Microsoft is arming upcoming Windows 11 and Windows Server Insider builds with two new Kerberos authentication extensions—IAKerb and LocalKDC—designed to finally sever the long-standing dependence on NTLM. The additions allow Kerberos to operate in network scenarios where it traditionally fell back to NTLM, moving the industry a decisive step closer to a truly passwordless, secure-by-default Windows ecosystem.

Insider previews are already shipping the groundwork, and administrators can expect these capabilities to land in mainstream releases later this year. For anyone managing Windows domains, the message is clear: the NTLM retirement clock is ticking.

Why NTLM Refuses to Die

Kerberos has been the default authentication protocol in Active Directory since Windows 2000, but two stubborn gaps forced Windows to keep NTLM alive. First, when a client cannot reach a domain controller—perhaps because of network segmentation, VPN splits, or pure air-gap environments—Kerberos bails out and NTLM steps in. Second, connections by IP address or server name (when the server’s hostname is not a valid service principal name) break Kerberos’s strict SPN-verification model, triggering another NTLM fallback.

NTLM’s cryptographic weaknesses, susceptibility to pass-the-hash, and inability to support modern claims-based authentication have been well documented. Yet millions of organizations still rely on it daily because the protocol simply works in places Kerberos does not.

IAKerb: Untethering Kerberos from Domain Controllers

IAKerb—Initial and Pass-Through Authentication Using Kerberos—is the most transformative piece of this puzzle. Defined in the Internet-Draft draft-ietf-kitten-iakerb-00 and honed by Microsoft’s Kerberos team, IAKerb lets a Windows client obtain a Kerberos service ticket without communicating directly with a KDC (Key Distribution Center). Instead, the client sends its pre-authentication data inside the Kerberos AP request itself, and the target server proxies that authentication to a reachable domain controller.

Under the hood, IAKerb uses asymmetric cryptography. The client encrypts a timestamp with the public key of the domain controller, proving knowledge of the user’s long-term key without ever sending it over the wire. The server, acting as a pass-through, wraps the client’s authentication payload in an IAKerb message and forwards it to a KDC. If verification succeeds, the KDC returns a service ticket that the server can use to complete the mutual authentication.

This proxy-based model eliminates the client’s need to find and contact a DC. For field laptops, cloud VMs, or stretch clusters where domain controllers are many hops away—or completely unreachable—IAKerb allows Kerberos to work natively. No more NTLM fallback simply because DC locator returned an empty list.

Administrators who have fought against NTLM over VPN tunnels will immediately see the benefit. A remote worker’s Windows 11 device can now authenticate to internal file servers using pure Kerberos, even when split-tunnel DNS hides the domain controllers. The server-side Windows Server Insider build handles the proxy authentication, keeping all of the security benefits of Kerberos—mutual authentication, delegation control, and AES encryption—without requiring any client-side VPN back-connection to a DC.

LocalKDC: Kerberos on an Island

LocalKDC tackles the other stubborn NTLM bastion: authentication that involves only local machine accounts. When a Windows service runs as NT AUTHORITY\\LocalSystem and connects to a resource on the same machine, or when a Hyper-V host needs to authenticate against the management OS running in the root partition, the Kerberos protocol was never available. These local-only scenarios defaulted to NTLM or simple challenge-response exchanges because a domain controller simply wasn’t necessary—and, in some cases, not even configured.

LocalKDC embeds a lightweight, on-machine Key Distribution Center that implements the core Kerberos KDC functions. It operates exclusively for local machine accounts and services that use the host/ service principal name bound to the machine’s identity. When a local component performs a GetTicket call, LocalKDC issues a Kerberos ticket that the receiving service can validate locally—no domain controller in sight.

The implementation relies on the machine’s certificate store. LocalKDC uses the machine’s private key to sign tickets and encrypt session keys, establishing a zero-trust chain of trust that stays entirely within the box. This means Windows Defender, Update Orchestrator, and countless other background services that today resort to NTLM or token duplication can now reap the full advantage of Kerberos’s secure, auditable ticketing system.

For developers, the shift is transparent. Calls to AcquireCredentialsHandle and InitializeSecurityContext with the Kerberos package will succeed locally when LocalKDC is active, just as they do in domain-joined scenarios. The authentication layer hides the complexity, so applications that have long requested Kerberos get it automatically.

How These Pieces Fit Together

IAKerb and LocalKDC are not siloed features; they are complementary. IAKerb solves the “no DC reachable” problem for domain-joined machines, while LocalKDC handles the “local-only” use case that has nothing to do with the domain. Together, they close the two primary gaps that made NTLM a mandatory fallback.

Consider a common enterprise scenario: a branch office with a read-only domain controller in the site, but that RODC fails. Without IAKerb, client machines would drop to NTLM the moment the RODC becomes unresponsive. With IAKerb enabled, the Windows 11 client can still acquire Kerberos tickets by proxying through any server that still has network line-of-sight to a writable DC in the hub. The same logic applies to satellite links and Azure IaaS workloads where domain controllers are deliberately isolated.

Microsoft’s endgame is to make NTLM an opt-in protocol that must be explicitly enabled via Group Policy, and then eventually remove it entirely. IAKerb and LocalKDC are essential stepping stones because they eliminate the normal operational reasons for NTLM’s existence. Once these features are widely deployed, NTLM can be disabled by default in new Windows editions.

Insider Builds and Early Observations

Windows 11 Insider Preview builds from the Dev and Canary channels, along with Windows Server vNext Insider, have been shipping IAKerb and LocalKDC components since early 2025. The features are not on by default yet, but administrators can toggle them with registry keys or Group Policy objects under Computer Configuration\\Administrative Templates\\System\\Kerberos:

  • Enable IAKerb (Initial and Pass-Through Authentication Using Kerberos)
  • Enable Local KDC for local machine authentication

When enabled, network traces show a marked decline in NTLM negotiation packets. In Microsoft’s own test environments, NTLM authentication traffic dropped by over 70% on client machines that activated both features, leaving only legacy applications that hard-code NTLM as the security package.

Community feedback from forums and the Windows Insider Program has been largely positive but not without edge cases. Some testers report that third-party VPN clients intercept and modify Kerberos traffic, breaking the IAKerb proxy flow. Others note that LocalKDC initially failed when a machine had no installed certificates from a trusted root—a scenario common in disconnected manufacturing environments. Microsoft has addressed several of these bugs in cumulative updates to the Insider builds, and drivers for the most popular VPN vendors are being updated to preserve the integrity of IAKerb messages.

Implications for Administrators and Architects

The arrival of IAKerb and LocalKDC is more than a protocol change; it’s an architectural shift that touches network design, firewall rules, and server hardening. Organisations should begin planning now.

Firewall configurations: Because IAKerb tunnels authentication inside the application protocol (SMB, HTTP, etc.), no new ports need to be opened between clients and domain controllers. However, servers that act as IAKerb proxies must be allowed to communicate with domain controllers on TCP/UDP 88 (Kerberos). Some DMZ designs that currently block all DC traffic from application servers will need to be revisited.

Certificate health: LocalKDC depends on a valid machine certificate with client and server authentication EKUs. Enterprises that use Microsoft’s own Active Directory Certificate Services typically have these in place, but organisations using third-party PKI or no PKI at all may need to deploy certificates to all Windows endpoints. Microsoft is testing automatic enrollment via the MS-Organization-P2P-Access certificate template to simplify this.

Application compatibility: Most applications that use Windows SSPI (Security Support Provider Interface) will benefit automatically. Exceptions include software that parses NTLM tokens directly or relies on NTLM’s single-round-trip challenge for low-latency operations. Microsoft’s App Assure team is working with major ISVs to identify and remediate such cases, but homegrown line-of-business applications will need testing.

Group Policy readiness: Both features are controlled via Group Policy templates that will ship with Windows 11 24H2 and Windows Server 2025. Early adopters can import the ADMX files from Insider preview builds into their central store now and start piloting in ring deployments.

What’s Next for NTLM Decommissioning

Microsoft’s NTLM deprecation roadmap, outlined at recent Ignite sessions, has three phases:

  1. Instrumentation (current): Telemetry and audit logging to help organizations identify where NTLM is still used.
  2. Default off (next major Windows release after Insider testing): NTLM becomes an opt-in feature; Kerberos with IAKerb/LocalKDC fills the gaps.
  3. Removal (future version): NTLM is stripped from the Windows security subsystem entirely, potentially remaining only as an optional Feature on Demand.

IAKerb and LocalKDC are prerequisites for phase 2. Without them, turning NTLM off by default would break a large fraction of real-world deployments. With them, Windows can finally deliver on the promise it made in Windows 2000: a domain environment that never needs to fall back to legacy protocols.

The technical preview shows that Microsoft is close to finalizing these components. Expect hardened, generally available versions in the second half of this year, along with updated documentation and migration tools. The road to a post-NTLM world is shorter than it has ever been.