NTLM Is Ending in Git/libcurl: Azure DevOps Server Teams Need a Real Migration Plan

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

The upcoming NTLM removal in libcurl is one of those changes that looks technical but is actually organizational. If your Git over HTTPS path to Azure DevOps Server still depends on NTLM, your issue is not tooling, it is identity debt.

Original source: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft is right to push hard here. NTLM has known cryptographic weaknesses and should not be a modern enterprise default. The dangerous part is that many environments believe they are using Kerberos when they are actually surviving on silent SPNEGO fallback to NTLM. That illusion disappears in September 2026.

My opinion: do not treat this as a “client version” problem. Re-enabling NTLM flags, pinning old Git builds, or hoping fallback remains available is a short-lived workaround with long-term risk. If your remediation strategy is downgrade-and-delay, you are actively increasing operational fragility.

A practical migration sequence should be blunt and measurable.

Verify current auth behavior now. Run trace-based checks and ticket cache validation in real developer and build-agent contexts, including off-domain and remote-network paths.
Fix Kerberos end-to-end: SPNs, DNS aliases, load balancer settings, delegation, and domain controller reachability.
Identify non-domain-joined or workgroup scenarios early and design an SSH lane where Kerberos cannot be made reliable.

You also need ownership clarity. Security teams should define policy baselines, but platform engineering must own implementation readiness. This cannot be a side task for individual repo admins. It requires coordinated changes across IIS, AD, network edge, CI agents, and developer workstation guidance.

One subtle risk is automation. Build agents and service accounts frequently run in contexts where Kerberos tickets are missing or invalid, even when human users are fine. If you only test interactive developer workflows, you will miss the most critical breakpoints.

The upside is real. Moving cleanly to Kerberos or SSH not only avoids breakage, it reduces attack surface and aligns identity controls with modern compliance expectations. The teams that start this transition now will treat September as a nonevent. The teams that wait will be debugging auth failures under release pressure.

This is not a warning to archive. It is a deadline to execute against.

Reviewing Pull Requests Inside Visual Studio Is Exactly the Kind of Friction Reduction I Like

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

The browser has been stealing too much of the code review workflow for too long.

So I am very happy to see Visual Studio pushing further into end-to-end pull request review inside the IDE.

This is one of those features that may not generate huge headlines, but it can absolutely improve everyday development.

The main value is simple: less context switching

When your review loop lives partly in the IDE and partly in the browser, the friction adds up:

open the PR elsewhere
inspect changes in one tool
jump back to the solution for deeper investigation
switch again to comment or approve

It is not catastrophic. It is just inefficient.

If Visual Studio can let you open, inspect, comment, approve, and merge from the same working environment, that is a real productivity win.

The “review without checkout” option is especially nice

One part I particularly like is the ability to review without checking out the PR branch.

That sounds small, but it is perfect for:

quick review passes
interrupt-driven feedback requests
keeping your current branch and local state intact

That is exactly the kind of flexibility good code review tooling needs.

My take

This is not a revolutionary feature.

It is something better: a practical one.

For teams spending most of their day in Visual Studio, tighter PR review support means fewer workflow breaks and a smoother path from inspection to action.

That is a worthwhile improvement in my book.

Original post: Review pull requests without leaving Visual Studio

Git | The .NET Blog

NTLM Is Ending in Git/libcurl: Azure DevOps Server Teams Need a Real Migration Plan

Reviewing Pull Requests Inside Visual Studio Is Exactly the Kind of Friction Reduction I Like

The main value is simple: less context switching

The “review without checkout” option is especially nice

My take