That distinction should shape how Windows administrators respond. The coming change is a security opportunity, but it is also a dependency-discovery project. Organizations that treat it as an all-at-once block risk interrupting access to SMB shares, legacy applications, workgroup resources, and services reached by IP address. Those that audit first can use the transition to eliminate avoidable NTLM traffic before Microsoft’s defaults become more restrictive.
Why Windows is moving away from NTLM
Microsoft’s reasoning is straightforward: NTLM lacks server authentication, uses weaker cryptographic foundations than modern Kerberos deployments, and has known exposure to replay, relay, and pass-the-hash attacks. Those properties matter in a Windows environment because authentication is frequently negotiated behind the scenes. A user opening a file share, connecting to an internal web service, or starting an application may not know which protocol ultimately authenticated the session.
Kerberos is Microsoft’s preferred replacement because it is designed around ticket-based authentication and mutual authentication in domain scenarios. In broad terms, it gives a client a way to verify the service it is reaching, rather than merely responding to a challenge from a server. That makes it a better fit for reducing the opportunity for credential relaying and impersonation attacks.
It would be an overstatement, however, to frame this as a claim that every NTLM use is an active compromise or that switching it off automatically secures an enterprise. A correctly managed environment still needs sound identity administration, secure domain-controller infrastructure, service principal name management, network segmentation, patching, and monitoring. Retiring NTLM removes a longstanding class of exposure; it does not replace those controls.
The roadmap: default-off is not deletion
Microsoft’s published direction is to phase out NTLM in favor of Kerberos-based alternatives. In phase 3 of that roadmap, the next major Windows Server release and its associated client releases are planned to have network NTLM disabled by default in most cases. Microsoft explicitly cautions that timing and feature availability can change.
Two qualifiers deserve attention:
- “Most cases” is not universal enforcement. The wording recognizes that Windows estates contain configurations for which a Kerberos transition is not yet practical.
- NTLM remains present initially. Microsoft says it can be re-enabled through policy when necessary. That is an escape hatch for compatibility, not a reason to postpone assessment indefinitely.
For IT leaders, the likely effect is a reversal of the traditional troubleshooting posture. Today, a failed Kerberos path can quietly end in NTLM fallback in many situations. In a future default-disabled environment, an unprepared dependency may instead fail visibly until administrators fix Kerberos configuration or introduce a narrowly scoped exception.
That is healthier from a security perspective, but it means help desks, application owners, network teams, and identity teams need a shared plan. The question is no longer simply whether an application “supports Windows authentication.” The useful question is whether it can complete the required Kerberos path under real production conditions.
Audit before you block
The strongest immediate action is to inventory NTLM use before applying denial policies. Microsoft’s newer NTLM auditing capabilities in Windows 11 version 24H2 and Windows Server 2025 are especially useful because they go beyond a basic record that NTLM occurred.
The audit data is intended to identify:
- who used NTLM;
- why NTLM was selected rather than Kerberos;
- where the event occurred, including machine name and IP address; and
- the initiating process.
That last item is operationally significant. A security event tied to a user account alone can leave an administrator guessing whether the source was Explorer, a line-of-business application, a service, a script, a device-management agent, or a browser-integrated workflow. Process-level context makes it easier to assign remediation to the right owner.
A sensible investigation sequence is:
- Enable and collect NTLM auditing on supported systems.
- Group events by initiating process, destination, account, and business service.
- Identify whether the destination is domain-joined and whether it has a valid DNS name and service principal names.
- Separate active, justified dependencies from stale software, scripts, mappings, and infrastructure that can be retired.
- Fix Kerberos prerequisites where possible.
- Test restrictive policies first against a controlled population, with documented exceptions and rollback procedures.
This is not merely cautious change management. Microsoft’s existing NTLM restriction guidance warns that blocking before review can produce numerous authentication failures. An audit period also gives organizations a factual baseline: the goal is not to make a dashboard show zero events at any cost, but to understand which remaining events require engineering work, a limited exception, or a replacement product.
The IP-address problem is a common source of fallback
One particularly concrete NTLM trigger is connecting to a service by IP address rather than by DNS name. By default, Windows does not attempt Kerberos authentication when the target is specified as an IP-address hostname, and NTLM can become the fallback.
This catches many environments because IP-address access can seem harmless or even pragmatic: a script maps a share by address, an administrator enters an address while troubleshooting DNS, a device is configured with a fixed target, or an old application stores an IP address in its configuration. Each can undermine a broader Kerberos-first strategy.
Microsoft documents a mitigation called TryIPSPN. It is a per-client setting that permits Kerberos attempts for IP-address targets when the required IP-based service principal names have been registered manually. This is not a universal switch to apply blindly. Microsoft recommends DNS names where possible and positions IP-based SPNs for situations where moving to a DNS hostname is impossible.
The limitation is structural. IP-based SPNs must correspond to stable addresses. If addresses change or are reused, registrations can conflict and authentication can fail. For most organizations, the durable remediation is therefore to correct naming: use stable DNS records, have clients and scripts reference those names, and validate the service’s Kerberos registration. Treat TryIPSPN as a constrained compatibility tool, not as a substitute for DNS hygiene.
New Kerberos paths may reduce real-world exceptions
Microsoft has announced two technologies meant to close scenarios that have historically led to NTLM use: IAKerb and LocalKDC.
IAKerb is intended for cases where a client cannot directly reach a domain controller. Rather than abandoning Kerberos, the target service can proxy the Kerberos exchange so authentication remains on a Kerberos-based path. This could be relevant in segmented networks or service topologies where domain-controller reachability has been an obstacle.
LocalKDC is intended to enable Kerberos-based authentication for local-account scenarios. That addresses another historic gap, because traditional Kerberos is commonly associated with Active Directory domain identities.
Both capabilities were announced for Windows Insider public preview. Their general-availability status, precise supported editions, updates, and deployment requirements should not be assumed from that preview announcement. Administrators should therefore wait for finalized release documentation before building a production design around either feature. The direction is promising, but preview availability is not the same as a supported enterprise dependency.
Blocking options that exist today
Windows already provides controls that can support a staged retirement program. The established Restrict NTLM policy can audit or deny outgoing NTLM traffic to remote servers and can allow specified remote-server exceptions. That model supports gradual enforcement: observe first, correct what can be corrected, then deny traffic while preserving tightly justified exceptions.
For SMB specifically, Windows Server 2025 and Windows 11 24H2 include an SMB-client NTLM blocking control with an exception list. This can be valuable because SMB is a common place for legacy authentication patterns to persist unnoticed. But Microsoft’s documentation makes clear that exceptions may be needed, including when a target SMB server is not joined to Active Directory.
An SMB exception should be treated as a risk record, not a permanent convenience setting. For each entry, administrators should document the target, business owner, reason Kerberos cannot be used, compensating controls, review date, and migration path. A generic exception list can quickly become a hidden inventory of unmanaged or obsolete infrastructure.
It is also important not to assume that all future NTLM governance capabilities are already available. Publicly documented controls are scoped to particular policies and scenarios. Claims of a fully centralized policy engine that evaluates every combination of account type, device state, target characteristic, and sign-in method should be regarded as unconfirmed unless and until Microsoft publishes final documentation.
NTLMv1 protocol removal leaves an SSO cryptography concern
Microsoft distinguishes between removal of the NTLMv1 protocol and the remaining use of NTLMv1-derived cryptography in particular sign-on flows. Its Windows Server documentation says NTLMv1 has been removed. That does not mean every NTLMv1-derived credential path has immediately stopped working.
The important operational case is domain-joined MS-CHAPv2 single sign-on. Microsoft warns that some Wi-Fi, Ethernet, and VPN deployments can still rely on NTLMv1-derived credentials in these SSO scenarios. A network may therefore appear unaffected by NTLMv1 protocol removal yet still have a sign-on dependency that becomes visible when the related protection is enforced.
Microsoft has scheduled the default BlockNtlmv1SSO behavior to change from Audit to Enforce in October 2026, but only on systems where that registry setting has not already been deployed. This date is provisional and may change. Administrators should not wait for an assumed deadline: identify affected MS-CHAPv2 SSO profiles now, particularly for managed wireless, wired 802.1X, and VPN access.
The distinction between SSO and manual entry matters during testing. Where the affected SSO flow no longer works under enforcement, manually supplied credentials can continue to work. That may prevent a complete loss of access, but it is not a satisfactory silent fallback for organizations expecting passwordless or seamless connectivity. It can generate support calls, disrupt unattended connection behavior, and conceal a configuration problem until users move between networks or work remotely.
NTLMv2 remains a separate, longer-term concern. Microsoft says LANMAN and NTLMv2 are deprecated and no longer under active feature development. NTLMv2 continues to work for now, but Microsoft says it will be removed from Windows Server in a future release.
For administrators, this creates two cleanup tracks. First, test and remediate NTLMv1-derived MS-CHAPv2 SSO dependencies ahead of the provisional enforcement change. Second, do not interpret continued NTLMv2 operation as a long-term commitment. Applications and appliances with NTLMv2 dependencies can take substantial time to identify, update, replace, or isolate—especially where a vendor no longer actively maintains the product.
A practical migration plan for Windows organizations
A successful NTLM retirement program is as much about ownership as technology. Start by giving the work a defined scope: endpoints, servers, SMB paths, web applications using integrated authentication, scheduled tasks, services, devices, VPN-adjacent infrastructure, Wi-Fi and Ethernet authentication, and administrative scripts.
Then use the audit evidence to create categories:
- Easy fixes: IP-address references that can become DNS names, outdated mappings, incorrect service registrations, and no-longer-needed scripts.
- Configuration fixes: services that can use Kerberos once names, SPNs, delegation, domain connectivity, or sign-on settings are corrected.
- Compatibility exceptions: non-domain targets, third-party appliances, or products with a documented but temporary limitation.
- Replacement candidates: unsupported software or devices whose design cannot make the Kerberos transition.
Pilot restrictions with users and applications that represent a realistic cross-section of the organization. Include remote workers and users of wireless, wired, and VPN access where MS-CHAPv2 SSO is in scope. Measure failed connections and manual-credential prompts, not just reduced NTLM events. A successful pilot must show that required work still completes, that support teams can interpret failures, and that exception handling does not become so broad that it defeats the policy.
Home users and small businesses running a simple Windows setup may see little immediate change. The main effects will fall on managed networks, hybrid estates, file servers, older NAS devices, internal applications, and environments that routinely connect by IP address. Even there, the change should be manageable if organizations begin with auditing rather than emergency enforcement.
The strategic takeaway
Microsoft’s direction is clear: Windows authentication is becoming Kerberos-first, and NTLM is moving from background fallback to explicit exception. The near-term reality is more nuanced than a headline suggesting NTLM has vanished. Default disablement is planned in most cases for a future Windows Server and associated client release, Microsoft says timing and feature availability can change, and policy-based re-enablement is expected during the transition.
That nuance is not a reason for complacency. It is time to prepare. Windows 11 24H2 and Windows Server 2025 offer better visibility into why NTLM remains in use, while existing restriction and SMB-blocking controls allow carefully targeted enforcement. Organizations that inventory dependencies now, repair DNS and Kerberos configuration, test MS-CHAPv2 SSO behavior, and govern exceptions tightly will be in a much stronger position when NTLM-safe defaults arrive.