Microsoft has formally moved NTLM (NT LAN Manager) to the deprecation pile and is pressing organizations to adopt Kerberos via the Negotiate stack as the secure default for Windows authentication, while also shipping new auditing, telemetry, and migration tooling to help IT teams find and remediate legacy NTLM usage.
NTLM arrived with early Windows networking and persisted for decades as a simple challenge–response authentication mechanism that worked in many edge cases where Kerberos could not. Over time, Kerberos became the preferred protocol for domain environments because it supports mutual authentication, single sign‑on, and stronger cryptography. Microsoft now says all versions of NTLM — LANMAN, NTLMv1, and NTLMv2 — are no longer under active feature development and are deprecated, and that calls that explicitly request NTLM should be replaced by calls to the Negotiate package so Kerberos is used first and NTLM only as an exceptional fallback. This is not a sudden change; Microsoft has been signaling an authentication modernization path — including new Kerberos features such as IAKerb (Initial and Pass‑Through Authentication Using Kerberos) and Local KDC to broaden Kerberos applicability — while simultaneously building richer NTLM auditing and management controls to give organizations the visibility to act. Those platform investments are intended to make Kerberos usable in more scenarios today so NTLM can eventually be disabled without breaking business-critical services.
This approach has strengths — safer defaults, improved telemetry, and platform features that make Kerberos viable in more situations — but success depends on disciplined execution by organizations. The real work falls on IT teams: inventorying legacy consumers, engaging vendors, fixing or replacing brittle applications, and instituting governance for short‑lived exceptions.
Two related timelines demand attention: NTLMv1 is already removed in Windows 11 24H2 and Windows Server 2025, and Microsoft has signaled a separate Kerberos default flip (disabling RC4 and preferring AES for KDC session keys) targeted for mid‑2026 to reduce Kerberoasting exposure. Plan accordingly, treat any re‑enabled legacy option as a tracked, temporary risk, and use Microsoft’s auditing and Kerberos telemetry to make remediation data‑driven. For most organizations, the roadmap is clear: enable auditing now, fix developers who explicitly request NTLM, rekey and rotate service accounts so AES is available, and stage Kerberos‑first pilots. The payoff is fewer brittle compatibility compromises and a measurably stronger authentication posture across Windows estates.
Microsoft’s move turns a decades‑old compatibility choice into an operational modernization project — one that the vendor is supporting with new features and telemetry, but which ultimately requires proactive inventory, testing, and disciplined cleanup from IT teams to realize the security benefits.
Source: BetaNews Microsoft officially deprecates NTLM and promotes Kerberos authentication
Background / Overview
NTLM arrived with early Windows networking and persisted for decades as a simple challenge–response authentication mechanism that worked in many edge cases where Kerberos could not. Over time, Kerberos became the preferred protocol for domain environments because it supports mutual authentication, single sign‑on, and stronger cryptography. Microsoft now says all versions of NTLM — LANMAN, NTLMv1, and NTLMv2 — are no longer under active feature development and are deprecated, and that calls that explicitly request NTLM should be replaced by calls to the Negotiate package so Kerberos is used first and NTLM only as an exceptional fallback. This is not a sudden change; Microsoft has been signaling an authentication modernization path — including new Kerberos features such as IAKerb (Initial and Pass‑Through Authentication Using Kerberos) and Local KDC to broaden Kerberos applicability — while simultaneously building richer NTLM auditing and management controls to give organizations the visibility to act. Those platform investments are intended to make Kerberos usable in more scenarios today so NTLM can eventually be disabled without breaking business-critical services. What Microsoft actually announced (the facts)
- Microsoft updated the Windows “deprecated features” guidance to list NTLM as deprecated and clarified that NTLMv1 is already removed starting in Windows 11, version 24H2 and Windows Server 2025. Use of NTLM will continue to work in those releases, but Microsoft expects teams to migrate away.
- The company explicitly recommends replacing explicit NTLM calls with Negotiate, which tries Kerberos first and only falls back to NTLM when Kerberos cannot be used. For many applications the change is mechanical: replace the literal package name passed to AcquireCredentialsHandle from "NTLM" to "Negotiate". Microsoft documents this migration path and notes a known compatibility caveat: Negotiate typically adds at least one extra round trip to the authentication exchange, and some applications that assumed a maximum number of round trips may require additional configuration.
- Microsoft also shipped enhanced NTLM auditing in Windows 11 24H2 and Windows Server 2025 so administrators can answer who is using NTLM, why it was chosen, and where (host/process/IP) it runs. Event logs for NTLM are now richer and easier to act on.
Why this matters: security drivers and technical context
NTLM’s cryptographic and architectural limitations make it a continuing target for attackers:- NTLM is vulnerable to relay and spoofing attacks and remains amenable to credential reuse techniques such as pass‑the‑hash when password hashes are exposed. Those attack patterns remain high‑value for attackers performing lateral movement inside networks.
- Kerberos-based attacks such as Kerberoasting exploit weak encryption paths in Kerberos service tickets (historically amplified when systems fall back to RC4-related key derivation). Microsoft and the security community have documented real-world compromises where offline cracking of Kerberos tickets played a role; removing weak fallback and strengthening Kerberos defaults directly raises the cost of these attacks. Microsoft has announced a related change to Kerberos defaults — moving domain controllers to prefer AES-SHA1 session keys and disable RC4 by default — explicitly to reduce the population-level risk from Kerberoasting-style abuses.
- NTLM lacks key modern features: no mutual authentication guarantees, poor cryptographic key derivation (especially in NTLMv1), and limited extensibility for modern SSO and encryption requirements. Moving to Kerberos improves security posture and enables newer identity features.
What administrators and developers should do now — a practical migration playbook
Microsoft’s guidance and ecosystem recommendations provide a clear remediation path. The steps below translate that guidance into an operational plan.- Inventory NTLM usage and generate a prioritized remediation list
- Turn on the enhanced NTLM auditing introduced in Windows 11 24H2 and Windows Server 2025 and collect logs from endpoints, servers, and domain controllers. The new logs show account, process, machine, and IP address — allowing you to identify both client and server causes.
- Categorize NTLM consumers
- Split findings into: (a) developer/hardcoded NTLM calls, (b) legacy applications or appliances that only speak NTLM, (c) imaging/provisioning problems (duplicate SIDs), (d) local account use where Kerberos isn’t available.
- Prioritize remediation for service accounts and high‑privilege systems first.
- Developer remediation: change AcquireCredentialsHandle
- For applications that explicitly select the NTLM package, change the package parameter to "Negotiate" in the AcquireCredentialsHandle call (SSPI). Microsoft documents that most applications can make this one-line change and start negotiating Kerberos first. Test after the change — Negotiate commonly adds an extra round trip which can affect code that assumed tighter timing or a fixed number of exchanges.
- Update service accounts and SPNs
- Ensure service accounts have AES key material in Active Directory. Resetting service account passwords (or rekeying) will generate AES keys. Use Microsoft’s Kerberos telemetry (new event fields in 4768/4769) to validate encryption types used by tickets.
- Patch and modernize third‑party appliances
- For embedded or third‑party devices that only support NTLM or RC4-era Kerberos, contact vendors and demand modern authentication support or isolate those systems behind dedicated service accounts and network segmentation. Prepare fallback or proxy options where vendor updates are unavailable.
- Harden LDAP and transport bindings
- Enable LDAP channel binding and Extended Protection for Authentication (EPA) where supported to reduce the risk of NTLM relay attacks and man‑in‑the‑middle relays. These mitigations reduce the opportunity for NTLM-based credential relays.
- Staged testing and rollback plan
- Roll out staged changes in test, pilot, and production rings. Use telemetry to measure failures and hit lists; keep explicit, short‑lived exceptions only where absolutely necessary and document sunset dates.
- Governance and exception control
- Treat any explicit re‑enablement of NTLM or RC4 as a high‑risk, time‑boxed exception with logging, monitoring, and an assigned owner.
Common migration pitfalls to watch for
- Applications that hard‑code NTLM or expect a fixed number of authentication round trips may fail or suffer timeouts after switching to Negotiate. These cases require either application fixes or special configuration. Microsoft explicitly calls this out: Negotiate will add at least one additional round trip in most cases; some scenarios may require additional configuration.
- Local accounts and non-domain contexts. Kerberos requires KDC access or the new Local KDC/IAKerb features to extend Kerberos to scenarios where the domain controller is not reachable. Microsoft is shipping IAKerb and Local KDC features to address some of these gaps, but these are platform-level changes you must validate in your topology.
- Embedded devices and third‑party appliances frequently lag updates; they can become brittle and cause authentication outages. Inventory and vendor engagement are essential.
- Imaging issues and duplicate machine SIDs surfaced by recent Windows hardening changes can lead to unexpected authentication failures during testing and production rollout. Ensure provisioning best practices (Sysprep, unique SIDs) are followed.
Microsoft’s telemetry, tools and timelines (what’s provided)
Microsoft is not leaving admins to flail in the dark. The company has published guidance, logs, and tooling:- Deprecated features and migration guidance — the Windows documentation lists NTLM as deprecated and summarizes migration recommendations (Negotiate, auditing).
- NTLM auditing enhancements — new, richer Event Log entries and operational guidance for server, client, and DC auditing to answer who/why/where about NTLM usage.
- Kerberos telemetry and remediation tooling — Microsoft added new fields to Security Event Log Kerberos events (4768/4769) to show advertised enctypes, available keys, and ticket/session encryption types. They also published PowerShell scripts and guidance to inventory accounts and detect RC4 usage so teams can find and fix RC4 dependencies ahead of default flips.
- Timeline signals — NTLMv1 removal is already in Windows 11 24H2 and Windows Server 2025. Microsoft has set guidance and tooling to phase out NTLM broadly; in parallel it will flip Kerberos defaults so domain controllers prefer AES and RC4 will be disabled by default by around mid‑2026. That RC4/kerberos default flip addresses a related but distinct risk vector (Kerberoasting) and gives admins runway to remediate service accounts and third‑party clients.
- Additional community and vendor sources — public reporting and community discussion about the changes is robust; administrators should monitor vendor advisories and community remediation playbooks that map to their environment specifics.
Strengths of Microsoft’s approach
- Safer defaults move the entire installed base closer to modern cryptography without requiring every administrator to change settings. Making AES the default for Kerberos and recommending Negotiate reduces the feasible attack surface long-term.
- Operational telemetry and tooling: adding richer audit fields and scripts makes it realistic for large enterprises to discover and remediate issues rather than guessing. The company’s approach is fix‑first: give visibility, automation, and a runway, not a surprise removal.
- Protocol modernization: IAKerb and Local KDC address operational gaps that historically forced NTLM fallbacks (offline clients, non‑domain contexts), making Kerberos a practical default in more scenarios.
Risks, tradeoffs and governance concerns
- Operational disruption: vendor devices, legacy applications, and fragile authentication handoffs risk outages if remediation is rushed or poorly tested. Microsoft’s own warnings about round trips and assumptions underline this.
- Exception overuse: preserving opt‑ins for RC4 or NTLM for compatibility is necessary, but organizations that treat exceptions as permanent will reintroduce risk. Exceptions must be documented, short‑lived, audited, and governed.
- Supply‑chain and vendor risk: many devices in industrial, healthcare, and telco environments rely on legacy stacks. These vendors may lack short‑term updates; firms must plan compensating controls (network segmentation, proxies, privileged access limitations).
- Detection gaps: while Microsoft’s auditing is better, not every environment has a centralized SIEM or the operational discipline to ingest and act on logs. Organizations must map NTLM telemetry into change‑management and vulnerability remediation workflows.
- Cloud and hybrid identity complexities: hybrid scenarios (Azure AD/Entra ID, cloud‑only devices, RDP gateways) can introduce unexpected fallbacks; test thoroughly in hybrid lab setups and consult Microsoft’s guidance on IAKerb and local KDC behavior for those topologies.
Quick checklist for the next 30/90/180 days
- 0–30 days:
- Enable NTLM auditing and start collecting logs for endpoints, servers, and DCs.
- Search codebases for AcquireCredentialsHandle calls using the literal "NTLM". Plan developer fixes.
- Build a prioritized list of service accounts and high‑risk hosts.
- 30–90 days:
- Test changing AcquireCredentialsHandle package to "Negotiate" in development and QA; document and resolve any round‑trip timing issues.
- Reset/rotate service account credentials to ensure AES key material exists; run Microsoft PowerShell inventory scripts for Kerberos encryption usage.
- Engage vendors for firmware/software updates on appliances that only support NTLM or RC4.
- 90–180 days:
- Execute pilot Kerberos‑first deployments in a representative segment; monitor for fallback to NTLM and service failures.
- Implement governance for any remaining exceptions and plan retirement timelines for devices/applications that cannot be remediated.
Final analysis — what this means for Windows environments
Microsoft’s formal deprecation of NTLM is a significant, long‑overdue move to narrow an identifiable and widely‑exploited attack surface in Windows environments. The company balances hardening with practicality: it provides tooling, logging, and new Kerberos features to make migration feasible rather than simply cutting compatibility.This approach has strengths — safer defaults, improved telemetry, and platform features that make Kerberos viable in more situations — but success depends on disciplined execution by organizations. The real work falls on IT teams: inventorying legacy consumers, engaging vendors, fixing or replacing brittle applications, and instituting governance for short‑lived exceptions.
Two related timelines demand attention: NTLMv1 is already removed in Windows 11 24H2 and Windows Server 2025, and Microsoft has signaled a separate Kerberos default flip (disabling RC4 and preferring AES for KDC session keys) targeted for mid‑2026 to reduce Kerberoasting exposure. Plan accordingly, treat any re‑enabled legacy option as a tracked, temporary risk, and use Microsoft’s auditing and Kerberos telemetry to make remediation data‑driven. For most organizations, the roadmap is clear: enable auditing now, fix developers who explicitly request NTLM, rekey and rotate service accounts so AES is available, and stage Kerberos‑first pilots. The payoff is fewer brittle compatibility compromises and a measurably stronger authentication posture across Windows estates.
Microsoft’s move turns a decades‑old compatibility choice into an operational modernization project — one that the vendor is supporting with new features and telemetry, but which ultimately requires proactive inventory, testing, and disciplined cleanup from IT teams to realize the security benefits.
Source: BetaNews Microsoft officially deprecates NTLM and promotes Kerberos authentication
