Windows Kerberos First: Phase-by-Phase Move Away From NTLM

  • Thread Author
Microsoft’s long-running allowance for NTLM-based authentication is finally being reworked into history: the company has laid out a phased plan to clamp down on Network NTLM and push Windows environments toward Kerberos-first authentication, a move that promises real security gains but will require careful planning across enterprises that still rely on legacy behaviors and devices.

Background: why NTLM must go​

NTLM (New Technology LAN Manager) was introduced in 1993 as a simple, password-based challenge/response protocol. For decades it served as a practical fallback when Kerberos-based authentication wasn’t available—useful in mixed environments, offline scenarios, or when applications used IP addresses or lacked Service Principal Names (SPNs). But the protocol’s design makes it an increasingly untenable security foundation in modern networks.
  • NTLM transmits data that can be relayed or reused. Unlike Kerberos, NTLM’s challenge/response model allows attackers to capture and relay authentication artifacts — a technique exploited in NTLM relay attacks.
  • Attack techniques matured. Security research has exposed a string of coercion and relay scenarios that allow adversaries to force servers to authenticate to malicious endpoints and then relay those credentials to critical services such as Active Directory Certificate Services (AD CS). Notable examples include the PetitPotam family of techniques and other coercion methods; these have repeatedly been leveraged to escalate privileges and attain domain takeover.
  • Pass-the-hash and credential theft remain practical. Tools and threat actor playbooks that capture NTLM hashes and re-use them (pass-the-hash) continue to yield lateral movement and privilege escalation in breached networks.
In short, NTLM’s fallback role has become a broad attack surface — one Microsoft has publicly acknowledged must shrink if Windows environments are to be secure by default.

Microsoft’s three-phase transition: what’s changing and when​

Microsoft has published a staged roadmap to move Windows toward a Kerberos-first future. The plan is structured to reduce operational disruption while eliminating the legacy NTLM attack surface.

Phase 1 — Visibility and auditing (already rolling out)​

Phase 1 focuses on giving administrators the tools to discover where NTLM is still used. Enhanced NTLM auditing capabilities were integrated into recent releases, so organizations can:
  • Catalog services and accounts that generate NTLM authentication.
  • See which processes and services are responsible for NTLM calls.
  • Identify cross-forest, local-account, or IP-based behaviors that cause Kerberos fallback.
These auditing improvements were introduced in modern releases of Windows client and server builds, enabling admins to create a prioritized remediation plan rather than blind-rolling policy blocks.

Phase 2 — Kerberos coverage for legacy scenarios (second half of 2026)​

Phase 2 addresses the practical reasons Windows historically fell back to NTLM. Microsoft plans to deliver two major capabilities to extend Kerberos reach:
  • IAKerb (Initial and Pass Through Authentication Using Kerberos): This mechanism helps Kerberos work in more diverse network topologies by allowing Kerberos messages to be passed or proxied in situations where direct Kerberos exchanges or traditional discovery (DNS, Netlogon) would fail. It aims to remove the need to fall back to NTLM when clients and servers are separated by network constraints or when direct contact with a domain controller is difficult.
  • Local KDC (local Key Distribution Center): A small, local Kerberos KDC implementation on endpoints that allows local accounts and certain offline or partially-connected scenarios to use Kerberos-style tickets (with modern ciphers such as AES) instead of falling back to NTLM.
Microsoft’s guidance notes these features will be available in pre-release or supported builds and are scheduled to roll out in the second half of 2026 for devices running the relevant client and server baselines.

Phase 3 — Network NTLM disabled by default (future major release)​

The final phase is a major, default configuration change: network NTLM authentication will be disabled by default in a future major Windows Server and matching Windows client release. NTLM will remain present for explicit re-enablement by policy, but the out-of-the-box behavior will prefer Kerberos and block network NTLM unless an administrator opts otherwise.
This three-step approach — visibility, mitigation features, then secure-by-default configuration — gives organizations a runway to adapt, though it also imposes a responsibility to act.

What Kerberos brings to the table (and why it matters)​

Kerberos is not new to Windows — it has been the default authentication protocol for domain-joined machines for many years. What’s changing is Windows’ tolerance for fallback to NTLM.
Key technical advantages of Kerberos:
  • Ticket-based authentication: Clients obtain Ticket Granting Tickets (TGTs) from a KDC and then request service tickets for specific services. Tickets are cryptographically bound and time-limited, reducing replay and credential-theft risks.
  • Mutual authentication: Kerberos supports mutual authentication so clients can validate service identity, closing attack channels that rely on impersonation.
  • Stronger cryptography and ephemeral tokens: Modern Kerberos implementations use AES and can limit ticket lifetimes, reducing exposure windows.
  • No password exchange across the network: Kerberos avoids sending password-equivalent material that NTLM challenge/response flows can leak.
The challenge historically was that Kerberos requires certain conditions — time synchronization, reachable domain controllers, and proper SPN registration — and older devices or apps violated those assumptions. Microsoft’s Phase 2 features are explicitly designed to address these operational gaps.

The attack landscape that pushed Microsoft’s decision​

Over the last several years the security community documented multiple practical NTLM-based attacks that make default NTLM usage risky:
  • NTLM relay (coercion) attacks. Techniques such as PetitPotam exploit benign RPC or protocol behaviors to force servers (including domain controllers and certificate servers) to authenticate to attacker-controlled endpoints. Those authentication artifacts can then be relayed to acquire certificates or perform privileged actions.
  • ShadowCoerce and similar vectors. Researchers showed how obscure RPC interfaces — not commonly monitored — could be abused to coerce authentication in the same family as PetitPotam.
  • Continued pass-the-hash and credential reuse. NTLM hash theft remains an effective technique for lateral movement, especially where NTLM is present and accepted across services.
These realities turned NTLM from a compatibility convenience into a systemic vulnerability. Microsoft’s new defaults and mitigations (such as enabling Extended Protection for Authentication and LDAP channel binding in key services) reduce these attack surfaces in the short term while the longer-term Kerberos coverage improvements land.

Operational impact: what admins must expect​

Disabling network NTLM by default will produce real-world friction unless organizations prepare. Expect these categories of impact:
  • Legacy applications and appliances. Many older applications, network appliances, scanners, MFPs, or specialized servers still use NTLM or rely on IP-based authentication or hard-coded endpoints lacking SPNs. Those will likely fail authentication when NTLM is blocked.
  • Cross-forest and trust complexities. One-way trusts, legacy domains, and cross-domain authentication flows may use NTLM in edge cases. Admins must validate cross-domain access patterns.
  • Local account and service scenarios. Systems that rely on local accounts, or local services that historically used NTLM to authenticate to local resources, may need reconfiguration to use Local KDC or other supported Kerberos options.
  • Human and process impact. Helpdesks, scripted automation, and scheduled tasks that authenticate with NTLM flows must be identified and updated.
Because Microsoft intends to allow explicit policy re-enablement of NTLM, there will be a safety valve. But relying on that as a long-term strategy is risky; it keeps a large attack surface open.

A practical migration roadmap for IT teams​

This is not a binary switch you flip at 3 AM. A methodical, phased approach will reduce outages and security exposure.
  • Inventory and measure NTLM usage (Phase 1 actions).
  • Enable enhanced NTLM auditing in your Windows 11 24H2 and Windows Server 2025+ estates.
  • Collect logs centrally (SIEM, Defender for Identity, or Event Hubs) and map sources: which machines, services, users, and service names generate NTLM.
  • Prioritize high-risk assets (domain controllers, certificate servers, Exchange, LDAP endpoints, critical file shares).
  • Remediate high-risk servers and services.
  • Harden Exchange, AD CS, and LDAP with EPA, channel binding, and SMB signing where applicable.
  • Apply relevant Microsoft hotfixes and baseline configurations to close known coercion vectors.
  • Test Kerberos-first behavior in a controlled lab.
  • Create a test network that mirrors production topology, including cross-forest trust scenarios and legacy devices.
  • Evaluate the impact of enabling SMB NTLM blocking in the SMB client and server stacks; use exception lists as needed.
  • Identify and update legacy clients and appliances.
  • Replace or patch devices that cannot use Kerberos or negotiate with modern security packages.
  • Where replacement isn’t immediately possible, use targeted policy exceptions and network segmentation to reduce exposure.
  • Deploy Phase 2 features when available.
  • Plan to adopt IAKerb and Local KDC once production-ready builds are available (Microsoft indicated a rollout target in H2 2026).
  • Pilot these features on a subset of devices to validate resolution of offline, local-account, and topology-constrained fallbacks.
  • Implement policy and hardening.
  • Gradually move from detection to blocking: use per-service NTLM blocking rather than a blanket network ban where needed.
  • Ensure administrators know how to re-enable NTLM where absolutely necessary and log such decisions.
  • Communicate, train, and document.
  • Update runbooks, incident playbooks, and helpdesk scripts.
  • Train SOC and operations teams to recognize Kerberos failures vs. NTLM-related errors and to respond accordingly.

Controls and features you should be using now​

  • NTLM auditing and event extension. Capture which service and process initiated NTLM auth to reduce false positives and to pinpoint remediation targets.
  • SMB NTLM blocking. Modern SMB clients can refuse to offer NTLM; use this in test groups to assess compatibility. Exception lists are available to mitigate breakage during rollout.
  • Extended Protection for Authentication (EPA). Enforce protocol-level protections on services like Exchange and AD CS to block relays.
  • LDAP channel binding and SMB signing. Enabling these reduces the risk of NTLM coercion.
  • Network segmentation. Isolate legacy devices to minimize the blast radius while migrating them off NTLM.

Realistic timeline and expectations​

Microsoft has published target windows for the major milestones:
  • The auditing and visibility improvements are already available in recent releases (Windows 11 24H2 and Windows Server 2025).
  • Microsoft has stated that Phase 2 capabilities (IAKerb, Local KDC) are scheduled to appear in the second half of 2026 for supported server and client builds.
  • Phase 3 — disabling network NTLM by default — is planned for a future major Windows Server release and associated client ships; the company emphasizes NTLM will remain re-enableable by policy to avoid unexpected outages.
Administrators should take these published timelines seriously as planning inputs but also recognize that Microsoft’s calendar may shift and that organizational readiness will likely dictate when you implement blocking policies in production.

Risks and caveats — what can go wrong​

  • Operational outages. A blunt, mass disabling of NTLM will almost certainly cause immediate authentication failures for legacy endpoints and third-party applications that lack Kerberos support.
  • Incomplete telemetry. Even with improved auditing, corner cases exist — obscure RPC interfaces, third-party services, or devices with intermittent connectivity may still use NTLM in ways that are hard to detect without thorough testing.
  • Policy complexity and shadow exceptions. Relying on per-server or per-service NTLM exceptions creates a maintenance burden. Over time, exceptions can accumulate and erode the security posture if not audited.
  • Supply-chain and appliance gaps. Hardware or SaaS providers that embed legacy Windows auth in their products may not have near-term upgrades, requiring compensating controls or replacements.
  • Human error in configuration. Misapplied blocking policies could inadvertently lock out management accounts or remote services; strong test-and-rollout procedures are essential.
Flag: any specific claim about exact release dates beyond Microsoft’s posted guidance should be treated as tentative. Microsoft’s published statements indicate general target windows (e.g., “second half of 2026” for IAKerb/Local KDC) rather than fixed ship dates, and product schedules have historically shifted.

Why not just keep NTLM and live with the risk?​

Some organizations will choose to defer changes — re-enabling NTLM by policy is an available stopgap. But the strategic trade-offs are stark:
  • Keeping NTLM widely available is effectively accepting a broad, well-understood attack surface that has been repeatedly weaponized.
  • As Microsoft hardens client and server defaults and as the ecosystem shifts to Kerberos-first expectations, the administrative and security costs of clinging to NTLM will grow.
  • Threat actors will continue to develop coercion and relay techniques against any remaining NTLM-enabled surface, making incremental remediation both prudent and necessary.
In short: deferring creates mounting risk exposure and reduces operational options down the road.

Final verdict: a necessary but delicate evolution​

Microsoft’s plan to shift Windows to a Kerberos-first model is a positive change from a security perspective. The staged approach — inventory, deliver mitigations, then change defaults — reflects a pragmatic attempt to balance security with compatibility. The inclusion of tools such as SMB NTLM blocking, IAKerb, and Local KDC shows Microsoft understands the real-world reasons NTLM persisted and is investing to remove them without breaking enterprise workloads.
However, this is not an overnight project for enterprise IT. The path to a secure-by-default Windows estate requires:
  • disciplined telemetry collection,
  • careful testing with legacy systems and third-party appliances,
  • a structured remediation program, and
  • a governance model to manage exceptions and regressions.
Organizations that start now — building inventories, applying hardening, and piloting Kerberos-first behaviors — will have the advantage when Microsoft flips the default switch. Those that wait risk last-minute firefighting and elevated breach exposure.

Checklist: first actions for IT teams this week​

  • Enable enhanced NTLM auditing in your Windows 11 24H2 and Windows Server 2025+ environments.
  • Start a focused inventory: list devices, services, and apps that still use NTLM.
  • Harden Exchange, AD CS, and LDAP endpoints with EPA and channel binding where supported.
  • Build a test lab that mirrors production cross-domain and offline scenarios for Kerberos validation.
  • Evaluate SMB NTLM blocking in a sandbox and prepare exception lists for devices that cannot switch.
  • Communicate change windows to application owners and procurement teams so replacement and upgrade paths can be scheduled.
The end of NTLM as a default network authentication mechanism will be a landmark change for Windows security. It’s long overdue, it is achievable, and it will materially reduce a class of attacks that has plagued organizations for years — provided IT teams use the breathing room Microsoft is offering now to inventory, remediate, and modernize their identity surfaces before defaults change.
Source: Red Hot Cyber Goodbye to NTLM! Microsoft is moving towards a new era of authentication with Kerberos
 
Click to expand...
Microsoft is preparing to ship Windows in a "secure-by-default" state that blocks network NTLM authentication unless an organization explicitly allows it — a phased, multi-year shift that replaces legacy NTLM with Kerberos-first authentication and introduces new Kerberos capabilities (IAKerb and Local KDC) to minimize compatibility fallout.

Background​

NTLM (New Technology LAN Manager) began life in 1993 as the successor to the original LAN Manager protocol. For decades it provided Windows with a simple challenge/response mechanism to authenticate users and services across networks. Over time, however, cryptographic advances and attack techniques outpaced NTLM’s protections: the protocol is vulnerable to replay, relay, pass‑the‑hash, and man‑in‑the‑middle attacks, and it lacks modern server authentication guarantees. Microsoft has long advised customers to prefer Kerberos and Negotiate where possible; the company now classifies NTLM as deprecated and is moving to disable it by default in upcoming Windows releases.
This change is not a sudden removal. Microsoft designed a staged rollout to give IT teams time to inventory usage, remediate or modernize legacy apps, and test configurations. The plan centers on three phases: better auditing to find NTLM dependencies, new Kerberos-first technologies (IAKerb and Local KDC) to avoid NTLM fallback, and finally disabling network NTLM by default in the next major Windows Server and associated client releases — while still allowing administrators to re-enable NTLM where necessary via policy.

Why Microsoft is pulling the plug on NTLM​

NTLM remains a practical liability in many enterprise environments. The protocol’s design decisions — which predate modern crypto standards — create multiple risk vectors:
  • No server authentication guarantee: NTLM does not prove the identity of the target service the way Kerberos tickets and PKINIT/channel-binding mechanisms do. This makes relay and man‑in‑the‑middle scenarios feasible.
  • Weak cryptography and replayability: Older variants and derived credentials are susceptible to replay and cracking, especially when stored or transported insecurely.
  • Frequent attacker tooling: NTLM hashes and relays are common building blocks in lateral movement and privilege escalation attacks.
  • Limited visibility historically: Until recently, NTLM usage often lacked granular diagnostic logging, making it hard to fully inventory dependencies. Microsoft is fixing that with enhanced auditing.
The industry hit tallies when researchers and attackers exploited NTLM-related vectors in high-profile flaws — ShadowCoerce, PetitPotam, PetitPotam-like relays, and others — galvanizing the push for defaults that favor stronger protocols. Microsoft and security teams see disabling NTLM by default as an essential step to reduce the attack surface for on‑premises Active Directory and SMB-facing services.

The phased plan: what to expect and when​

Microsoft’s rollout follows three logical phases designed to be observable, reversible, and minimally disruptive.

Phase 1 — Audit and measure (already rolling)​

The first step is enhanced NTLM auditing. Windows 11 version 24H2 and Windows Server 2025 include new event logging and registry controls that let administrators run in Audit mode to find where NTLM is being used. New event types provide service‑level attribution for NTLM requests, making it far easier to map dependencies. This rollout is happening now via feature updates and controlled feature rollout channels.
Microsoft is also introducing a registry key that gates whether auditing is in Audit or Enforce behaviour; a planned change to make the key default to Enforce (BlockNTLMv1SSO = 1) is scheduled for October 2026 unless organizations set the registry themselves. That default change specifically affects NTLMv1-derived SSO credentials and is part of the NTLMv1 removal and hardening work. Administrators should not wait to deploy auditing — it’s the primary way to identify breakage risks.

Phase 2 — Compatibility mitigations (second half of 2026 target)​

Phase two delivers new Kerberos‑centric features that aim to fix the common scenarios that historically forced Kerberos to fall back to NTLM:
  • IAKerb (Initial and Pass‑Through Authentication Using Kerberos) — a mechanism to carry Kerberos messages between endpoints in network topologies that previously required DNS, Netlogon, or additional services, without opening new inbound ports. IAKerb broadens Kerberos applicability for remote and constrained environments.
  • Local KDC (Local Key Distribution Center) — a machine-local KDC that uses the local Security Account Manager so that local accounts can authenticate using Kerberos instead of forcing NTLM for local account scenarios. The Local KDC is intended to provide AES-based Kerberos for local accounts out of the box and reduce reliance on domain controllers for certain authentication flows.
Microsoft expects these features and related core-component updates to be available in Windows Server 2025 and Windows 11 24H2 devices during the second half of 2026. These capabilities aim to eliminate common NTLM fallback triggers (no DC connectivity, local-account authentication, hardcoded NTLM in legacy components). Administrators should plan to test IAKerb and Local KDC in lab environments as they become available through Windows Insider and servicing channels.

Phase 3 — NTLM disabled by default (next major Windows Server/client release)​

The final stage is where network NTLM authentication will be disabled by default in the next major Windows Server release and its associated client builds. Microsoft clarifies that disabling by default means Windows will block network NTLM from being used automatically and will prefer Kerberos/Negotiate, but NTLM will remain present in the OS and can be restored with explicit policy exceptions for compatibility. The company positions this as a “secure‑by‑default” posture that still preserves a path for mission‑critical legacy applications. The specific product name and precise release date for this final phase have not been published; Microsoft intends to use the telemetry gathered in Phase 1 and Phase 2 to determine readiness.

What IAKerb and Local KDC actually change​

Understanding the technical guardrails helps explain why Microsoft thinks it can safely flip the default.
  • IAKerb changes how Kerberos can be used across a variety of network topologies. Traditionally Kerberos required domain-aware infrastructure (DNS, Netlogon, direct KDC reachability). IAKerb enables Kerberos message pass‑through and ticket establishment in environments where those assumptions break down, reducing the need for NTLM fallback over SMB and other transports. This reduces attack surface because Kerberos includes better server authentication semantics and stronger cryptography.
  • Local KDC gives a Windows machine a local ticket‑granting capability backed by the machine’s SAM, enabling Kerberos for local accounts and local services without contacting a domain controller. That addresses one of the thorniest NTLM scenarios: when local authentication (or machines in workgroup scenarios) forced NTLM usage. In principle, Local KDC plus IAKerb lets endpoints authenticate with Kerberos semantics in situations that previously required NTLM.
Neither IAKerb nor Local KDC is a drop-in fix for every legacy app, and Microsoft has intentionally gated them behind feature rollouts so administrators can evaluate behavior in their own telemetry and test labs. Early reporting from the field shows that Local KDC had presence in Server 2025 builds but wasn’t necessarily enabled globally — expect teasers in preview builds before broad rollout.

What’s already changing today (practical defenses and knobs)​

Even before NTLM is disabled by default, Microsoft has implemented several defensive measures and administrative controls you can, and should, use now:
  • Enhanced NTLM auditing: Turn on the new NTLM auditing in Windows 11 24H2 and Windows Server 2025 to log NTLM usage, including service attribution. Use the logs to build a dependency map. Eventing improvements make it practical to see which services and binaries are using NTLM—and where to focus remediation.
  • SMB NTLM blocking: The SMB client supports NTLM blocking for remote outbound connections. That allows environments to force Kerberos for SMB while permitting exceptions for hosts that require NTLM. This is configurable via Group Policy or PowerShell on Windows Server 2025 and Windows 11 24H2. Use exceptions to avoid breaking third‑party devices that lack Kerberos.
  • SMB signing and channel binding: Windows Server 2025 and Windows 11 builds tighten SMB signing behavior and LDAP channel binding by default. These improvements reduce the feasibility of relays and tampering that enable credential theft.
  • Extended Protection for Authentication (EPA): Microsoft has enabled EPA by default for new and updated Exchange and AD CS configurations to mitigate relays and related NTLM attack patterns.
  • Credential Guard: Enabling Windows Credential Guard protects NTLMv1 legacy cryptography and other attack surfaces; devices with Credential Guard enabled may not be subject to some of these changes. Microsoft recommends Credential Guard where feasible.

Risks, realistic compatibility pain, and what can break​

Disabling NTLM by default will reduce attacks, but it also risks application breakage if organizations haven’t inventoried legacy usage. Key high-risk scenarios include:
  • Legacy applications that hardcode NTLM or use IP addresses instead of SPNs: Applications that authenticate using IP addresses, direct SMB fallback, or undocumented authentication flows often force NTLM. Those apps need code or configuration changes (SPNs, service accounts, Negotiate) to use Kerberos.
  • Non‑domain servers and appliances: Third‑party NAS devices, printers, and embedded systems that lack Kerberos or PKU2U will still rely on NTLM. Administrators must vet these devices and add exceptions where necessary during a staged rollout.
  • Local‑account scenarios and workgroup topologies: Before Local KDC arrives broadly, local accounts and workgroup authentication may be forced to use NTLM. Test plans should include local‑account scenarios and consider long‑term migration to domain or rearchitecting services.
  • Timing and feature gating uncertainty: Microsoft has given windows of availability (second half of 2026 for Phase 2 features; October 2026 for specific NTLMv1 registry defaults), but exact dates and product build numbers are subject to change. IT teams should treat timelines as targets, not immutable deadlines. Microsoft will use telemetry to determine readiness for Phase 3.
Flagging unverifiable claims: any reporting that pins a specific calendar date to the final disablement should be treated cautiously. Microsoft’s public documentation gives windows and conditional defaults (e.g., October 2026 for a BlockNTLMv1SSO registry default change), but the ultimate timing of “NTLM disabled by default” depends on Phase 1 and 2 telemetry and on customer feedback during previews. Treat published target quarters as planning signals, not final release gates.

Action plan for IT teams: inventory, test, and remediate​

Here is a recommended, prioritized checklist to reduce risk and be ready for NTLM‑disabled defaults. Follow these steps in a lab and then in increasingly larger production cohorts.
  • Enable enhanced NTLM auditing now on a representative set of endpoints and servers (Windows 11 24H2 and Server 2025). Capture the new event types and the service attribution the logs provide.
  • Build a dependency map from audit logs: which services, servers, and binaries depend on NTLM? Prioritize production-critical paths (authentication to file servers, AD replication-adjacent services, mission-critical apps).
  • Identify appliances and non‑domain services that cannot support Kerberos and plan exception lists or device replacements. Use SMB NTLM blocking exceptions sparingly and document them carefully.
  • Move services to Negotiate and Kerberos where possible. Verify SPNs, use setspn to register correct SPNs, and avoid connecting by IP address when Kerberos is required. Use Microsoft’s Kerberos troubleshooting guidance to resolve SPN and ticketing issues.
  • Use SMB signing, channel binding, and EPA where applicable to reduce NTLM relay vectors. Enable these defaults in a phased manner and verify behavior in active directories and Exchange deployments.
  • Pilot blocking policies in a small group: use Group Policy and PowerShell to selectively block NTLM on SMB clients while allowing exceptions. Expand the pilot after verifying no breakage.
  • Test Local KDC and IAKerb in lab when they become available in Insider or preview builds. Validate local-account and remote-topology authentication flows to avoid surprises when those features roll out broadly.
  • Harden endpoints with Credential Guard where hardware and application compatibility allow; this reduces the risk associated with older NTLM variants.
  • Communicate with application owners and vendors early; demand Kerberos support for new deployments and prioritize Kerberos enablement in vendor roadmaps.
  • Maintain a rollback plan: keep policy controls and documented exception lists to re-enable NTLM quickly if a critical, unforeseen failure occurs during staged enforcement.

Migration gotchas and troubleshooting hints​

  • SPNs and DNS matter: Kerberos selects the SPN based on how clients address services. If applications reference a service by IP or an alternative name without a matching SPN, Kerberos won’t be used and NTLM will be attempted instead. Use setspn and DNS hygiene to fix these cases.
  • Service-level attribution simplifies fixes: the new NTLM logs show which service used NTLM, not just which user or machine. Use that data to patch binaries, update configuration, or file vendor tickets.
  • Non‑Windows services: Linux CIFS/SMB implementations and appliances may need configuration changes to use Kerberos (both machine principals and properly configured keytabs). Schedule change windows and test authentication with Kerberos tickets before removing NTLM exceptions.
  • LocalKDC limitations: early reports indicate Local KDC exists in Server 2025 builds but may be feature‑gated; don’t rely on it for immediate remediation until Microsoft enables it broadly and documents operational behavior. Expect to test Local KDC in preview channels.

Security upside: measurable reduction in attack surface​

The practical security benefits of shifting to Kerberos-first defaults are material:
  • Kerberos provides stronger cryptographic assurances, mutual authentication in many cases, and better tooling for delegation and constrained delegation scenarios.
  • Blocking NTLM reduces the avenues attackers use for pass‑the‑hash and relay attacks.
  • Defaults that require administrators to explicitly enable NTLM flip the risk calculus: security teams gain a safer baseline across new deployments rather than relying on manual hardening that is easy to miss.
For security-minded organizations, the change should reduce incident frequency related to credential theft and lateral movement — assuming the migration is executed carefully and legacy edge cases are handled via documented exceptions or replacements.

Conclusion​

Microsoft’s decision to deprecate and ultimately disable network NTLM by default marks a major platform-level acceleration toward modern authentication. The company’s staged approach — beginning with auditing, followed by IAKerb/Local KDC compatibility investments, and ending with default disablement — is sensible and pragmatic, but it places the onus on IT teams to inventory, test, and remediate legacy dependencies.
Security teams should treat the current period as the final opportunity to find and fix NTLM usage with low disruption: enable enhanced NTLM auditing now, pilot SMB NTLM blocking and SMB signing in controlled groups, and prepare to test Local KDC and IAKerb in preview builds when they arrive. Organizations that act early will both reduce their attack surface and have a smoother upgrade path when Microsoft flips the default in a future major release.
The timeline contains targets — October 2026 and H2 2026 windows, plus an eventual “next major release” for final disablement — which Microsoft may adjust based on the telemetry and feedback it gathers during previews and enterprise rollouts. Treat those dates as planning signals and proceed with a measured program: audit, pilot, remediate, and document exceptions. The near-term work will be worth it — the long-term outcome will be fewer NTLM‑based attack vectors and a more robust, Kerberos‑first Windows ecosystem.
Source: Windows Central Microsoft will disable NTLM as standard in Windows
 
Microsoft is moving Windows toward a “Kerberos-first” default by phasing out New Technology LAN Manager (NTLM) as the out‑of‑the‑box network authentication option and shipping new Kerberos capabilities and telemetry to give administrators time to discover and remediate legacy dependencies before defaults flip. This is a staged program — extended auditing and eventing are available today, targeted Kerberos coverage features (IAKerb and Local KDC) are being introduced as platform improvements, and a future major Windows Server / client release will ship with network NTLM blocked by default while retaining explicit re‑enablement for exceptional compatibility needs.

Background / Overview​

NTLM (New Technology LAN Manager) is a decades‑old Microsoft challenge/response authentication protocol that was designed to work in a wide variety of early Windows networking scenarios — including workgroup setups and pre‑Kerberos environments. Over time attackers refined relay, replay, and pass‑the‑hash techniques that target NTLM artifacts, and NTLM’s lack of mutual authentication and weaker key derivation put it firmly in the “high‑risk fallback” category for modern enterprise networks.
Microsoft’s position today is straightforward: NTLM is deprecated, NTLMv1 is being removed or hardened in recent releases, and Windows will be shipped in a more secure‑by‑default posture that prefers Kerberos (via the Negotiate package) and actively helps organizations find and fix remaining NTLM usage before blanket enforcement. The company has published platform auditing, new Kerberos coverage features, and a multi‑phase rollout plan to reduce surprise outages while shrinking a well‑known attack surface.

Why Microsoft is disabling NTLM by default​

  • NTLM lacks mutual authentication guarantees and relies on challenge/response hash material that can be captured and relayed.
  • NTLM‑based flows have been central to numerous real‑world escalation and lateral movement techniques (relay attacks, pass‑the‑hash, and variants that coerce servers into authenticating to attacker-controlled endpoints).
  • Modern Kerberos implementations support strong ciphers (AES families), mutual authentication, and protocol extensions (channel binding, constrained delegation) that remove many of the practical downgrade and relay vectors NTLM exposes.
The aim is not immediate removal but secure defaults: disable network NTLM from being used automatically while keeping the binary present for explicit, time‑boxed compatibility needs. Microsoft couples this change with forensic‑quality auditing and platform enhancements so organizations can remediate rather than scramble.

Microsoft’s phased roadmap — what to expect and when​

Microsoft’s plan follows three practical phases: visibility, compatibility mitigations, and secure‑by‑default enforcement. Administrators should treat these phases as operational milestones with concrete calendar points to guide planning.

Phase 1 — Audit and measure (already rolling)​

  • What it delivers: Enhanced NTLM auditing for clients, servers, and domain controllers. New event channels under Microsoft‑Windows‑NTLM/Operational provide who, why, and where details (process name/PID, source IP, target service/SPN, reason ID for NTLM fallback, and NTLM version). Event IDs such as 4020/4021 (client), 4030/4031/4032 (DC/forwarded flows) appear in the new operational logs.
  • When: The auditing features are included in Windows 11, version 24H2 and Windows Server 2025 and have been rolling out via controlled feature updates. Microsoft’s documentation and controlled feature rollout (CFR) mean not every device sees the updates at the same time.
  • Why it matters: Without precise attribution of which process or device forced NTLM, remediation is guesswork. The new telemetry lets security teams map dependencies and prioritize fixes.

Phase 2 — Kerberos coverage for legacy scenarios (compatibility mitigations)​

  • What it delivers: Platform capabilities that broaden Kerberos applicability and reduce common fallback triggers:
  • IAKerb (Initial and Pass‑Through Authentication Using Kerberos): a mechanism to carry Kerberos messages through network topologies that previously required DNS/Netlogon/DC reachability, enabling Kerberos in constrained or proxying scenarios without opening additional inbound ports.
  • Local KDC (Local Key Distribution Center): a machine‑local KDC backed by the local Security Account Manager (SAM) so local accounts and certain offline or non‑domain scenarios can use Kerberos ticketing (AES by default) instead of falling back to NTLM.
  • When: Microsoft expects these capabilities and supporting component updates to be broadly available as previews and servicing updates through the Windows Insider and servicing channels, with many vendors and community reporting placing practical rollouts or previews across 2025–2026 and Microsoft indicating second‑half‑2026 windows for wider availability; exact chronology depends on controlled rollout decisions. Administrators should validate behavior in lab rings as these features arrive.

Phase 3 — NTLM disabled by default (secure‑by‑default enforcement)​

  • What it delivers: A future major Windows Server / client release will ship with network NTLM blocked by default. NTLM will remain in the OS and can be re‑enabled explicitly via policy for short, governed exceptions — but the out‑of‑the‑box behavior will be Kerberos‑first. Microsoft positions this as reducing population‑level exposure while providing an escape hatch for legacy or mission‑critical dependencies.
  • When: Microsoft has not published a single fix date for a global flip—planning targets and specific enforcement dates vary by feature: some NTLMv1 hardening behavior is already present in Windows 11 24H2 and Windows Server 2025; BlockNTLMv1SSO auditing was introduced in late‑2025 and will change default enforcement behavior if not explicitly configured on devices by October 2026. Overall, the full network NTLM default disablement is scheduled for a future major release after the compatibility mitigations are broadly available. Administrators should assume multi‑year runway and plan now.

Exact, actionable technical details administrators need to know​

The most operationally important facts are the event IDs, registry controls, and dates for staged changes. Use these as the backbone of your test and rollout plan.

NTLM enhanced auditing — where to look​

  • Audit channel: Applications and Services Logs → Microsoft → Windows → NTLM → Operational.
  • Key event IDs: 4020/4021 (client info), 4024/4025 (NTLMv1‑derived SSO audit/enforce), 4030–4033 (domain controller forwarded/processed NTLM requests).
  • Audit fields now include: process name/PID, username and domain, target machine and IP, SPN/target name, usage reason ID (why NTLM was selected), NTLM version and flags, session key status, MIC and channel binding status. These fields let you map whether an NTLM call was an application hard‑code, an IP‑address‑by‑SPN fallback, or a genuine offline/local account flow.

NTLMv1 hardening — BlockNTLMv1SSO registry control and dates​

  • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BlockNtlmv1SSO (REG_DWORD)
  • 0 = Audit (default when first rolled out)
  • 1 = Enforce (block NTLMv1‑derived SSO)
  • New events: Event ID 4024 — “Auditing an attempt to use NTLMv1‑derived credentials” (warning); Event ID 4025 — “Blocked attempt to use NTLMv1‑derived credentials” (error).
  • Timeline to plan against:
  • Late August / September 2025 — Audit logging for NTLMv1‑derived credentials enabled on Windows 11 24H2 clients.
  • November 2025 — Rollout to Windows Server 2025.
  • October 2026 — Microsoft will set the default value of BlockNtlmv1SSO to Enforce (1) via Windows update on devices that have not had the registry key deployed, unless organizations have proactively configured a policy. Plan remediation and targeted exceptions long before this date.

Kerberos hardening — RC4 and DefaultDomainSupportedEncTypes​

  • Microsoft published guidance to reduce RC4 usage for Kerberos service tickets following CVE‑2026‑20833.
  • Windows updates released on or after January 13, 2026 shipped audit/telemetry for weak Kerberos enctypes and introduced the registry gating value RC4DefaultDisablementPhase to let administrators opt into earlier enforcement tests.
  • Planned rollout phases:
  • Jan 13, 2026 — Initial deployment: audit events and tooling shipped; RC4DefaultDisablementPhase registry value introduced.
  • April 2026 — DefaultDomainSupportedEncTypes changed to AES‑SHA1 only for accounts lacking explicit msDS‑SupportedEncryptionTypes (i.e., the KDC will prefer AES).
  • July 2026 — Enforcement phase: audit‑only controls removed; enforcement enabled broadly. Microsoft recommends using the provided telemetry, remediating RC4 dependencies, or explicitly marking accounts that require RC4 via msDS‑SupportedEncryptionTypes if necessary.

IAKerb and Local KDC — what they change technically​

  • IAKerb lets Kerberos messages be passed or proxied between endpoints so Kerberos can be used even when direct DNS/Netlogon/DC discovery is not possible. It enables Kerberos for some topologies where NTLM previously was the only practical choice.
  • Local KDC provides a small KDC implementation on the endpoint that uses the local SAM so local accounts and certain offline scenarios can obtain Kerberos‑style tickets (using AES by default), eliminating a common reason Windows fell back to NTLM for local authentication.
  • Neither feature is a panacea — vendor appliances and hardcoded NTLM in third‑party binaries will still require vendor fixes or configuration changes — but they narrow the class of operational reasons NTLM persisted. Test these features in lab rings first.

Practical migration playbook — 0–180 days and beyond​

Plan remediation as a project, not a one‑off checklist. Below is a prioritized plan you can adapt to your environment.

0–30 days: discovery and baseline​

  • Enable NTLM enhanced auditing (Microsoft‑Windows‑NTLM/Operational) on a sampling of endpoints, servers, and domain controllers and ensure logs are forwarded to your SIEM.
  • Enable Kerberos encryption telemetry (Security events 4768/4769 enriched fields). Export sample logs to validate parsing.
  • Search code and configs for AcquireCredentialsHandle usage that passes explicit "NTLM" (common in legacy apps). Replace with "Negotiate" in dev/QA to verify compatibility.
  • Inventory service accounts and run PowerShell helpers Microsoft provides to detect accounts lacking AES keys or advertising RC4 only.

30–90 days: remediation pilots​

  • Triaging: map each NTLM event to an owner and remediation path (reconfigure to Negotiate/Kerberos, update vendor firmware, or isolate via segmentation).
  • Pilot Kerberos-first configuration in a non‑production ring: set client/service to prefer Negotiate, rotate/ensure service account keys include AES keys, and test SPNs and constrained delegation where used.
  • Test Local KDC / IAKerb as previews arrive in Insider/servicing channels for your platform build, and evaluate for print servers, VPN gateways, RAS, and appliance flows.

90–180 days: broader rollout preparation​

  • Plan for NTLMv1 SSO enforcement — collect multiple weeks of BlockNtlmv1SSO (4024) events and close high‑impact items.
  • Vendor engagement: obtain firmware/software update timelines from vendors for appliances that still use NTLM or RC4.
  • Governance: define strict exception policy for re‑enabling NTLM or RC4 — exceptions must be short‑lived, recorded, monitored, and owned by an application or device owner.
  • Automate: convert remediation tasks into configuration management playbooks (Intune GPOs, SCCM, registry preferences) and SIEM alerts for 4024/4025 and Kerberos KDCSVC 205/4768/4769 telemetry.

Concrete commands and checks you can use right now​

  • Enable NTLM operational log via command line:
  • wevtutil set‑log Microsoft‑Windows‑NTLM/Operational /e:true
  • Set BlockNTLMv1SSO to audit (safe starting point) on a test device:
  • reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f
  • Set BlockNTLMv1SSO to enforce (only for tested rings):
  • reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 1 /f
  • Monitor SIEM searches for common indicators:
  • Event ID 4024 with repeat counts from the same binary or host.
  • Event ID 4025 once enforcement is enabled.
  • Kerberos 4768/4769 fields showing RC4 as session encryption type or absence of AES keys.
Note: test any registry changes in a controlled environment before wide deployment. Many of these controls are intended to be managed via Group Policy or endpoint management tooling at scale.

Strengths and benefits of Microsoft’s approach​

  • Safer defaults for everyone: moving Windows to Kerberos‑first reduces the population exposure to a well‑known class of exploit techniques without requiring every admin to reconfigure settings manually.
  • Fix‑first strategy: shipping auditing and telemetry up front avoids the “flip switch and pray” outcome that breaks nightly production services.
  • Platform coverage: IAKerb and Local KDC address real operational gaps that historically forced NTLM fallback (no DC connectivity, local accounts, constrained network topologies).
  • Actionable telemetry: richer NTLM events and Kerberos encryption fields make it realistic to automate discovery and remediation at scale.
  • Aligned with Kerberos hardening: flipping KDC defaults away from RC4 toward AES raises the bar for Kerberoasting attacks and complements NTLM deprecation.

Risks, trade‑offs, and the things that will hurt if you don’t plan​

  • Operational disruption: legacy applications, embedded devices, printers, industrial control appliances, and third‑party network appliances can still assume NTLM. When defaults are hardened, those devices may fail authentication.
  • Vendor lag: many appliance vendors update on slower cadences. Expect coordination problems and temporary compensating controls (ACLs, network segmentation, jump hosts).
  • Exception creep: leaving NTLM or RC4 exceptions permanently re‑enabled defeats the purpose. Exceptions must be strictly governed and time‑boxed.
  • Hybrid and cloud complexity: Azure AD/Entra hybrid scenarios, RDP‑gateway or VPN‑to‑AD flows, and cloud‑backed proxies can surface unexpected fallbacks to NTLM. Test hybrid use cases explicitly.
  • Operational readiness gap: not every organization has SIEM coverage or the incident response staffing to triage hundreds of NTLM/RC4 findings; remediation will require investment in process and automation.

Governance: how to keep exceptions short and safe​

  • Treat any explicit re‑enablement of network NTLM or RC4 as a high‑risk, time‑boxed exception.
  • Require:
  • A named owner for each exception.
  • A documented mitigation plan and expected sunset date.
  • Continuous monitoring (SIEM alerts for 4024/4025 / KDCSVC 205).
  • Quarterly review of outstanding exceptions until remediation is complete.
  • Where re‑enablement is unavoidable, enforce microsegmentation and least‑privilege access to reduce the blast radius.

Vendor engagement checklist (for OEMs, appliances, and SaaS connectors)​

  • Request vendor roadmaps and target dates for Kerberos/Negotiate support.
  • Ask whether their product supports:
  • Negotiate stack instead of explicit NTLM.
  • SPN configuration and AES keys for service accounts.
  • msDS‑SupportedEncryptionTypes or equivalent configuration to advertise AES.
  • Escalate vendor exceptions early and require documented fix commitments with dates.

Final recommendations — an operational checklist you can adopt this week​

  • Immediately enable NTLM enhanced auditing and forward logs to your SIEM for 30 days of baseline telemetry.
  • Search codebases and vendor configurations for explicit "NTLM" package usage and plan mechanical fixes to use "Negotiate" where possible.
  • Inventory service accounts, ensure AES keys are present, and run Microsoft’s PowerShell helpers for Kerberos/RC4 detection before April 2026 enforcement windows.
  • Start a remediation working group (AD + apps + security + network + procurement) and put the key dates (Jan 13, 2026; April 2026; July 2026; October 2026) on your change calendar for targeted actions.
  • Treat exceptions as temporary, logged, owned, and monitored.

Conclusion​

Microsoft’s move to ship Windows in a Kerberos‑first, secure‑by‑default state is a major platform hardening that closes a repeatable attack surface used in lateral movement and privilege escalation. The company has deliberately chosen a measured path: deploy high‑fidelity auditing now, ship platform mitigations to broaden Kerberos applicability, and then flip safer defaults once telemetry shows the ecosystem is ready. For administrators the implication is unambiguous — begin discovery and remediation today, govern exceptions tightly, and engage vendors aggressively. The alternative is painful: when defaults flip, poorly prepared environments will experience outages and increased operational cost. Act now to convert a planned platform change into a controlled security upgrade rather than an emergency incident.
Source: Petri IT Knowledgebase Microsoft to Disable NTLM by Default in Windows
 
Microsoft is preparing to ship Windows in a “secure‑by‑default” state that blocks network NTLM authentication unless an administrator explicitly allows it — a staged, multi‑phase program that replaces default NTLM fallbacks with a Kerberos‑first approach while shipping new Kerberos capabilities and enhanced telemetry to reduce compatibility pain.

Background​

NTLM (New Technology LAN Manager) arrived in the early 1990s as Microsoft’s challenge/response authentication protocol for Windows networks. For decades NTLM provided a simple, interoperable authentication mechanism that worked across workgroups, early domain models, and with a wide array of legacy products. Over time, however, security research and real‑world attacks exposed structural weaknesses in NTLM that make it a hazardous default in modern environments.
Kerberos has been the preferred domain authentication protocol on Windows since Windows 2000, providing ticket‑based, mutual authentication and stronger cryptography. But Kerberos historically requires certain infrastructure assumptions — reachable Key Distribution Centers (domain controllers), correctly registered service principal names (SPNs), DNS that works, correct time sync, and so on — which is why NTLM persisted as a safety valve for many environments. Microsoft’s new plan aims to fix the safety valve’s security problems by: 1) giving admins visibility into NTLM usage today, 2) broadening Kerberos applicability, and 3) flipping the default so NTLM is blocked unless explicitly permitted.

Why Microsoft is disabling NTLM by default​

The security case: NTLM’s persistent risk​

NTLM’s design and cryptographic foundations are decades old. The protocol lacks robust server authentication guarantees and relies on challenge/response hashes that can be captured, relayed, or cracked in several attack patterns that remain common in enterprise incidents.
  • NTLM relay attacks and coercion allow attackers to trick a client into authenticating to a malicious endpoint and then relay that authentication to another target.
  • Pass‑the‑hash and offline cracking of credential material remain practical when NTLM artifacts are exposed.
  • NTLMv1 in particular uses weak algorithms and is already being phased out; NTLMv2 is stronger but still represents a fallback with structural limitations compared with Kerberos.
Microsoft and the security community have observed NTLM‑based techniques used in advanced intrusions, which is a key reason the company classifies NTLM as deprecated and is moving toward a default‑off posture. Disabling NTLM by default is intended to remove a well‑known, high‑impact attack surface from the majority of Windows deployments while still allowing controlled exceptions where necessary.

Operational reality: compatibility and the need for a runway​

Microsoft did not announce a sudden removal. Instead, the company is executing a phased roadmap that provides time for discovery, remediation, and testing so that mission‑critical services are not unexpectedly broken. The program recognizes that many legacy applications, appliances, and network topologies still depend on NTLM, and it gives organizations tools and time to modernize.

The three‑phase roadmap — explained​

Microsoft’s announcement lays out three phases: visibility and auditing; Kerberos coverage for legacy scenarios; and finally, NTLM disabled by default in a future major release. Each phase builds on the last to reduce risk while preserving operational flexibility.

Phase 1 — Visibility and control (available now)​

Phase 1 focuses on giving administrators precise telemetry and audit data so they can answer three questions: who uses NTLM, why NTLM was selected, and where it is coming from.
  • Enhanced NTLM auditing is included in modern releases such as Windows 11 version 24H2 and Windows Server 2025. New Operational event channels provide process‑level attribution, source IP, target SPN, and the reason ID explaining why Kerberos did not succeed and NTLM was used. These richer logs are the foundation for any remediation plan.
This phase is effectively live: admins should enable the new NTLM operational logs, collect data centrally, and begin building an inventory of NTLM producers and consumers. Without this basic measurement, any default change risks operational surprise.

Phase 2 — Addressing the top NTLM pain points (target: second half of 2026)​

Phase 2 is the engineering phase that delivers Kerberos coverage for scenarios that historically forced NTLM fallback. Microsoft has signaled that the most important items here are:
  • IAKerb (Initial and Pass‑Through Authentication Using Kerberos): a mechanism to carry Kerberos messages or proxy Kerberos exchanges through constrained or non‑standard topologies (for example, when DNS/Netlogon or direct KDC reachability is absent). IAKerb aims to let Kerberos work where previously only NTLM would.
  • Local KDC (local Key Distribution Center): a machine‑local KDC implementation that can issue Kerberos‑style tickets backed by the local Security Account Manager (SAM), enabling local accounts (and certain workgroup/offline scenarios) to authenticate using Kerberos semantics instead of NTLM.
Microsoft expects these capabilities and supporting component updates to be available to devices running Windows Server 2025 and Windows 11, version 24H2 in the second half of 2026. The aim is to eliminate the most common reasons Kerberos fails and NTLM is used as a fallback. Independent reporting and Microsoft’s own blog align on this second‑half‑2026 window as the target for phase‑2 feature delivery.

Phase 3 — NTLM disabled by default (future major Windows release)​

Phase 3 is the switch: in the next major Windows Server and associated Windows client releases, network NTLM will be disabled by default. That means Windows will block network NTLM from being used automatically and prefer Kerberos/Negotiate for authentication. NTLM binaries will remain in the OS for explicit, administrator‑enabled compatibility exceptions, but the OS will assume a Kerberos‑first posture out of the box. Microsoft will make new policy controls available so admins can re‑enable NTLM for specific targets if required.

Key technical clarifications and timelines​

  • Auditing availability: Enhanced NTLM auditing arrived with Windows 11 24H2 and Windows Server 2025 and is available now to help you find NTLM dependencies.
  • Phase 2 availability target: Microsoft has stated a second‑half‑2026 target for the Kerberos coverage features (IAKerb, Local KDC) and associated core‑component updates. This is a target window and Microsoft may adjust engineering schedules.
  • NTLMv1 hardening/removal: NTLMv1 has been removed or strongly hardened in recent releases; Microsoft’s NTLMv1 deprecation/hardening schedule includes auditing rollouts in 2025 and a default enforcement registry change for BlockNTLMv1SSO slated in guidance for October 2026 unless administrators explicitly set a value. Administrators should treat those dates as operational markers in planning.
  • Related defaults: Microsoft already shipped security hardening for SMB and LDAP: SMB signing is required by default in some SKUs, LDAP channel binding and Extended Protection for Authentication (EPA) have been enabled by default for AD CS and Exchange where applicable as part of the secure‑by‑default hardening program that complements NTLM changes. These mitigations reduce NTLM relay feasibility and are part of the risk‑reduction landscape.
Where Microsoft provides calendar cues (for example, “second half of 2026” or “October 2026”), treat those as planning targets. They reflect Microsoft’s public guidance and internal timelines but could shift as engineering and servicing decisions evolve.

How “disabled by default” differs from deprecation or removal​

  • Deprecation signals that a feature will no longer receive feature development and may be removed in the long run, but it typically remains fully functional in the interim.
  • Disable by default means the code remains present in the OS but is configured so that the behavior (here, network NTLM authentication) is blocked unless an administrator explicitly re‑enables it. This is a safer, staged approach: it reduces exposure at scale while preserving an escape hatch for legacy compatibility. Microsoft explicitly chose "disable by default"removal to avoid breaking critical applications unexpectedly.

Practical impact — what breaks, and what to watch for​

Disabling NTLM by default will surface compatibility gaps in real environments. Common trouble spots include:
  • Legacy applications and appliances (backup software, monitoring agents, network printers, NAS devices, some load balancers) that authenticate only with NTLM.
  • Services that authenticate using IP addresses rather than hostnames, or services with misregistered SPNs.
  • Workgroup or local‑account scenarios that historically relied on NTLM when domain controllers were not reachable.
  • Appliances and third‑party devices that cannot be upgraded quickly and still expect NTLM.
The good news is Microsoft will continue shipping NTLM in the OS and provide policy and exception controls so organizations can continue to operate while they fix or replace legacy dependencies. But that safety net is intentionally narrow and time‑bounded: organizations should not treat policy exceptions as a long‑term solution.

Concrete migration and mitigation playbook​

Start now. The runway exists, but remedial work can be time consuming.

Immediate steps (0–3 months)​

  • Enable enhanced NTLM auditing on endpoints, servers, and domain controllers. Collect and centralize Microsoft‑Windows‑NTLM/Operational events to identify sources and reasons for NTLM usage.
  • Inventory all devices and appliances that talk to Windows services (SMB, Exchange, LDAP, AD CS, IIS). Tag any that report NTLM usage and prioritize by business criticality.
  • Harden contact points now: enable SMB signing, LDAP channel binding where supported, and enable Extended Protection for Authentication (EPA) on Exchange/AD CS as appropriate to reduce relay attack risk. These settings are already being enabled by default in newer SKUs and can be rolled out proactively.

Medium horizon (3–12 months)​

  • Replace explicit NTLM calls with Negotiate in custom or third‑party applications so Kerberos is negotiated first. For many apps this is a code/setting change to use the Negotiate security package instead of explicitly requesting NTLM.
  • Test Local KDC and IAKerb previews in lab environments when available via Windows Insider or servicing rings; validate local‑account and disconnected scenarios to determine which devices can switch to Kerberos semantics.
  • Work with vendors to get firmware/software updates for appliances and embedded devices that only support NTLM. Prioritize replacements for devices that cannot be updated.

Pre‑enforcement (12–24 months)​

  • Run NTLM‑off pilot configurations in non‑production rings using the new blocking policies and exception lists; measure business impact and remediate.
  • Lock down exceptions: when using policy to re‑enable NTLM for specific targets, document the business justification, expiration date, and remediation plan. Do not leave exceptions open indefinitely.
  • Ensure Kerberos robustness: review SPNs, time sync, DNS, and KDC reachability across sites. Make sure service tickets are issued under AES enctypes and that RC4/weak enctypes are removed or tightly governed. Microsoft has signaled a mid‑2026 move toward AES defaults and RC4 deprecation that organizations should align to.

Administration and detection tips​

  • Use the Microsoft‑Windows‑NTLM/Operational event channel; key event IDs give you the process name, reason ID for fallback, and SPN/target information. Aggregate these events to quickly map device/application owners.
  • For SMB, consider using the new SMB NTLM blocking to enforce Kerberos for SMB connections while permitting exception lists for known legacy servers. Combine this with SMB signing to reduce relay opportunities.
  • Monitor Defender for Identity and related telemetry for suspicious authentication patterns, as these sensors can detect relay attempts and lateral movement that exploit NTLM flows.

Strengths of Microsoft’s approach​

  • Measured, instrumented rollout — giving admins visibility before changing defaults reduces surprise and allows prioritized remediation.
  • Engineering mitigations — building features like IAKerb and Local KDC directly addresses the operational reasons NTLM persisted, not just the security problem.
  • Complementary hardening — enabling EPA, LDAP channel binding, and SMB signing by default where possible removes practical attack vectors while Kerberos improvements come online.
These are meaningful strengths: Microsoft is not merely flipping a switch, it is delivering telemetry, compatibility features, and system hardenings to make a Kerberos‑first world feasible.

Risks and open questions​

  • Third‑party ecosystem readiness: many appliances and vendor devices are slow to update; organizations with specialized hardware may face extended compatibility windows.
  • Operational complexity: accurate inventory, per‑app testing, and exception governance require people and process investment many organizations have deferred.
  • Timeline slippage risk: Microsoft’s targets (for example, second half of 2026 for phase 2) are engineering commitments but not immutable dates; delays could change the planning cadence and require recoordination.
Administrators should plan for these risks by starting early, prioritizing the highest‑risk NTLM consumers, and requiring vendor remediation timelines as part of procurement lifecycle changes.

Final analysis — what this means for Windows shops​

This policy shift is both overdue and consequential. Removing a decades‑old insecure fallback from the default configuration materially raises the cost of several widely‑used attack techniques. Microsoft’s three‑phase approach — visibility, mitigation, and default change — is the practical path to reach that goal without breaking the ecosystem overnight.
For IT organizations, the practical takeaway is simple: treat this as an operational project, not an optional security patch. Start with telemetry today, remediate high‑impact NTLM usage, pilot Kerberos‑first configurations in lab rings, and insist vendors provide NTLM‑free firmware and appliances. Organizations that use the runway wisely will reduce risk and avoid last‑minute firefighting when defaults change. Organizations that wait will inherit a sharper, more painful migration when the switch is finally flipped.

Executive checklist (what to do this quarter)​

  • Enable Microsoft‑Windows‑NTLM/Operational auditing and centralize logs.
  • Inventory and classify NTLM‑using endpoints by business criticality.
  • Harden SMB, LDAP, and Exchange endpoints (SMB signing, LDAP channel binding, EPA) where supported.
  • Start vendor outreach for appliance updates or replacement plans.
  • Build test plans for Local KDC and IAKerb when they enter preview; plan pilot windows for the second half of 2026.
Microsoft’s move to disable NTLM by default is a milestone in Windows security: it reduces a long‑standing, exploitable failure mode and forces ecosystems to adopt modern authentication patterns. The work to get there is operationally real, but the payoff — fewer relay attacks, fewer credential‑extraction paths, and a stronger default security posture — is worth the effort. Start the work now; the platform’s telemetry and upcoming Kerberos improvements are explicitly designed to help you succeed.
Source: The Windows Club Microsoft to disable NTLM by default in Windows
 
Microsoft has declared an end of the road for NTLM as a secure default: network NTLM authentication will be blocked by default in upcoming Windows client and server releases, replaced by Kerberos-first behavior and a multi-year migration plan that delivers auditing, compatibility tooling, and enforced secure defaults.

Background​

NTLM (New Technology LAN Manager) has been a fixture of Windows networking since the early 1990s. For decades it provided a workable fallback authentication mechanism for scenarios where Kerberos was unavailable or impractical. Over time, however, the protocol’s cryptographic foundations and design assumptions have become obsolete in the face of modern attack techniques. Microsoft now classifies all versions of NTLM (including LANMAN, NTLMv1 and NTLMv2) as deprecated and has published a staged roadmap to move the platform to a Kerberos-first posture.
This is not a sudden flip of a switch. Microsoft’s plan is deliberately phased: administrators already have enhanced auditing in Windows 11 version 24H2 and Windows Server 2025; additional compatibility features such as IAKerb and a Local Key Distribution Center (Local KDC) are slated for the second half of 2026; and a later major Windows release will change the default to block network NTLM authentication. The protocol will remain present in the OS for escape and troubleshooting, but the system will no longer select NTLM automatically.

Why Microsoft is moving away from NTLM​

The technical problems in plain language​

NTLM was designed in an era with very different threat models and computing constraints. The protocol has several structural weaknesses that make it unsuitable as a secure default today:
  • Weak cryptography and legacy algorithms: NTLM’s primitives were not designed to withstand modern offline and active attacks. Over decades, cryptanalysis and improved attacker capabilities have eroded the protocol’s confidentiality and integrity assurances.
  • Replay and relay vulnerabilities: Attackers can capture NTLM authentication exchanges and replay or relay them to impersonate users or access services — a long-standing and practical class of attack in enterprise networks.
  • Lack of reliable mutual authentication: NTLM does not natively provide strong mutual authentication guarantees, which makes man-in-the-middle and coercion attacks easier compared with Kerberos.
  • Fallback and compatibility complexity: Because many components historically fell back to NTLM when Kerberos failed, the protocol persisted as a safety net and a vector for compromise.

Why Kerberos is the preferred replacement​

Kerberos addresses many of NTLM’s weaknesses with a ticket-based, time-limited model and by enabling mutual authentication by default. Key Kerberos advantages include:
  • Time-stamped tickets with expiry, which reduce the window for replay.
  • Mutual authentication so clients verify servers and vice-versa.
  • Stronger cryptography choices and extensibility for modern ciphers and channel binding.
  • Least-privilege delegation models that are more expressive and auditable.
Moving the OS to prefer Kerberos and to only fall back to NTLM when explicitly required reduces the attack surface and aligns Windows with modern authentication best practices.

The three-phase rollout — what to expect​

Microsoft’s rollout is structured to minimize operational disruption. Each phase builds tools and protections while giving IT teams time to identify and remediate dependencies.

Phase 1 — Visibility and auditing (available now)​

  • Enhanced NTLM auditing features are included in Windows 11 version 24H2 and Windows Server 2025.
  • New event channels (Microsoft-Windows-NTLM/Operational) provide richer telemetry: who used NTLM, which process triggered it, which machine name and IP were involved, NTLM version in use, channel-binding and service-binding status, and whether session keys or MIC (message integrity check) protections were present.
  • Audit events are controlled via Group Policy settings such as NTLM Enhanced Logging and Log Enhanced Domain-wide NTLM Logs (for domain controllers).
  • The default for these enhanced audit events is enabled, so administrators should review logs immediately to map dependencies.
Why this matters: You cannot eliminate what you cannot measure. The detailed logs make it possible to inventory NTLM usage, identify the specific applications and endpoints relying on it, and prioritize remediation.

Phase 2 — Compatibility tooling and kerberized alternatives (expected H2 2026)​

  • Microsoft plans to ship IAKerb (Initial Authentication using Kerberos) and a Local Key Distribution Center (Local KDC) to address common scenarios that forced NTLM usage:
  • Local account authentication where a domain controller isn’t reachable.
  • Hard-coded protocol choices inside legacy components that select NTLM.
  • Scenarios that previously required fallbacks because Kerberos could not be used.
  • Core Windows components will be updated to prefer Kerberos where possible and to use these compatibility primitives instead of falling back to NTLM automatically.
Why this matters: These tools are Microsoft’s effort to provide drop-in alternatives that let legacy apps authenticate securely without rewriting them. That reduces the “break everything” risk many organizations fear when deprecations arrive.

Phase 3 — Disabled by default (future major Windows release)​

  • Network NTLM authentication will be blocked by default on the next major Windows Server and corresponding client releases.
  • NTLM will remain present in the operating system and may be re-enabled through Group Policy or registry keys for emergency compatibility, but it will no longer be used automatically.
  • Microsoft has not published a firm enforcement date for the Phase 3 default change; it is the logical end-state of the phased rollout.
Why this matters: The long-term posture is “secure by default.” Organizations that delay planning will face forced migration windows or emergency re-enablement decisions.

What’s already changed (practical items admins should know today)​

  • NTLMv1 removal and deprecation: NTLMv1 has been removed in modern releases and NTLMv2 is being deprecated in default behaviors — confirm on your platform versions whether NTLMv1-derived credentials are blocked or audited.
  • SMB, LDAP, and Exchange hardening: Microsoft has enabled mitigations such as Extended Protection for Authentication (EPA), LDAP channel binding, and SMB signing defaults in recent server releases, which make relay and coercion harder.
  • Credential Guard: When enabled, Credential Guard can protect against many NTLM-derived credential theft scenarios and mitigations should be considered in high-risk systems.
  • New registry controls: Microsoft introduced registry keys like BlockNtlmv1SSO that let administrators move between “Audit” and “Enforce” modes for NTLMv1-derived credential generation; one change is scheduled to flip Audit to Enforce by default in the future unless administrators deploy the key explicitly.

Administrator playbook — a step-by-step migration checklist​

  • Enable and review enhanced NTLM auditing now.
  • Turn on the Microsoft-Windows-NTLM/Operational logs clients, servers, and domain controllers.
  • Make use of Group Policy for centralized configuration (NTLM Enhanced Logging, Log Enhanced Domain-wide NTLM Logs).
  • Inventory every NTLM consumer.
  • Identify user accounts, service accounts, applications, services, and devices that trigger NTLM authentication.
  • Include unmanaged devices, network appliances, print servers, and third-party software in the scan.
  • Prioritize critical workloads.
  • Rank services by sensitivity and business impact. Migrate domain controllers, file servers, Exchange and application backends before low-risk endpoints.
  • Test Kerberos compatibility in a lab.
  • Validate SPNs, constrained delegation, and time synchronization (Kerberos is sensitive to clock skew).
  • Test Local KDC or IAKerb when they become available in a staged environment.
  • Deploy mitigations for NTLM-relay risks.
  • Enable EPA where supported, enforce LDAP channel binding, enable SMB signing, and harden services that accept NTLM.
  • Deploy Credential Guard where feasible.
  • Use Credential Guard on devices that meet hardware/firmware requirements to protect credential secrets from extraction.
  • Communicate and plan helpdesk readiness.
  • Expect authentication errors during testing and early rollout. Provide scripts and rollback guidance for re-enabling NTLM where absolutely necessary.
  • Replace or modernize legacy applications.
  • Where possible, update apps to call Negotiate or to use Kerberos directly, and validate behavior across cross-domain and cross-forest scenarios.
  • Document emergency escape hatches.
  • Maintain a documented, auditable policy for re-enabling NTLM in controlled conditions and track usage.
  • Schedule phased production enforcement.
  • Aim to complete audits and prioritized migrations before Phase 2 compatibility tools arrive so you can leverage them for complex cases in H2 2026.

Common migration obstacles and how to handle them​

Legacy applications with hard-coded NTLM​

  • Problem: Some older apps explicitly select NTLM or expect NTLM-style responses.
  • Mitigation: Test with Local KDC and IAKerb once available; where impossible, isolate the app (network segmentation, service accounts with limited scope) or refactor the application.

Devices or appliances that don’t understand Kerberos​

  • Problem: Printers, network attached storage, and some older appliances may not support Kerberos/SPN semantics.
  • Mitigation: Use service or machine accounts, configure SMB signing or channel binding where possible, and plan replacement for long-lived unsupported hardware.

Offline or disconnected scenarios​

  • Problem: Kerberos requires KDC availability; mobile and remote scenarios can fall back to NTLM.
  • Mitigation: Local KDC aims to address some local-account scenarios; for true offline use, evaluate modern authentication tokens or VPN-based solutions that federate authentication.

Cross-forest and trusted domains​

  • Problem: Kerberos across trust boundaries needs correctly configured trusts and name resolution.
  • Mitigation: Validate trust configurations, ensure SPNs and DNS records are correct, and test constrained delegation behavior.

Managed service accounts and automation​

  • Problem: Service accounts used by automation or batch jobs may be scripted to use NTLM.
  • Mitigation: Convert automation to use Managed Service Accounts or certificate-based service identities where possible.

Security benefits — what organizations gain​

  • Reduced attack surface: Blocking NTLM by default eliminates a broad class of relay, replay, coercion and pass-the-hash style attacks that rely on NTLM’s fallback behavior.
  • Stronger cryptography and mutual authentication: Kerberos’s design and modern ciphers make many passive and active attacks more difficult to execute.
  • Better telemetry and enforcement: Enhanced audit logs let security teams track and triage real dependencies instead of guessing.
  • Alignment with passwordless initiatives: The move complements Microsoft’s work toward phishing-resistant, key-based or passwordless authentication schemes.

Risks and unintended consequences — what to watch for​

  • Operational disruption: Misconfigured Kerberos (SPNs, time sync, DNS) or overlooked NTLM consumers can produce service outages that impact business operations.
  • Over-reliance on escape hatches: The availability of Group Policy or registry-based re-enablement may become a crutch; re-enabling NTLM should be a temporary mitigation, not a long-term policy.
  • Incomplete inventory coverage: Shadow IT and unmanaged endpoints often hide NTLM usage; failure to include these can produce last-mile breakages.
  • Third-party ecosystem readiness: ISVs and vendors may be slow to update legacy products; procurement teams should require Kerberos compatibility in new purchases.
  • Human and process costs: Helpdesk load will spike during migrations if defects are not adequately tested and communications with business units are lacking.

Technical clarifications and what’s verifiable today​

  • NTLM auditing is shipped and enabled by default in Windows 11 24H2 and Windows Server 2025; administrators should check the new Microsoft-Windows-NTLM/Operational event channels and related Group Policy settings to begin mapping usage.
  • NTLMv1 removal has already occurred in modern client and server releases; the platform now provides registry and policy controls to move NTLMv1 SSO behavior from Audit to Enforce mode, with a planned default flip for those settings unless administratively configured.
  • Microsoft’s compatibility tooling roadmap explicitly names IAKerb and Local KDC as part of the H2 2026 phase, intended to replace common NTLM fallbacks. These are pre-release capabilities at the time of the announcement.
  • Phase 3 enforcement date is not yet set. While Microsoft has declared the intent to block network NTLM by default in a future major release, no specific calendar date for the default-change enforcement has been published. Administrators should not assume an immediate deadline but must still act early to avoid last-minute crises.
Any claim about exact enforcement dates beyond the vendor’s published guidance should be treated cautiously until Microsoft publishes a firm release schedule for that Phase 3 change. Administrators should monitor product release notes and the platform’s official guidance for definitive timing.

Practical tools and commands to get started (high level)​

  • Check the new NTLM operational logs in Event Viewer under:
  • Applications and Services Logs > Microsoft > Windows > NTLM > Operational
  • Use Group Policy settings:
  • Administrative Templates > System > NTLM > NTLM Enhanced Logging
  • Administrative Templates > System > Netlogon > Log Enhanced Domain-wide NTLM Logs
  • Consider Defender for Identity and server hardening:
  • Monitor typical NTLM relay patterns and unusual authentication sequences.
  • Ensure LDAP channel binding and SMB signing are enabled where supported.
  • Evaluate Credential Guard for endpoint protection where hardware allows.
(Implementations should follow vendor documentation and change control processes; these bullets are a starting checklist rather than prescriptive commands.)

The organizational implications​

For security teams, this announcement is an opportunity to modernize authentication posture and reduce a large, well-understood class of enterprise exposures. For IT operations, it’s an operational program: inventory, test, remediate, and govern the many endpoints and services that still rely on NTLM.
Executive sponsors and risk owners should prioritize the project because the change reduces systemic risk and because the transition will be safer and less expensive if it’s done methodically rather than under emergency conditions.
Procurement and vendor management must be involved: any future deployments should require Kerberos/Negotiate-compatible authentication or provide mitigation contracts and timelines for legacy dependencies.

Final analysis — strengths, trade-offs, and the right posture​

Microsoft’s phased approach is pragmatic and rooted in lessons learned from past deprecations. The strengths of the plan are clear:
  • It starts with measurement (audit), which reduces blind remediations.
  • It provides compatibility tooling (IAKerb, Local KDC) ahead of hard enforcement, which reduces breakage risk.
  • It keeps an emergency escape hatch so that critical business processes can continue while migrations proceed.
However, the trade-offs are real. The change does not remove NTLM overnight, but it does create a sustained operational program that many organizations will underestimate. The biggest single risk is human and procedural: failing to inventory shadow use, misconfiguring Kerberos, or treating re-enablement as a long-term option.
The recommended posture is straightforward: treat NTLM deprecation like a security project with budget, timelines, testing gates, and executive oversight. Start with the auditing tools in Windows 11 24H2 and Windows Server 2025, map dependencies, pilot Phase 2 features when available, and schedule controlled enforcement windows with business owners.
If you want a single guiding principle: assume defaults will trend more secure, not more permissive. Plan to move services to Kerberos (or newer, passwordless mechanisms) rather than to rely on long-term exceptions.

Conclusion​

The end of NTLM as the OS default is both overdue and consequential. Microsoft’s three-phase plan — immediate auditing, compatibility tooling in 2026, and eventual default blocking in a future major release — offers a practical path for organizations to migrate without breaking essential business services. But the work falls to IT and security teams: run the audits now, inventory and prioritize remediation, test new compatibility features in non-production, and build your migration program around the reality that secure defaults are coming and will become the new normal. The organizations that prepare deliberately will avoid crisis migrations and hard choices later; those that delay will almost certainly face painful, last-minute fixes when defaults finally flip.
Source: WinBuzzer Microsoft to Disable NTLM Protocol by Default in Future Windows Releases
 
Microsoft's decision to ship Windows in a "secure-by-default" state by disabling NTLM (NT LAN Manager) authentication by default marks one of the most consequential shifts in Windows security policy in decades, and it will force enterprises to confront years of legacy dependencies or accelerate a migration to Kerberos-based, phishing-resistant authentication.

Background​

NTLM is a family of legacy authentication protocols that has been part of Windows since the early 1990s. Once a workhorse for Windows network authentication, NTLM is now widely understood to be cryptographically weak and susceptible to a number of practical attacks — including relay, pass-the-hash, replay, and man-in-the-middle techniques — that enable lateral movement and domain compromise. Because Kerberos has been the preferred Windows authentication protocol for years, the new initiative is not a repudiation of Kerberos but a targeted push to remove the NTLM fallback that still exists across many environments.
Microsoft is executing the change as a multi-phase program: enhanced visibility and auditing are available today in recent Windows releases; capability improvements to remove key blockers (notably IAKerb and a Local Key Distribution Center (Local KDC)) are slated for rollout in 2026; and a future "next major Windows release" will flip the default to block network NTLM, requiring explicit policy to re-enable it. This staged approach is intended to reduce breakage while driving customers toward a modern, Kerberos-first authentication posture.

Why this matters now​

NTLM has persisted largely due to application compatibility and network topologies that prevent Kerberos from working reliably — things like services that authenticate by IP address instead of SPN, remote machines with no line-of-sight to domain controllers, or local accounts used across machines. Those scenarios kept NTLM alive as a reliable fallback, but also as a high-value target for attackers. The security community and Microsoft alike have for years recommended disabling NTLM where possible; the new default represents an industry-leading move from recommendation to enforced baseline.
For IT teams, the implication is clear: the era of passively accepting NTLM fallbacks is ending. Organizations that continue to rely on NTLM for production authentication risks exposure to credential relay and credential theft attacks that increasingly drive ransomware and enterprise compromises. Conversely, environments that move proactively to Kerberos-first configurations — and use the new auditing and mitigation tooling — will dramatically reduce their attack surface for authentication-based lateral movement.

Overview of Microsoft's three-phase plan​

Phase 1 — Enhanced visibility (available now)​

Microsoft has shipped improved NTLM auditing in Windows 11, version 24H2 and Windows Server 2025. These logs provide much richer telemetry than older NTLM events: administrators can see the account, calling process, why NTLM was chosen, which machine and IP were involved, and whether NTLMv1 was negotiated. The enhanced logs are enabled by default and can be controlled through Group Policy, making it straightforward for teams to build an inventory of NTLM usage across clients, servers and domain controllers.
This capability is the essential first step: before you can phase NTLM out, you must know where and why it is being used. The new audit events answer the classic "who, why, where" questions that previously required laborious packet captures and application-level triage.

Phase 2 — Address the blockers (second half of 2026)​

Microsoft's roadmap calls for introducing features that directly remove the most common technical reasons Kerberos fails and NTLM takes over. Two of the headline items are:
  • IAKerb (Initial and Pass Through Authentication Using Kerberos): an extension to Kerberos that allows a client without direct line-of-sight to a Domain Controller to authenticate through a server that does have DC connectivity. IAKerb proxies Kerberos tickets through intermediary servers using the Negotiate extension, preserving Kerberos security properties while enabling Kerberos in segmented networks.
  • Local KDC (Local Key Distribution Center): a KDC implementation bound to the local machine’s Security Account Manager (SAM). This lets local and service accounts use Kerberos-compatible ticketing for authentication scenarios that previously required NTLM, and it ships with stronger defaults (AES-based ciphers) for local account authentication.
Microsoft has signaled that these capabilities, together with updates that make core Windows components prefer Negotiate/Kerberos over NTLM, will remove the technical justifications for NTLM in many environments. While Microsoft expects Phase 2 features to appear in the second half of 2026, customers should treat the schedule as optimistic and plan for testing and pilot deployments ahead of any default-flip.

Phase 3 — NTLM disabled by default (next major Windows release)​

In the final stage, Microsoft will ship Windows with network NTLM blocked by default. NTLM will remain present in the OS for extreme legacy compatibility, but the out-of-the-box behavior will be a Kerberos-first, NTLM-blocking posture — and re-enabling NTLM will require an explicit administrative policy change. This final stage is meant to harden newly deployed systems and prevent new deployments from reintroducing NTLM as default behavior. Microsoft has emphasized that this change is about default behavior and not about completely removing NTLM from the product immediately.

The technical reality: what will change for admins and developers​

Better logging to remove blind spots​

The new NTLM logs provide actionable fields such as Usage Id/Reason for outgoing NTLM calls, the client process name and PID, and domain-controller-level traces of forwarded NTLM authentication. These fields make it much quicker to identify which applications or services hardcode NTLM or rely on name resolution behaviors that force an NTLM fallback. The logs are surfaced in Event Viewer under Microsoft > Windows > NTLM > Operational and are controllable by updated Group Policy settings.
Administrators should integrate these events with SIEM systems and create prioritized remediation lists: servers with high-volume NTLM activity tied to business-critical apps should be tested first, while clearly deprecated endpoints can be scheduled for rapid migration or isolation.

Kerberos for the scenarios that previously forced NTLM​

IAKerb and Local KDC are explicit engineering efforts to close the gap where Kerberos could not reach. For example:
  • Remote terminals that cannot reach a DC can now use IAKerb to flow Kerberos messages via an intermediary server.
  • Local accounts used across machines can authenticate with Kerberos through Local KDC rather than using NTLM-based mechanisms that lack the same cryptographic protections.
Both features aim to minimize changes required by application developers while keeping enterprise authentication based on modern cryptography. However, IAKerb is a protocol extension and Local KDC is a new service; both introduce operational variables that must be tested alongside existing network architecture and security controls.

SMB and NTLM blocking​

Microsoft has already moved to support SMB NTLM blocking and to require SMB signing by default in newer releases. These changes limit the ability for an attacker to coerce a client into falling back to NTLM over file-share protocols, and SMB signing prevents tampering and many relay-based exploits. Administrators should expect group-policy controls and exception lists to manage selective compatibility, but the overall direction is to stop NTLM from being the "least effort" option for authentication on Windows networks.

Security benefits — measurable reductions in risk​

Shifting the default away from NTLM yields multiple, concrete security improvements:
  • Eliminates the most common vector for NTLM relay attacks, which have been used repeatedly in enterprise breaches.
  • Prevents pass-the-hash style abuses in many real-world configurations where NTLM-derived credentials could be replayed.
  • Reduces credential exposure by forcing Kerberos ticket-based authentication, which binds identities more tightly to services and supports stronger cipher suites.
  • Improves auditability, because Kerberos flows are more amenable to behavioral analysis and IAKerb/local KDC telemetry is designed to be visible to administrators.
These are not theoretical gains: Microsoft itself and independent security researchers have long recommended deprecating NTLM because it is a higher-probability vector for lateral movement and domain takeover. The move to block NTLM by default therefore materially improves the baseline security posture of new Windows installations.

Practical migration guidance for IT teams​

Microsoft's guidance is intentionally prescriptive: you should treat this as a project with clear phases, milestones and testing gates. Below is a practical migration playbook you can operationalize now.

1. Inventory and visibility (now)​

  • Enable the enhanced NTLM auditing in Windows 11 24H2 and Windows Server 2025 across representative hosts and domain controllers to map NTLM usage patterns. Use the new event IDs and fields to tie NTLM use back to application names and PIDs.

2. Categorize and prioritize​

  • Create triage buckets:
  • Category A: business-critical apps where Kerberos is supported but misconfigured.
  • Category B: apps that can be updated within a defined window.
  • Category C: legacy apps requiring vendor engagement or containment strategies.
  • Prioritize Category A for immediate change-control windows and testing.

3. Test Kerberos-first configurations in non-production​

  • Deploy Kerberos-only/NTLM-blocked Group Policy in a lab or staging environment.
  • Use exception lists and targeted blocking to simulate Phase 3 behavior on a small set of clients.
  • Validate by running the enhanced NTLM logging and Kerberos ticketing diagnostics.

4. Engage developers and vendors​

  • Where server-side code or 3rd-party software uses IP-based authentication, NTLM will often be the fallback. Require vendor timelines for Kerberos support or provide mitigations such as service principal name (SPN) configuration, DNS/host header changes, or reverse proxy architectures that preserve Kerberos semantics.

5. Use compensating controls where migration is long​

  • For systems that cannot be moved quickly: enforce SMB signing, isolate services to secure subnets, and implement host-based network controls to minimize exposure until Kerberos-compatible upgrades are implemented.

Risks, tradeoffs, and things to watch​

Compatibility versus security tradeoff​

The most immediate operational risk is application breakage. Many internal web apps, legacy services and device-management systems expect NTLM and will fail silently or present authentication errors if NTLM is blocked without remediation. That’s why Microsoft’s staged rollout with robust logging is critical; but organizations must budget the engineering time to update applications, consult vendors, or implement mitigations.

Operational complexity of IAKerb and Local KDC​

While IAKerb and Local KDC are designed to preserve compatibility, they are new pieces in the authentication flow. That introduces operational complexity — new logs, new failure modes, and novel interactions with network segmentation, firewalls, and reverse proxies. Treat them as new platform features that require the same operational validation you would apply to any infrastructure change.

Attackers will pivot​

As NTLM is hardened, attackers will migrate to alternative vectors — for example, targeting misconfigured Kerberos delegation, exploiting AD-related misconfigurations, or focusing on identity platform weaknesses outside Windows authentication. Hardening NTLM reduces one class of high-value attack, but adversaries will adapt, making layered defenses and continuous monitoring essential. Microsoft’s own guidance continues to recommend complementary controls such as SMB signing, LDAP channel binding, and Defender for Identity monitoring.

Timeline uncertainty​

Microsoft has published target windows (enhanced logs in 24H2/Server 2025 today; Phase 2 in H2 2026; default NTLM blocking in a future major release) but has also noted that rollout timing can be gradual and that registry/policy overrides will remain available during the transition. Administrators should plan conservatively and avoid assuming an exact calendar date for the Phase 3 flip — instead, prepare to test and remediate on a rolling schedule. The NTLMv1 enforcement timeline is more concrete: Microsoft plans to flip the default BlockNTLMv1SSO registry behavior to Enforce in October 2026 if the key hasn't been centrally deployed.

How to measure success: KPIs and operational metrics​

Establish measurable indicators so stakeholders can see progress and get comfortable that the migration reduces risk without breaking business processes.
  • Reduction in NTLM-originated authentication events (count per week) across clients and servers.
  • Number of business-critical applications migrated to Kerberos or validated to work with Local KDC/IAKerb.
  • Percentage of endpoints with enhanced NTLM auditing enabled and integrated to SIEM.
  • Time-to-remediate for the top 10 NTLM-using services by volume and criticality.
  • Number of NTLMv1 events (target: zero in production) and successful enforcement of BlockNTLMv1SSO in controlled rings.
These KPIs help leadership understand progress and justify investment in remediation work — and they give security teams a quantifiable basis for tightening policies over time.

Executive-level considerations​

For CISOs and IT leaders, the change is both a security win and a project-management challenge. The strategic benefits are obvious: a default-block of NTLM by Microsoft will make new Windows deployments harder to misconfigure and will prevent new services from reintroducing the risk. The operational cost is that many organizations will need to invest in application modernization, vendor coordination, testing, and exception management.
Budgeting should include:
  • Engineering time for Kerberos troubleshooting and SPN fixes.
  • QA cycles for app compatibility testing.
  • Investment in logging, SIEM integration and incident response playbooks for authentication anomalies.
  • Training for helpdesk staff on authentication failure modes when NTLM is blocked.
Viewed holistically, the organizational investment pays off: fewer credentials leaked, fewer lateral-movement paths for attackers, and a significantly stronger baseline for identity security.

Final assessment: a security-first turning point​

Microsoft's phased plan to disable NTLM by default is a responsible, risk-managed approach to retiring an insecure legacy protocol while providing backward compatibility and tooling to ease migration. The engineering investments in IAKerb, Local KDC, richer NTLM auditing, and SMB hardening are coherent: they tackle the real technical reasons Kerberos was bypassed and give administrators the visibility and controls they need to migrate safely.
That said, the change is not a silver bullet. Organizations must avoid complacency: disabling NTLM reduces a class of attacks but also highlights other gaps in identity and infrastructure security that attackers will pursue. The successful outcomes will come from measured programs — inventory, remediation, testing, and monitoring — plus executive sponsorship and engineering resources to fix applications and vendor integrations.

Action checklist (next 90 days)​

  • Enable enhanced NTLM auditing across a representative set of clients and DCs; export logs to your SIEM.
  • Build a prioritized inventory of NTLM-using applications (identify owners and SLAs).
  • Pilot NTLM-blocking policies in a staging ring and validate IAKerb/Local KDC behavior where available.
  • Engage major vendors and internal dev teams to schedule Kerberos compatibility updates.
  • Harden SMB (enable signing and test NTLM-block exception lists) and enforce LDAP/LDAPs channel binding best practices.
These steps will both reduce immediate exposure and position your environment to tolerate Microsoft’s eventual default-change with minimal operational disruption.
Disabling NTLM by default is one of those rare platform-level moves that forces a long-overdue conversation about identity hygiene across the enterprise. For organizations willing to invest the engineering effort today, the reward is a significantly harder-to-exploit authentication surface and a stronger foundation for modern, passwordless, phishing-resistant identity strategies.
Conclusion: treat the Microsoft roadmap as an actionable deadline, not a distant promise. Begin inventory and remediation now, test Kerberos-first configurations rigorously, and build monitoring that proves NTLM usage is declining. Those who do will both avoid disruption and materially reduce one of the most-exploited attack vectors in modern Windows networks.
Source: Cyber Press https://cyberpress.org/microsoft-to-disable-ntlm-by-default-in-major-push/
 
Microsoft’s decision to ship future Windows releases in a “Kerberos‑first” posture — effectively disabling network NTLM authentication by default — is one of the most consequential platform security changes in years, and it arrives with a deliberate, multi‑phase runway designed to give enterprises time to discover dependencies, pilot replacements, and avoid disruptive outages.

Background / Overview​

NTLM (New Technology LAN Manager) debuted in the early 1990s and for decades served as a pragmatic, widely supported challenge/response authentication fallback across Windows workgroups and early domains. Over time Kerberos became the domain default, but NTLM persisted as a compatibility safety valve — and with it a repeatable set of attack vectors that adversaries still use in enterprise compromises. Microsoft now classifies NTLM as deprecated and is moving systems to a secure‑by‑default state that prefers Kerberos and rejects network NTLM unless an administrator explicitly re‑enables it.
This change is not a sudden removal of code. Microsoft will keep NTLM binaries in the operating system for compatibility and emergency re‑enablement, but the operating system will no longer elect NTLM automatically in most network authentication flows. That behavioral flip — from pelocked‑by‑default — is the defining technical and operational shift here.

What Microsoft announced: the three phases​

Microsoft’s public plan is structured as a three‑phase program that balances telemetry, platform mitigations, and an eventual default change. The phases and their practical milestones are:
  • Phase 1 — Visibility and auditing (already rolling): Enhanced NTLM logging shipped with Windows 11 version 24H2 and Windows Server 2025 so administrators can find who and what still uses NTLM and why. These logs include fields such as process name, PID, source IP, target SPN, NTLM version, and a reason id that explains why Kerberos failed and NTLM was used. Use this phase to build a prioritized inventory.
  • Phase 2 — Kerberos coverage for legacy scenarios (target: second half of 2026): Microsoft will introduce new Kerberos capabilities, most notably IAKerb (a mechanism to carry Kerberos messages or pass them through constrained topologies) and a Local Key Distribution Center (Local KDC) (a machine‑local KDC backed by the local Securithese features are explicitly intended to eliminate common root causes that force Kerberos to fail and NTLM to be used instead.
  • Phase 3 — Network NTLM disabled by default (future major Windows release): After telemetry and compatibility tooling indicate readiness, Microsoft will ship a next major Windows Server and corresponding client release that blocks network NTLM by default. Administrators will still be able to explicitly cific targets or scenarios via policy, but the out‑of‑the‑box behavior will be Kerberos‑first. Microsoft has not published a single global date for the final flip; the company will use the telemetry and phased previews to judge readiness.
These phases provide a runway — but they are also firm enough that organizations should not treat them as purely optional guidance. The dates Microsoft has published for NTLMv1 hardening and auditing (audit rollout in late‑2025; enforcement default for certain keys planned for October 2026) are operational signals you should plan around today. (support.microsoft.com)

Why this matters: the security case against NTLM​

NTLM’s structural and cryptographic characteristics make it a persistent, high‑value attack surface:
  • NTLM relay and coercion: Attackers can coerce a client to authenticate to a malicious endpoint and then relay that authentication to a target service, effectively impersonating the user for lateral movement or privilege escalation. Variants of these attacks (PetitPotam, ShadowCoerce, DFSCoerce, RemotePotato0) have repeatedly been used in real intrusions.
  • Pass‑the‑hash and credential extraction: NTLM‑derived hashes and credentials can be harvested and re‑used without knowing a plaintext password, allowing attackers to move laterally in poorly protected estates.
  • Weak historical defaults and fallback logic: NTLM persisted because many devices, appliances, and legacy applications fall back to it when Kerberos fails (name resolution issues, SPN mismatches, unreachable domain controllers). That fallback pattern makes it easy for an attacker to weaponize a compatibility feature.
By favoring Kerberos — which provides ticketed, time‑limited authentication and better mutual authentication semantics — Microsoft expects to materially reduce the population‑level attack surface for relay and pass‑the‑hash families of attacks. But the gains are only real if organizations use the current runway wisely to find and fix NTLM consumers. (microsoft.com)

Technical deep dive: what IAKerb and Local KDC change​

IAKerb: making Kerberos work where Kerberos used to fail​

Kerberos historically relies on domain-aware infrastructure — reachable Key Distribution Centers (domain controllers), DNS, and correctly registered Service Principal Names (SPNs). Many legacy topologies lack those assumptions, so NTLM survived as the working fallback.
IAKerb is designed to carry Kerberos messages through constrained or non‑standard topologies, enablete in scenarios where previously only NTLM could function. That reduces the number of triggers that cause a client to downgrade to NTLM, without requiring application rewrites in many cases. IAKerb is explicitly described as a pass‑through/bridging mechanism that avoids requiring new open ports or extra infrastructure.

Local KDC: Kerberos semantics for local accounts​

Local KDC gives a Windows machine a local ticket‑granting capability backed by the local Security Account Manager (SAM). This is important for scenarios where local accounts or workgroup machines cannot reach a domain controller: instead of using NTLM for local authentication, the OS can issue Kerberos‑style tickets locally. That addresses classic NTLM use cases — like local account remote authentication — without moving to less secure mechanisms. atform extensions: they introduce operational variables and must be tested in lab rings. Microsoft intends to ship these capability improvements in preview and servicing channels prior to any final default change, giving administrators time to validate behavior.

What administrators must do now — an actionable checklist​

Microsoft is giving enterprises time, but the practical work required is non‑trivial. Below is a prioritized, operationt runway into readiness.
  • Enable and centralize the enhanced NTLM audit logs
  • Turn on Microsoft‑Windows‑NTLM/Operational auditing (Event Viewer → Applications and Services Logs → Microsoft → Windows → NTLM → Operational).
  • Export logs to your SIEM and build dashboards for event IDs and reason codes.
  • Key events to watch: NTLM client events that include process name/PID, target SPN, NTLM version, and the reason ID that explains why Kerberos was not used.
  • Build a prioritized inventory of NTLM producers and consumers
  • Classify endpoints by business criticality: printers, NAS, backup serveonitoring agents, and older third‑party appliances are common NTLM consumers.
  • For each item, document the authentication flow: which account, which protocol, target SPN or IP, and why Kerberos would fail today. Use the enhanced audit fields to reduce guesswork.
  • Harden services that historically enrce SMB signing where supported and evaluate SMB NTLM blocking in controlled groups (Windows Server 2025 / Windows 11 24H2 supports blocking NTLM for remote outbound SMB).
  • Enable LDAP channel binding and Extended Protection A) on services like AD CS and Exchange where platform support exists. These hardenings reduce relay feasibility even before NTLM is disabled by default.
  • Pilot IAKerb and Local KDC in non‑production
  • Use Windows Insider and servicing preview builds to test Local KDC and IAKerb behavior with representative topologies.
  • Validate authentication flows end‑to‑end, including constrained delegation and SPN resolution, and observe the operational telemetry.
  • Negotiate vendor remediation timelines
  • Contact appliance, backup, printer, and NAS vendors to request Kerberos support or validated gndors cannot deliver, plan for exception windows with tight monitoring and documented expiration. Treat exceptions as temporary and monitored.
  • Build a governance model for exceptions
  • Every explicit NTLM re‑enablement should require a documented business justification, owner, timebox, and compensating controls such as network segmentation and attack detemmunication and testing windows
  • Coordinate with application owners, procurement, and change management to ensure planned migration windows and fallbacks are agreed in advance.
Following this playbook will materially reduce the chance of surprise outages when the default flips.

Technical specifics you should record in your playbook​

  • Registry key and audit timeline: Microsoft introduced a registry key to gate NTLMv1 SSO behavior: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BlockNtlmv1SSO. Devices started in Audit mode, but Microsoft plans to change the default to Enforce (1) via Windows updates in October 2026 on devices that have not configured the key. Administrators should treat that date as a firm planning signal. Event IDs such as 4024 (NTLMv1‑derived SSO auditing) will appear in enhanced logs.
  • Where to find actionable logs: Microsoft‑Windows‑NTLM/Operational contains fields for client process, PID, domain, target SPN/IP, the NTLM version used, and a reason id. These fields let you map fallback causes: hardcoded NTLM in an application; SPN mismatch causinr offline/local account flows. Use these fields to prioritize remediation.
  • SMB NTLM blocking: SMB clients now support blocking NTLM authentication for outbound remote connections — a tool you can use to force Kerberos for SMB in controlled groups while maintaining per‑host exceptions. SMB signing defaults were also tightened in Server 2025 / Windows 11 24H2.

Compatibility risks and real‑world failure modes​

The move away from NTLM will expose long‑buried compatibility gaps in many organizations. The most re:
  • Legacy appliances (networked storage, backup appliances, monitoring probes) that only support NTLM.
  • Hardcoded service access where software authenticates by IP address instead of SPN or uses local accounts across hosts.
  • Third‑party integrations in which vendor tooling executes on endpoints with minimal Kerberos support.
  • Remote or edge devices that cannot reliably reach domain controllers for Kerberos ticketing.
These item Microsoft and independent reporting repeatedly point to appliances and legacy app behavior as principal reasons NTLM persisted. Where replacements are impossible, organizations will need to govern exceptions tightly and apply compensating controls such as network segmentation, conditional access, or jump hosts that broker Kerberos-secured access.

Benefits — what you stand to gain​

Shifting the default away from NTLM produces measurable security improvements:
  • Fewer relay vectors: Kerberos ticketing and enforced SMB signing reduce the viability of relay attuced credential re‑use**: Ticket‑based authentication avoids many forms of pass‑the‑hash abuse.
  • Better auditability: Kerberos flows and the new telemetry expose authentication behaviors in richer, more actionable ways.
  • Stronger default poents: Defaults are powerful; changing them at the OS level means fewer misconfigurations and safer estate baselines over time. ever, are realized only if the migration is executed deliberately; defaults alone do not fix legacy architectures.

Where Microsoft’s plan is strong — and where it still risks friction​

Strengths​

  • Phased, telemetry‑driven approach: Microsoft is not flipping a switch without data. The emphasis on rich auditing, preview capabilities (IAKerb, Local KDC), and a staged rollout shows awareness of the operational risks.
  • Platform mitigations beyond NTLM: Parallel hardening of SMB signing, LDAP channel binding, and EPA reduces exploitable combinations and makes a final disablement less brittle.
  • Escape hatches remain: NTLM binaries will remain in the OS and administrators can re‑enable NTLM selectively for documented exceptions. That reduces the risk of catastrophic breakage.

Risks and open questions​

  • Timeline slippage: The public target for Phase 2 (H2 2026 default change for NTLMv1 controls are planning signals that could shift; organizations should not assume an indefinite runway. Treat published dates as actionable planning points.
  • Vendor readiness: Many third‑party vendors (appliance makers, embedded device vendors) have slow product cycles. Expect mixed readiness across the ecosystem and plan for replacement or compensating controls where remediation is impractical.
  • Operational complexity: Accurate inventorying, targeted testing, exception policy governance, and end‑to‑end validation are time and resource intensi treat this as a project and begin now will minimize last‑minute firefighting.
Where Microsoft’s approach matters most is in converting a long‑standing se into an enforceable default — but that conversion shifts the operational burden squarely to IT and procurement teams to ensure compatibility.

Practical example: how a test migration looks​

  • Select a representative business unit with a mixture of servers, appliances, and user devices.
  • Enable enhanced NTLM auditing and baseline weekly NTLM traffic for 90 days.
  • Identify top NTLM endpoints (by volume and business criticality).
  • For each endpoint, attempt to enable Kerberos authentication (correct SPN, DNS entry, and time sync). If Kerberos fails, capture the reason id from the NTLM event and debug the precise failure mode.
  • If a device cannot be Kerberized, assess vendor support and either schedule replacement or configure a logged exception with compensating network controls.
  • Pilot SMB NTLM blocking on a sma exception lists for identified legacy hosts. Observe for any authentication regressions and timeouts.
Pilots should emphasize recovery paths and clear rollback plans; a successful pilot gives confidence for broader rollouts.

Final analysis and recommended priorities​

Microsoft’s move to disable network NTLM by default is overdue from a security perspective and technically achievable given today’s Kerberos feature set and the platform mitigations Microsoft is shipping. The company’s three‑phase plan — auditing, compatibility coverage, and default change — is pragmatic and reflects an operationally realistic way to modernize authentication without causing chaos.
That said, the program’s success depends on three organizational behaviors:
  • Start measuring today. You cannot fix what you cannot see — enable the NTLM operational logs and ingest them into your SOC/SIEM now.
  • Treat this as an IT modernization project. Inventory, vendor engagement, test labs, and clear exception governance are required to avoid late breakages.
  • Pilot the new Kerberos primitives (IAKerb, Local KDC) as they arrive and validate that they actually eliminate the real‑world fallback scenarios in your estate. Microsoft intends to ship them in preview channels before enforcement, and those previews are the chance to discover corner cases.
If you begin now — audit, harden, pilot, and govern — you will transform Microsoft’s platform change from an operational headache into a predictable security win. If you wait, the default change will force reactive choices under pressure and create needless service outages or temporary, potentially risky, re‑enablement policies. Microsoft’s policy shift raises the baseline security of new Windows deployments; how smoothly your organization benefits from that baseline depends on the work you do in the next 12–18 months.
In short: the era when NTLM was an implicit, invisible safety net is ending. Microsoft has given time and tools — the rest is up to security teams and procurement to act before defaults change.
Source: SC Media Microsoft to disable NTLM authentication by default
 
You must log in or register to reply here.

Similar threads

  • Article Article
Microsoft's NTLM Phase-Out Roadmap: Kerberos First, Network NTLM Off by Default
Replies
0
Views
23
ChatGPT
  • Article Article
NTLM Deprecated: Move to Kerberos with Negotiate in Windows Authentication
Replies
0
Views
36
ChatGPT
  • Article Article
NTLM Deprecation: Windows Preview Moves to Block NTLM by Default
Replies
0
Views
33
ChatGPT
  • Article Article
Preventing Duplicate SID Kerberos NTLM Failures After Windows Updates
Replies
2
Views
78
ChatGPT
  • Article Article
Remove RC4 in Windows Kerberos with New Audit Fields and Remediation Tools
Replies
0
Views
54
ChatGPT