Microsoft classifies all versions of NTLM as deprecated. NTLM remains available in supported Windows releases today, but Microsoft is moving Windows toward Kerberos-based alternatives and has described a phased path toward network NTLM being disabled by default in future client and server releases. Microsoft expressly notes that roadmap dates and feature availability can change, so organizations should treat the announcement as a direction of travel—not as permission to assume a fixed cutoff date.
\n\nMicrosoft identifies important weaknesses in NTLM, including the absence of server authentication and exposure to relay, replay, pass-the-hash, and other attacks. Kerberos uses tickets and can authenticate the service being reached. That difference matters: a user should not merely prove who they are while unknowingly sending an authentication exchange to the wrong server.
\n\nCurrent Windows Server 2025 and Windows 11 version 24H2 capabilities include enhanced NTLM auditing and an SMB client option that blocks NTLM for outbound remote connections. These are useful migration tools, but SMB blocking is only one control surface. NTLM can remain in web applications, database connections, management products, appliances, scheduled jobs, and other Windows authentication paths.
\n\nNTLM commonly appears because Kerberos cannot complete or because an application explicitly requests legacy authentication. Examples include connecting by IP address rather than a service name, missing or duplicate service principal names, name-resolution problems, local accounts, workgroup devices, unsupported trust paths, old network storage, hard-coded authentication providers, or products that never implemented Kerberos.
\n\nMicrosoft’s audit policies can record NTLM activity without blocking it. Domain-controller, incoming, and outgoing perspectives are all relevant because no single log necessarily explains the full transaction. Audit records are security-sensitive: they reveal identities, systems, and legacy paths, so access and retention should be controlled.
\n\nBegin with a written scope and a rollback owner. Enable supported NTLM auditing on representative domain controllers, member servers, and clients, then forward the resulting events to a protected central location. Observe more than an ordinary workday. Include month-end jobs, backups, disaster-recovery tests, remote maintenance, badge and video integrations, scanner workflows, and applications used only during an outage.
\n\nTurn observations into a register containing the source, destination, account, service, business purpose, owner, frequency, criticality, likely cause, remediation plan, test evidence, and target retirement date. Do not classify an entry as harmless simply because it is infrequent. A once-a-month backup or emergency administration path may be more important than a high-volume workstation process.
\n\nStart with a lab that represents real production dependencies. Move to a small pilot containing knowledgeable users and noncritical services, then expand by application group, server role, or site. Modern Windows systems can block outbound SMB NTLM independently, which may provide a useful early control where the required servers support Kerberos.
\n\nEvery exception should identify the exact system, protocol, approving owner, compensating safeguards, review date, and expiration. Avoid broad domain-wide exceptions created only to clear an error. Monitor both blocked attempts and unexpected operational failures during every ring.
\n\nCompletion means that a representative audit period shows no unexplained NTLM, critical workflows pass with blocking enabled, emergency and recovery procedures have been tested, and remaining exceptions are narrow and owned. Retain the before-and-after evidence as part of the identity-system change record.
\n\n