Organisations should move local-account use cases to Kerberos alternatives such as local KDC or IAKerb where possible, then treat any remaining NTLM requirement as a temporary exception with a named owner. The key decision is whether the access path can be preserved without leaving hash replay and relay exposure in place.
What to do with NTLM-bound local accounts
local account that still depend on NTLM should not be left as a steady-state control. Treat them as a migration problem first, an exception second. Where the use case is legitimate, move to a Kerberos-based alternative that preserves local access without keeping password hash replay or relay exposure as an accepted operating condition.
The practical objective is to reduce the number of places where NTLM remains necessary, then constrain the remainder with explicit ownership, review, and expiry. That keeps the organisation focused on the access path, not just the protocol name.
Why local NTLM use is an exposure problem, not just a legacy preference
NTLM is weakly suited to modern local-account use because it preserves replayable credential material and is more forgiving of relay-style abuse. When a local account cannot be replaced, the organisation is carrying an authentication design that is inherently harder to harden, audit, and scope than a Kerberos-based alternative. This is why the question is really about exposure management, not compatibility alone.
For local use cases, the key distinction is whether authentication can be re-established on a stronger basis without breaking the business function. If the answer is yes, the remaining work is implementation and transition. If the answer is no, the organisation should assume the exception carries continuing security debt until it is removed.
How to phase out NTLM without breaking necessary local access
Start by inventorying where local accounts still authenticate with NTLM and identify which of those can move to a local KDC or IAKerb-supported path. Those options are valuable because they let you preserve the local-account pattern while shifting the trust model away from NTLM dependence.
- Prioritise interactive or administrative paths first, because they carry the clearest abuse potential.
- Separate accounts that can be migrated immediately from those that require a temporary exception.
- Attach each exception to a named owner, an expiry condition, and a documented reason the stronger path is not yet available.
That sequencing matters because the hardest part is not the protocol change itself, but preventing temporary compatibility from becoming permanent reliance.
Risk and Threat Considerations
Keeping NTLM in place for local accounts preserves replay and relay opportunities that attackers can use after partial compromise. The risk is highest where the account has broad local reach, repeated interactive use, or access paths that are difficult to monitor consistently.
Failure mechanism: An attacker who obtains or coerces NTLM-compatible credential material can reuse it against local services, or relay authentication where the environment still accepts it, turning a compatibility exception into a lateral-movement path.
Impact: The result can be unauthorized local access, privilege escalation, or wider credential exposure, especially if the account is reused across systems or left without a clear expiration path.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of account authenticators and NTLM exception handling. |
| IA-9 — Service Identification and Authentication | Applies when local service or workload accounts still authenticate on the legacy path. | |
| AC-6 — Least Privilege | Limits the blast radius of any local account that must remain temporarily on NTLM. | |
| Recommendation — Rotate and retire NTLM-bound authenticators under a tracked exception process. Use stronger service authentication methods where local accounts must remain machine-accessible. Restrict NTLM-dependent local accounts to the minimum privileges needed. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Supports the shift away from implicit trust in legacy local authentication paths. |
| Recommendation — Treat legacy local authentication as untrusted and require explicit verification for access. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Legacy NTLM use on local accounts is an insecure authentication pattern for machine-bound identities. |
| Recommendation — Replace NTLM with stronger authentication for any remaining non-human local access. | ||
Practitioner Guidance
What to prioritise: Replace NTLM-dependent local accounts that support administration, service access, or repeated interactive use before tackling low-frequency edge cases. Those accounts create the highest blast radius if the old protocol remains in place.
Decision rule: If the access path can be preserved through Kerberos alternatives such as local KDC or IAKerb, treat that as the preferred route. If not, keep NTLM only as a time-bound exception with an owner, a review date, and a clear exit criterion.
What to verify: Confirm that any remaining exception is truly required by the application or device path, not by convenience, undocumented dependency, or lack of migration effort.
Practitioner takeaway: The goal is not to keep local access alive at any cost, but to ensure that every remaining NTLM dependency is consciously accepted, tightly owned, and on a path to removal.