Microsoft just pulled the rug out from under a huge class of on-prem Git setups: Azure DevOps Server customers have been told NTLM authentication in Git's libcurl will be removed. If your devs or automation still rely on Windows Integrated Authentication for HTTP(S) Git operations — credential manager flows that negotiate NTLM or legacy domain auth baked into build agents — those clones, fetches, and CI checkouts will start failing until you switch auth methods.
This is the right call for security, but a messy one for anyone who treated NTLM as an implicit transport-layer credential. NTLM is an old, stateful Windows protocol with a track record of edge-case failures and replay risks; removing it forces an architectural shift toward token-based flows or SSH. The problem is Git and many on-prem images historically relied on a libcurl build with NTLM support enabled, so a lot of scripts, VMs, and appliance-style CI/CD runners assume it just works.
What breaks and why it matters
- Developer laptops using Git over HTTPS with Windows Integrated Authentication will see auth errors.
- Hosted or on-prem build agents that perform Git fetches with machine accounts or service accounts relying on NTLM will fail CI jobs.
- Automation that impersonates users via NTLM (custom credential injection, legacy scripts) will stop working and can block releases.
Migration options (pick one, test aggressively)
- SSH keys: Highest compatibility. Convert repos to SSH access and rotate keys into your platform-managed store. Good for non-interactive automation.
- Personal Access Tokens (PATs) or OAuth via Git Credential Manager (GCM): Modern, token-based, and auditable. Use GCM where possible — it supports Azure AD flows and avoids storing raw credentials in scripts.
- Service principals and managed identities for automation where supported: Replace service-account NTLM flows with tokenized access in your pipeline tool.
Audit checklist (practical)
- Search for NTLM usage: git config --list | grep -i credential; scan agent images and container layers for libcurl builds that list NTLM support (curl --version will show NTLM or NTLM_WB if enabled).
- Identify non-interactive checkouts: these are the highest priority — change them to SSH or PATs first.
- Update secrets rotation and vault policies: tokens should be short-lived and auditable; rotate SSH keys and store them centrally.
- Test bump: spin up a canary agent with libcurl built or configured without NTLM support and run all pipelines.
Why Microsoft did this — and why it's overdue
NTLM's removal aligns with a broader industry shift away from fragile, stateful auth mechanisms toward short-lived, scoped tokens and SSH. It's the right security decision. My gripe is execution: on-prem customers are getting a breaking change to a behavior they've relied on for years without a one-click migration path. Microsoft should have shipped tooling to convert service accounts to scoped PATs or provided clearer migration utilities for Azure DevOps Server.
Other Azure platform moves this week
Azure also announced several updates across resiliency, AI, and migration tooling; check the Azure updates feed and your tenant notifications for exact details relevant to your environment.
If you're the platform engineer responsible for developer productivity, treat the NTLM removal like a hard deprecation: inventory, prioritize automation, and pick a token-first strategy. If you delay, you'll get interrupted builds and disgruntled developers. If you act now, you get rid of a brittle auth mode and move toward auditable and revocable credentials — which is what on-prem Git should have had five years ago.