Mixed environments expand the attack surface because NTLM lacks mutual authentication and can be relayed if controls are inconsistent. Legacy applications, unenforced signing, and weak session protections give attackers room to capture and reuse authentication material. Kerberos reduces this risk, but as long as NTLM remains enabled, defenders must treat every unprotected path as a potential relay opportunity.
Why This Matters for Security Teams
Mixed NTLM and Kerberos estates matter because attackers do not need to “break” authentication when they can redirect it. NTLM remains relay-friendly whenever signing, channel binding, or endpoint protections are inconsistent, while Kerberos only lowers exposure when it is actually enforced end to end. That makes the real issue operational drift: a modern directory can be designed for stronger authentication and still contain legacy paths that quietly preserve relay risk. NHI Mgmt Group’s 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge show how small identity control gaps persist long after teams believe they have modernised. Microsoft’s own hardening guidance is useful here, but the practical lesson is simpler: if any NTLM path remains reachable without strong relay protections, the environment is only as strong as its weakest exception. In practice, many security teams discover relay exposure only after an old service or privileged workflow has already been abused, rather than through intentional testing.
How It Works in Practice
ntlm relay works because the attacker forwards authentication messages to another service that accepts them as valid, which becomes far easier when a mixed environment has uneven policy enforcement. Kerberos introduces mutual authentication and ticket-based controls, but that benefit does not automatically extend to applications, appliances, and legacy workflows that still fall back to NTLM. The danger is not just the protocol choice, but the translation layer between systems that do and do not require signing, channel binding, SMB protections, or LDAP relay mitigation.
Security teams should treat the problem as a control-mapping exercise, not a protocol preference debate. Practical hardening usually includes:
- Disabling NTLM where business dependencies permit it.
- Enforcing SMB and LDAP signing consistently across all tiers.
- Blocking inbound NTLM on high-value servers and domain controllers.
- Auditing fallback paths in browsers, print services, file shares, and service accounts.
- Testing for relays in lab conditions before assuming production policy is uniform.
For broader identity context, NHI Mgmt Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now highlights why identity sprawl and weak lifecycle discipline magnify access risk, even when the immediate issue is human authentication. Current guidance from OWASP Active Directory attack defense guidance and Microsoft hardening material aligns on the same point: eliminate inconsistent trust paths, then verify that every remaining path enforces the same protections. These controls tend to break down when line-of-business systems, third-party appliances, or older directory-integrated services cannot support signing or modern auth at all.
Common Variations and Edge Cases
Tighter authentication hardening often increases operational overhead, requiring organisations to balance relay resistance against compatibility risk. That tradeoff is especially visible in hybrid estates where Windows, Linux, application proxies, and third-party devices all authenticate differently. Best practice is evolving, but there is no universal standard for this yet: some teams can fully retire NTLM, while others must preserve it temporarily with compensating controls and a clear decommission plan.
Edge cases include service accounts that authenticate from legacy hosts, applications that silently downgrade to NTLM when Kerberos fails, and cross-domain or cross-forest dependencies where trust boundaries are not consistently protected. A false sense of safety also appears when Kerberos is enabled on paper but relay exposure still exists through web authentication, LDAP bind paths, or misconfigured file shares. NHI Mgmt Group’s 52 NHI Breaches Analysis and the Anthropic AI-orchestrated cyber espionage campaign report both reinforce a practical lesson: once an attacker can chain weak trust assumptions across systems, the original protocol boundary matters less than the weakest enforcement point. The safest approach is to reduce NTLM exposure, segment privileged paths, and continuously validate that every authentication fallback is intentional.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Addresses weak non-human auth paths and legacy credential exposure. |
| NIST CSF 2.0 | PR.AC-3 | Covers access enforcement and authentication control consistency. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires explicit verification of each access path. |
| NIST AI RMF | Supports governance of trust assumptions and operational risk. | |
| CSA MAESTRO | Useful where agentic or automated workflows consume mixed auth paths. |
Require runtime approval and scoped identity for any automated workflow using legacy auth.
Related resources from NHI Mgmt Group
- Why does NTLM create a larger lateral movement risk in enterprise environments?
- Why do OAuth tokens and SaaS integrations create outsized breach risk in connected environments?
- Why do privileged accounts with service principal names create unnecessary exposure in Active Directory?
- Why do service accounts and personal access tokens create more risk in CI/CD environments when they are left standing?
