After more than 30 years, Microsoft has confirmed that the legacy NTLM authentication protocol is on its way out. Future versions of Windows Server and Windows client will have NTLM disabled by default, with a phased plan already in motion.
If you look after Windows endpoints, this is more than just an identity-story headline. It’s a reminder that a lot of our environments still depend on old assumptions: “everything talks NTLM on the LAN” and “everyone’s a local admin on their PC.”
In this post we’ll look at what the NTLM phase-out means in practice – and why it’s a good moment to revisit your local admin and legacy app strategy at the same time.
Quick recap: what’s happening to NTLM?
NTLM (New Technology LAN Manager) has been around since the Windows NT 3.1 days. It was designed for a very different world: flat networks, on-prem everything, and few attackers thinking about relay, replay or pass-the-hash attacks.
Today, Microsoft classifies NTLM as deprecated and is moving to disable it by default in future Windows releases. The roadmap, in very simple terms:
- Phase 1 – Visibility. Enhanced NTLM auditing in Windows 11 24H2 and Windows Server 2025 to show where NTLM is still used.
- Phase 2 – Removing roadblocks. Features like IAKerb and a local KDC help replace scenarios that previously relied on NTLM, even when domain controllers aren’t directly reachable.
- Phase 3 – Default off. In the next major Windows Server and client releases, network NTLM will be disabled by default. It will still be present in the OS, but you’ll have to explicitly re-enable it via policy.
The message is clear: NTLM is leaving the building. Identity teams now have a concrete timeline to find and remove remaining dependencies.
NTLM and local admin: two sides of the same old Windows story
For many organisations, NTLM isn’t the only 1990s hangover. There’s a familiar pattern on the endpoints too:
- Older or “special” Windows apps that only behave if the user is a local admin.
- Installers and management tools that assume they can touch the whole file system and registry.
- Helpdesk teams typing local admin passwords into UAC prompts “just to get things working”.
NTLM and local admin are both symptoms of the same era: a trusted LAN, a trusted user, and software written with very few guard rails.
Microsoft’s NTLM decision is a signal that the identity side of that world is closing down. It’s a good time to ask: do we really want to reach the “NTLM disabled by default” future while still running most of our legacy apps as local admin?
What the NTLM phase-out means for your legacy apps
As you start auditing NTLM usage, certain patterns will pop out:
- Line-of-business apps talking to old servers using NTLM.
- “Helper” utilities and management tools that have never been updated to use modern auth.
- Services or scheduled tasks running under accounts that still rely on NTLM.
Those same applications are often the ones that also demand local admin on the endpoint: they write settings into HKLM, drop files under C:\Program Files, or expect unfettered access to sensitive folders.
So while you’re mapping NTLM dependencies for your identity team, it’s worth mapping “needs local admin to work” at the same time. They’re usually the same list of apps.
A joint plan: modern authentication + least privilege on the endpoint
From an endpoint point of view, the NTLM news is an opportunity to join two projects that are often handled separately:
- Modernise authentication. Use the new NTLM auditing features to find where NTLM is still used, then plan your move to Kerberos and other modern protocols.
- Reduce standing local admin. Identify who is a local admin today and which apps are blocking you from removing those rights.
- Give legacy apps a controlled elevation path. Instead of keeping users as admins “because of one old app”, find a way to elevate just the app, not the whole user session.
We’ve written previously about the local admin side of this story in:
- The Double-Edged Sword of Local Admin Rights in Windows Environments
- Five Myths About Removing Local Admin Rights on Windows
- Windows 11 Administrator Protection, Intune EPM, and the Legacy Apps They Still Can’t Fix
The NTLM phase-out just adds more urgency: attackers already love local privilege escalation bugs, and every standing local admin account makes their job easier.
Where Elevator fits in
At UNYK, we built Elevator for Windows specifically for the “we’d remove local admin, but these apps…” problem.
Elevator helps you:
- Keep users as standard users on their Windows devices.
- Define a short, explicit list of executables that are allowed to run with admin rights.
- Run those apps elevated, without users knowing (or re-typing) local admin passwords.
- Log elevation events so you can see exactly which legacy apps still depend on admin rights.
That means you can modernise authentication (moving away from NTLM) and modernise endpoint privilege at the same time: Kerberos on the wire, least privilege on the device.
Don’t reach the NTLM future with 1990s local admin
Microsoft’s NTLM roadmap is a clear signal that “old Windows assumptions” are being actively dismantled. You can either wait for that change to arrive and scramble, or use the time between now and the “NTLM disabled by default” world to get ahead.
If you’d like to test Elevator against a couple of your legacy or specialist Windows apps, you can start a pilot in a small group and see how far you can reduce local admin without breaking anything.
