Teams should move domain controllers to level 3 when legacy inbound compatibility must remain. Level 3 preserves that compatibility while removing the outbound NTLMv1 path, which is the part that creates the attack surface attackers actually exploit.
Why level 3 is usually the better default for domain controllers
Level 3 is the safer operating point when you still need legacy inbound compatibility, because it keeps the older client path available without leaving the controller exposed to the weaker outbound path. That matters on domain controllers because the main question is not whether legacy traffic can arrive, but whether the controller should still initiate NTLMv1-based outbound authentication where abuse risk is materially higher.
The practical distinction is that inbound compatibility supports continued service, while outbound NTLMv1 expands the attack surface. Attackers target the weaker direction because it can be abused for relay, credential exposure, or coercion paths that are harder to justify on a modern domain controller. Level 3 keeps the compromise boundary tighter without forcing an immediate legacy cutover.
That framing is consistent with broader identity and access control practice: Cisco Yanluowang breach 2022 shows how attackers move from access acquisition to abuse of trusted machine and domain infrastructure once they find a weak path.
What changes between legacy compatibility and attack surface
Keeping level 2 can look attractive because it preserves more legacy behavior, but it does so by retaining more outbound compatibility than most teams actually need. On a domain controller, that extra compatibility is not neutral, it is an additional trust path that can be used during lateral movement or to pivot through systems that still accept older authentication behavior.
Level 3 is the better compromise when the business still depends on old inbound clients or services. It allows the environment to tolerate legacy participation at the edge while reducing the controller’s own participation in outdated authentication flows. That is the right trade when the goal is containment: let the legacy app connect, but do not let the controller keep making the weaker decision on its own.
This is where protocol-level controls matter. The outbound side is often the part that defenders underestimate because it is less visible than failed logons or obvious account lockouts. But the control question is simple, what path can still be used to authenticate in a way that expands blast radius if it is abused?
When to keep level 2, and when not to
Level 2 should be treated as a temporary compatibility exception, not the steady state, when a specific legacy dependency truly breaks at level 3 and there is no short-term remediation path. In that case, the team should document the dependency, constrain the affected systems, and treat the exception as a migration problem with an expiry date rather than as an acceptable long-term domain-controller posture.
Move to level 3 when the legacy need is only inbound compatibility and not a requirement for the domain controller to continue initiating weaker outbound authentication. If the controller is still allowed to use that weaker path, you are preserving convenience at the cost of a broader compromise path for attackers.
For identity and access hardening, the useful comparison is not “does it still work,” but “what trust is still being extended?” That is why the control decision belongs with the systems and identity owners who can weigh compatibility against the security boundary, not with application owners alone.
Risk and Threat Considerations
Legacy authentication settings on domain controllers create a predictable attack opportunity when they preserve outdated outbound behavior. The risk is not abstract, attackers look for the weakest remaining trust path because once a domain controller can be induced to authenticate in a weaker way, the result can be relay, credential abuse, or further movement into the directory trust fabric.
Failure mechanism: level 2 preserves more legacy behavior than level 3, which can leave an outbound NTLMv1 path available for abuse. An attacker who can influence that path may be able to coerce or relay authentication in ways that defeat the intended containment boundary.
Impact: the compromise can extend beyond a single legacy app and into domain-level exposure, especially when the controller is treated as a trusted initiator. That increases the chance of lateral movement, privilege abuse, and a broader incident than the original compatibility issue would suggest.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Domain controllers authenticating legacy systems still require constrained machine authentication paths. |
| AC-6 — Least Privilege | Level 3 reduces unnecessary authentication privilege exposure on the controller. | |
| Recommendation — Restrict weak machine authentication paths and require stronger authenticators where possible. Limit controller authentication paths to the minimum required for business compatibility. | ||
| CIS Controls v8 | CIS-5 — Account Management | Legacy authentication settings affect how accounts and trust paths are managed on controllers. |
| Recommendation — Remove obsolete authentication paths and review exceptions on a scheduled basis. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The question is about reducing excess trust in authentication behavior on domain controllers. |
| Recommendation — Apply least privilege to authentication flows and retire unnecessary legacy protocols. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | The setting directly concerns secure authentication behavior and legacy compatibility. |
| Recommendation — Enforce secure authentication settings and phase out weaker controller authentication methods. | ||
Practitioner Guidance
Decision rule: if the only reason to stay at level 2 is legacy inbound compatibility, treat level 3 as the preferred target and keep the exception bounded to the systems that truly need it. If the legacy app needs outbound behavior from the domain controller, assume the risk is structural and plan a remediation path rather than accepting the setting indefinitely.
What to verify: confirm whether any domain controller actually needs outbound NTLMv1 for business function, or whether the dependency is really on an application, service account, or trust relationship that can be changed. The critical check is whether the compatibility requirement sits on the client side or on the controller side.
Practitioner takeaway: preserve legacy inbound compatibility where you must, but do not keep legacy outbound trust just to avoid migration work. On domain controllers, the safer posture is the one that reduces the controller’s ability to participate in weak authentication while the legacy estate is still being retired.
Related resources from NHI Mgmt Group
- How should security teams harden domain controllers that still need legacy authentication support?
- How should security teams decide whether to keep a legacy SEG or move to an API-based email security model?
- How do security teams decide whether to keep legacy search workflows or move to a piped query model for investigations?
- What happens when organisations keep custom legacy apps on AD while modern identities move elsewhere?