They should prioritise application compatibility, dependency mapping, and executive agreement on replacement timelines. Full shutdown works only when teams have identified which systems can move to Kerberos, federated identity, or certificates, and which systems must be upgraded or retired because they cannot survive without NTLM.
Why This Matters for Security Teams
A full NTLM shutdown is not just a protocol change. It is an identity migration problem that exposes hidden application dependencies, legacy authentication paths, and weak operational ownership. Security teams that rush to disable NTLM often discover breakage in file access, service-to-service calls, scheduled jobs, and third-party integrations that were never documented. That is why compatibility mapping and replacement planning matter more than the shutdown date itself.
NTLM also tends to surface broader identity hygiene issues. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which helps explain why legacy auth paths survive long after teams think they have been removed. In practice, NTLM is often embedded in workflows that nobody owns end to end, so the first sign of risk is usually an outage, not a policy review. Current guidance from the NIST Cybersecurity Framework 2.0 supports asset visibility and control mapping before enforcing disruptive changes. In practice, many security teams encounter NTLM failure only after a business-critical application has already fallen back to insecure authentication.
How It Works in Practice
The practical sequence is to inventory where NTLM is used, determine why it is used, and then classify each dependency by replacement path. Most teams need three buckets: systems that can move to Kerberos, systems that can shift to federated identity or certificate-based auth, and systems that require remediation, upgrade, or retirement before shutdown is realistic. This is less about a single technical switch and more about coordinated control migration across endpoints, servers, apps, and service identities.
A useful approach is to pair telemetry with ownership mapping. Authentication logs, directory reports, and application traces can reveal NTLM usage, but those signals only become actionable when linked to the business service and the accountable owner. NIST’s identity and access guidance, along with the Top 10 NHI Issues, both reinforce the same operational point: hidden credentials and undocumented dependencies are what make legacy shutdowns fail. Where service accounts are involved, teams should also review whether secrets, certificates, or managed identities can replace static authentication material.
- Map every NTLM use to a specific application, host, and owner.
- Identify the protocol replacement: Kerberos, federation, or certificates.
- Separate business-critical systems from low-risk or removable dependencies.
- Set an executive-approved timeline for testing, remediation, and cutover.
- Monitor for fallback paths that reintroduce NTLM after policy changes.
Where this guidance breaks down is in deeply embedded legacy environments with vendor-managed applications, unsupported operating systems, or cross-domain dependencies that cannot be upgraded on the organisation’s schedule.
Common Variations and Edge Cases
Tighter shutdown control often increases operational overhead, so organisations have to balance reduction in attack surface against the cost of remediation and the risk of business interruption. Best practice is evolving, and there is no universal standard for every NTLM retirement scenario because environment maturity varies so widely.
In mixed estates, some applications will support modern authentication only after configuration changes, while others require code changes or replacement. In outsourced or embedded environments, the real blocker is often contractual, not technical, because the application owner cannot change authentication behaviour without the vendor. For that reason, an explicit exception process is useful when paired with compensating controls such as network segmentation, tight service account scoping, and time-bound remediation commitments. The 52 NHI Breaches Analysis shows how often weak identity dependencies become incident pathways, which is why identity teams should treat NTLM retirement as part of a broader authentication modernisation programme, not a one-time hardening project. In environments with unmanaged third-party connectors, shutdown plans tend to fail because the dependency owner and the technical operator are not the same party.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM | NTLM shutdown depends on accurate asset and dependency inventory. |
| NIST CSF 2.0 | PR.AC | Replacing NTLM requires modern access controls and least privilege. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Legacy auth often hides service-account and secret sprawl risks. |
| NIST AI RMF | Shutdown planning needs governance, measurement, and accountability. |
Migrate NTLM use cases to Kerberos, federation, or certificates with tighter access rules.
Related resources from NHI Mgmt Group
- What should identity teams prioritise before adding quantum-related controls?
- Which identity controls should teams prioritise before expanding cloud access?
- How should healthcare teams strengthen identity security without slowing clinicians down?
- What do security teams get wrong about identity proofing in passwordless flows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
