NTLM Retirement: An SMB Authentication Migration Plan

A file share can work every morning while relying on an authentication method your business needs to retire. The same can be true of a scanner that deposits invoices, a finance application, or an overnight task nobody has reviewed recently.

For an SMB, the right NTLM migration plan starts with those business workflows, not a fleet-wide blocking switch. Find the dependencies, prove a supported replacement, then restrict NTLM in controlled groups with a tested recovery path. This guide separates Microsoft's published changes from the practical decisions your internal IT team or managed service provider needs to make.

What NTLM retirement means, and what it does not

NTLM is a legacy Windows authentication family. Microsoft's roadmap places default blocking of network NTLM in the next major Windows Server release and associated Windows client releases. That phase leaves NTLM installed, with explicit policy-based re-enablement available. It is not a statement that every existing Windows device has already stopped accepting NTLM.

The roadmap also describes IAKerb, which addresses some domain-controller connectivity constraints, and Local KDC, which addresses local-account authentication. Their second-half 2026 target is a roadmap, not proof that either capability is supported and enabled on your particular build. Check release-specific documentation before relying on them. Microsoft explicitly warns that timing and availability can change. Read Microsoft's phased NTLM roadmap.

NTLMv1 is a separate milestone: Microsoft lists it as removed beginning with Windows 11, version 24H2 and Windows Server 2025. That does not mean NTLMv2 has disappeared. All NTLM versions are deprecated; changing an application to use Negotiate lets it prefer Kerberos but can still allow NTLM fallback. Removed Windows features and deprecated Windows features explain the distinction.

A separate October 2026 change to check

On affected Windows versions, the October 13, 2026 security update changes the default for NTLMv1-derived single-sign-on credentials to enforcement when Credential Guard is disabled and the relevant BlockNtlmv1SSO setting is absent. MS-CHAPv2-based Wi-Fi, Ethernet, or VPN sign-on can be affected. This is not a universal NTLMv2 shutdown. If connectivity changed after patching, investigate this specific control rather than undoing unrelated security policies. Microsoft's NTLMv1 change guidance describes the conditions and audit events.

Start with an authentication dependency register

ITECS recommends giving every critical workflow both a business owner and a technical owner. The business owner confirms that an invoice, shipment, report, or remote session actually completes. The technical owner records the authentication evidence and manages the change.

Inventory Windows edition, version, build, update level, support status, device join state, and application or firmware version. Include resource servers and domain controllers, not just employee PCs. A product name such as “Windows 11” is not enough to establish which audit or blocking controls are available.

Use this worksheet to turn the inventory into testable work:

Record configuration references, not passwords or reusable secrets. Keep credential material in your approved vault. Protect diagnostic exports because account names, system names and network details can reveal sensitive information.

Audit NTLMv1 and NTLMv2 before changing enforcement

Microsoft's enhanced audit logging covers Windows 11 24H2 and later, Windows Server 2025, and Windows Server 2022 and 2019 with updates released October 13, 2026 or later. Verify the installed update and logging policy rather than assuming every server already provides the same evidence.

The Microsoft-Windows-NTLM/Operational log includes client events 4020/4021, server events 4022/4023, and domain-controller events 4030–4033. Inspect the recorded NTLM version, process and target, plus the client event's fallback reason. A warning is not, by itself, proof that authentication was blocked. Microsoft's enhanced NTLM auditing reference documents these fields and the applicable builds.

Our suggested collection window should include your actual operating cycle: remote work, overnight jobs, finance close and infrequent vendor access. Start collection before the pilot, verify that events are arriving, and retain a baseline. An empty dashboard can mean an idle workflow or missing telemetry; it does not establish that NTLM is absent.

Separate v1 findings, v2 dependencies, unknown-version findings and systems without adequate visibility. For older or unsupported systems, use their documented audit options and an upgrade plan. Do not label them safe because they lack the newer events.

Prove Kerberos for the real connection

Kerberos uses tickets issued by a trusted Key Distribution Center. In a conventional Active Directory environment, the KDC runs on domain controllers. That makes identity, service naming and connectivity part of the migration, not just an endpoint setting. Microsoft's Kerberos overview explains the client, service and KDC relationship.

Check hostnames, aliases and SPNs

A service principal name, or SPN, identifies a service instance and associates it with the account used to run that service. Microsoft requires the SPN to be registered correctly for Kerberos authentication. See Microsoft's SPN guidance.

Have the administrator check the intended service account, missing or duplicate registrations, DNS resolution and time synchronization. Do not “fix” an unknown SPN by assigning it to whichever account is convenient. Test the name users actually select, including aliases saved in shortcuts and application configuration.

IP-address paths deserve their own review. Windows does not normally attempt Kerberos when the hostname is an IP address. Microsoft documents an explicit IP-SPN configuration for situations where DNS names cannot be used, but recommends hostname-based access where possible. Replacing \\IP-address\share with a name is a candidate repair, not proof of success. Kerberos over IP guidance explains the limits.

Separate domain identities from local accounts

A local NAS account or workgroup account is not automatically an Active Directory identity. Microsoft documents NTLM use for standalone systems and local-account network authentication. Do not assume that a domain migration recipe covers these connections. Microsoft's NTLM overview describes those scenarios.

For each local-account dependency, obtain a vendor-supported path: appropriate domain integration, an application authentication change, a supported replacement product, or a narrowly approved temporary exception. Joining a PC to Microsoft Entra ID does not, by itself, prove that an older appliance can use Kerberos.

Test service accounts and cross-domain paths separately

A technician's interactive login is not a substitute for testing a scheduled task's identity. Confirm who owns service-account lifecycle, privileges and recovery. For cross-domain applications, include both sides of the trust and any multi-hop access. Escalate delegation changes to the identity owner; do not enable broad delegation merely to make a pilot pass.

Use authentication logs and service-ticket evidence tied to the tested connection. An existing ticket somewhere in a session, or a successful application login with fallback still enabled, is not enough. Repeat representative operations with fresh connections so cached sessions do not hide a dependency.

Pilot blocking without confusing SMB with all network authentication

Windows 11 24H2 and later and Windows Server 2025 and later provide an SMB-client NTLM blocking capability for outbound SMB connections. It is narrower than blocking NTLM across every protocol. The destination must support a usable alternative; Microsoft's documented configuration includes the Lanman Workstation policy and Set-SmbClientConfiguration -BlockNTLM $true. This is an administrator-controlled pilot action, not a command to run across your fleet immediately. Microsoft's SMB NTLM blocking guidance also documents server exceptions.

ITECS recommends a representative pilot rather than a group consisting only of IT staff. Include a finance user, a remote worker, a branch workflow, a scanner destination and an unattended job when those exist in your business. Do not experiment on the only functioning copy of a critical service.

1. Prepare: export the current relevant policy settings, record the pilot membership and confirm administrative recovery access that does not depend on the path being restricted.
2. Repair: address known naming, application and identity issues first. Confirm vendor support and retain before-and-after configuration evidence.
3. Restrict: apply the smallest relevant control to the pilot. Keep unrelated authentication, signing and encryption changes out of the same test.
4. Validate: run the worksheet transactions, review protocol evidence and confirm expected access denials as well as permitted access.
5. Expand or stop: obtain business-owner approval before the next group. Stop if a critical workflow fails, unexpected access appears, or the evidence is incomplete.

Make exceptions temporary and rollback specific

An exception should name the affected source systems, destination, business function, risk owner, compensating safeguards, vendor ticket, remediation date and next review. A blanket “legacy systems” exemption is not a migration plan. Ask vendors for the exact supported software or firmware version and authentication method, not a general promise that the product supports Windows.

Before rollout, write down the precise policy or configuration to restore, who can authorize it, and how to confirm effective settings on affected machines. Roll back only the failing pilot control to the documented prior state, then repeat the critical workflow and review the logs. A policy rollback cannot restore a protocol already removed from the operating system.

Do not recover availability by enabling guest access, broadening permissions, disabling unrelated protections or sharing privileged accounts. If a supported repair is unavailable, make the replacement budget and time-limited risk decision explicit.

Define completion in business terms

The finish line is not “the policy deployed.” It is a signed-off set of workflows, with evidence that the intended authentication works and unacceptable fallback is restricted within the approved scope.

• Operations: critical tasks pass under normal user and service identities, including remote and unattended cases.
• IT: tested device builds, effective policies, authentication observations and configuration versions are recorded.
• Security: residual dependencies have named owners and expiry dates; exceptions are not silently expanding.
• Service desk: staff know the rollout dates, likely symptoms, escalation route and approved recovery procedure. Users know where to report failures without sending passwords.
• Management: unresolved vendor work, replacement costs and accepted business risks are visible.

Continue checking after restarts, patch cycles, application upgrades and the next infrequent business process. Review the exception register regularly and remove exceptions only after the affected workflow passes its agreed test.

Choose the next manageable step

Start with one department's dependency register and one representative pilot. For a managed or co-managed environment, agree which work belongs to internal IT, the MSP, the application vendor and the business owner before changing enforcement.

Explore ITECS cybersecurity consulting and managed IT coverage, or contact ITECS about an authentication migration review. Bring an inventory and known dependencies, not credentials. The scope should follow your environment's evidence rather than a generic deadline.

---

Research checked October 16, 2026. This AI-assisted ITECS editorial guide combines linked Microsoft documentation with an original planning checklist; it is not a tenant-specific assessment or a claim of completed client migration. Recheck vendor release notes and the linked guidance before implementation. Update this plan when Microsoft changes availability, defaults or audit requirements.