In September 2026, libcurl removes NTLM support, and Git operations over HTTPS against on-prem Azure DevOps Server stop working for anyone still authenticating that way. Microsoft published the warning on its Azure DevOps Blog on July 1, and the migration paths it points customers at are Kerberos, or SSH. The pipelines most exposed are the ones that have quietly negotiated down to NTLM without anyone noticing.
How the change reaches your build agents
Git shells out to libcurl for HTTP and HTTPS transport, and libcurl is what actually talks to IIS on the Azure DevOps Server side. When libcurl drops NTLM, the whole Git-over-HTTPS chain drops it with it. Microsoft's post is explicit about the sites most likely to trip: IIS configured with both Negotiate and NTLM enabled, deployments where Kerberos was never fully wired end to end (missing SPNs, DNS aliases, load balancer configuration), and non-domain-joined machines. That last bucket is where a lot of CI lives: workgroup boxes, service accounts, build agents, and anything running outside the corporate network.
On paper, Negotiate is supposed to try Kerberos first and only fall back to NTLM. In practice, plenty of pipelines never negotiated up.
Checks Microsoft wants you to run first
Two probes come out of the guidance. The first is to look for the NTLM warning that Git surfaces in its own output when it ends up on NTLM; that string is the tell that a pipeline is on the doomed path. The second is to inspect the Kerberos ticket cache directly: klist purge to clear it, then klist after the next authenticated Git operation to see whether a ticket actually came back. If nothing came back, that pipeline was falling through to NTLM without anyone knowing.
Two migration routes
For anything on the domain, Microsoft's answer is to finish the Kerberos wiring by September 2026: correct SPNs on the service account, working domain controller connectivity from every agent, and IIS set up to accept Kerberos properly. That is a domain-team job, not a Git-team job, which is part of why NTLM survived this long in the first place. It defaulted to something that worked.
For everything else, workgroup machines, cross-forest developer laptops, service accounts on hosts that will never see a domain controller, the guidance is to move those specific Git connections to SSH. SSH does not need Kerberos and it does not need the domain. That is exactly why the post offers it as the escape hatch.
What Microsoft explicitly tells customers not to do
The blog closes with unusually direct warnings. Don't treat continued NTLM fallback as a mitigation; it goes away in September. Don't plan to re-enable NTLM after removal; the post says there will be no supported way to keep using it. And don't pin Git to an older version to hold onto NTLM; the post is explicit that a downgrade is not the answer.
The wider frame
Microsoft positions the change as part of a broader industry move toward more secure authentication mechanisms, which it is. The immediate operational read is narrower. From September 2026, an on-prem Azure DevOps deployment that has been leaning on NTLM stops being a working Git remote for anyone who has not migrated. The date is on the calendar. The Kerberos and SSH work is not.
Top comments (0)