Microsoft shipped a Windows Canary preview with two new authentication components—IAKerb and LocalKDC—on June 2, 2026, giving IT teams the first tangible pieces of a puzzle the company has been assembling for years: how to retire NTLM without breaking the network. The preview flips the switch on IAKerb by default while keeping LocalKDC off, and both features are initially controlled through registry keys, not Group Policy or MDM. That makes them important for lab validation now, but not yet for large-scale deployment. This is the moment for administrators to start mapping every remaining NTLM dependency to one of four paths—standard Kerberos, IAKerb, LocalKDC, or a tightly governed exception—before Microsoft’s default-disablement of NTLM arrives with the next major Windows Server release.

What Just Landed in Canary

The June 2 Insider Preview introduces two long-awaited capabilities: IAKerb (Initial and Pass Through Authentication Using Kerberos) and LocalKDC, both aimed at closing the loop on NTLM fallback scenarios that have stubbornly resisted Kerberos-only mandates. According to Microsoft’s tech community blog, IAKerb is enabled by default in this build, while LocalKDC remains disabled and must be manually turned on through the registry. Neither feature is yet exposed via Group Policy or mobile device management controls, which means IT shops can experiment but cannot push these settings broadly through existing enterprise configuration tools.

The company’s published roadmap places these features—along with an upgrade to hard-coded Negotiate behavior that favors Kerberos—in the second half of 2026. However, the bigger milestone is Microsoft’s stated plan to disable NTLM by default in most scenarios with the next Windows Server release. That schedule, while still subject to change, puts a premium on early testing. Organizations that wait for the final cutover risk discovering critical authentication dependencies only after a policy change breaks production workloads.

What Do IAKerb and LocalKDC Actually Do?

Think of IAKerb and LocalKDC as two specialized escape routes from NTLM, not one-size-fits-all replacements. IAKerb tackles a specific headache: a domain-joined device that needs to authenticate to a domain resource but cannot reach a domain controller directly. In that situation, Windows historically fell back to NTLM. IAKerb instead allows the authentication process to continue through an intermediary path, preserving the security properties of Kerberos tickets.

LocalKDC addresses a different historical compromise. It targets authentication involving local accounts, workgroup setups, and standalone systems—scenarios where Active Directory Kerberos was never part of the picture. By providing a local Kerberos key distribution center, it aims to bring Kerberos-based behavior to connections that have long relied on NTLM.

Crucially, Microsoft is clear that these cover only a subset of NTLM fallback situations. Neither feature repairs broken service principal names, misconfigured DNS, applications that explicitly demand NTLM, or legacy infrastructure that assumes the old protocol. If a line-of-business app connects to a server by IP address and has no SPN configured, IAKerb won’t fix it. LocalKDC won’t help a domain-joined workload that accidentally falls back to NTLM because of a name-resolution error. The distinction matters because early adopters risk declaring victory after a single successful test while NTLM usage continues elsewhere in the environment.

These new capabilities also sit alongside related but separate efforts. The SMB client’s ability to block outbound NTLM, introduced in Windows Server 2025 and Windows 11 version 24H2, is a blunt instrument that stops NTLM at the protocol level but needs an exception list for servers that cannot yet go Kerberos-only. The removal of NTLMv1 is an even earlier, narrower milestone. IAKerb and LocalKDC fill the harder gaps: authentication paths that have no easy Kerberos alternative today.

Who Needs to Pay Attention Right Now

Enterprise administrators and IT architects should treat this preview as a directive to start auditing. Home users and small offices without domain controllers will find little immediate relevance—LocalKDC isn’t ready for broad use, and IAKerb requires a domain identity. For organizations managing Windows Server and domain-joined clients, however, the clock is ticking. The eventual default-disablement of NTLM means every remaining dependency must be identified, categorized, and given a migration route—or a documented, time-bound exception.

In practice, that work falls into two bins: finding why NTLM is still used, and then matching each case to the right fix. A domain service that should support Kerberos but doesn’t usually points to misconfigured SPNs, DNS aliases, stale computer accounts, or applications that hard-code NTLM. Those are standard Kerberos hygiene tasks. Real IAKerb candidates are situations where the client is domain-authenticated but consistently lacks a direct line of sight to a domain controller—remote users connecting through unusual VPN tunnels, branch offices with unreliable DC connectivity, or subnet isolation that was never designed for Kerberos. LocalKDC candidates are local-account or workgroup authentication patterns that simply never had an Active Directory context.

How We Got Here: The Long Road to NTLM Retirement

The NTLM protocol has been on borrowed time for over a decade. Its weaknesses—pass-the-hash, brute force, lack of server identity validation—are well documented, and Microsoft has been chipping away at its surface area. The SMB client NTLM-blocking feature in Windows Server 2025 and Windows 11 24H2 was a major step, letting administrators prevent outbound NTLM on file shares while maintaining exceptions for servers that still need it. But blocking NTLM on one protocol is not the same as eliminating it system-wide. Applications, remote management tools, web services, and custom integrations often rely on NTLMv2, and many environments have deeply embedded dependencies.

The introduction of IAKerb and LocalKDC in the June 2026 Canary preview signals that Microsoft is now attacking the root cause: the lack of a viable Kerberos path in certain network topologies and local-account scenarios. The company’s own communications describe these as filling gaps that previously forced a fallback to NTLM, and the roadmap ties them to a broader “has-NTLM” removal in the next Server release. That means organizations cannot treat this as an academic feature—it’s a necessary component of the Kerberos-first future Microsoft has been promising.

What to Do Now: A Pilot Game Plan

Since both features are currently controlled via registry settings and exist only in the Canary channel, the immediate goal is validation, not deployment. A structured pilot should follow a methodical sequence:

Step 1: Inventory every NTLM dependency. Use event logs, network monitoring, and application audits to record the client, target server or service, account type (domain, local, workgroup), network location, protocol, and business criticality. Separate domain identities from local ones early—that will point each case toward standard Kerberos, IAKerb, or LocalKDC.

Step 2: Classify before changing anything. For each dependency, ask four questions:
- Can standard Kerberos fix it? (Fix SPNs, DNS, app config)
- Is it a domain identity without a reachable domain controller? (IAKerb candidate)
- Is it a local-account or workgroup scenario? (LocalKDC candidate)
- Is it outside the scope of these features? (Requires temporary exception)

Step 3: Build a minimal test ring. Choose two representative workflows: one domain scenario with intermittent or absent DC connectivity (for IAKerb), and one standalone or local-account setup (for LocalKDC). Do not begin with the most business-critical application. Use dedicated test devices running the Canary build.

Step 4: Baseline and test independently. Before enabling anything, capture the current authentication flow—is NTLM observed? What does the user experience? Then enable IAKerb (default) or LocalKDC (manual registry change) and repeat the test. Microsoft’s blog notes that IAKerb is on by default in this build, but that doesn’t guarantee it will handle every edge case. Test with real aliases, DNS names, credential renewal scenarios, and network interruptions. Also test rollback: disable the feature and confirm the old NTLM behavior returns.

Step 5: Handle exceptions like a retirement program. Every allowed NTLM path should have an owner, a technical reason, compensating controls, test evidence, and a sunset date. “Legacy compatibility” is not sufficient. Assign each exception a target remediation path—standard Kerberos, IAKerb, LocalKDC, redesign, or replacement—and review it on a regular cadence.

Avoid common traps: Canary builds are not production-ready, registry controls do not guarantee future manageability, and SMB blocking alone is insufficient. A successful SMB NTLM block does not prove that application stacks are clean. NTLMv1 removal is a separate, earlier milestone that tidies up the oldest protocol version but does not address NTLMv2 dependencies. The real test is whether every NTLM event in your environment can be tied to a tested Kerberos path or a finite, accountable exception list.

What Comes Next

The most important date on the calendar is not a specific build release, but the moment Microsoft flips NTLM to disabled by default in Windows Server. Between now and then, IT teams should watch for Insider builds that add Group Policy or MDM support for IAKerb and LocalKDC, making them feasible for production deployment. The registry-only controls in the June 2026 Canary preview are a starting gun, not a finish line. Organizations that use this window to inventory, classify, and pilot-test their NTLM dependencies will turn a potentially disruptive default cutover into a routine configuration change. Those that don’t will face the same scramble that accompanied past protocol retirements—only this time, the protocol underpins a vast range of authentication paths that have gone unexamined for years.