Start by mapping every Active Directory Certificate Services server and checking whether NTLM authentication is already reaching it. If there is no legitimate NTLM traffic, the safest move is to disable NTLM to those servers. If NTLM is in use, narrow the blast radius by restricting NTLM or enabling Extended Protection for Authentication on the certificate services that need it.
What to check before you change NTLM on AD CS
When PetitPotam-style relay is a concern, the first job is to establish whether certificate services are actually reachable over NTLM in your environment. That starts with inventorying every AD CS server, then verifying where NTLM is accepted, where it is required, and whether any legitimate workflows still depend on it. A narrow, evidence-based view avoids breaking enrollment paths while you remove an unnecessary relay path.
If NTLM is absent or truly unnecessary, disable it to the certificate services first rather than treating relay as a theoretical risk. If NTLM is still in use, the safer first move is to limit where it can be used and reduce the trust the service places in it, because the attack succeeds by turning a valid authentication path into a relayable one.
Why relay resistance in AD CS is an access-control problem
The practical issue is not just “NTLM is weak.” The issue is that AD CS can become a high-value target when a server accepts relayed authentication and then issues certificates or otherwise honors the relayed identity. That turns an authentication edge into a privilege edge. The more broadly NTLM is accepted, the easier it is for an attacker to convert one coerced authentication into durable access.
Two controls matter most in the first pass. One is reducing or removing NTLM exposure to the certificate service. The other is Extended Protection for Authentication, which helps bind authentication to the protected service and makes relay materially harder where it is supported. In AD CS environments, those two choices determine whether the service can be used as a relay target at all.
As a practical reference point, NHIMG’s Cisco Active Directory credentials breach illustrates how credential material tied to directory access can become a lateral-movement problem once trust boundaries are too loose. For broader context on the identity material that relay attacks try to exploit, see Ultimate Guide to NHIs, what are Non-Human Identities.
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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Relay abuse in AD CS depends on exposed auth paths and credential material. |
| NHI-03 — Overprivileged Non-Human Identities | AD CS relay impact grows when certificate services confer excessive access. | |
| Recommendation — Reduce relay exposure by removing unnecessary NTLM paths and tightening certificate-service trust boundaries. Limit certificate-service permissions so relayed authentication cannot yield broad access. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The question is about restricting authentication paths to a critical service. |
| PR.PT — Protective Technology | Extended Protection for Authentication is a protective mechanism against relay. | |
| Recommendation — Restrict authentication pathways to the minimum set required for AD CS operation. Enable service protections that bind authentication and reduce relayability. | ||
| CIS Controls v8 | 6.3 — Promptly Remediate and Revoke Access | Removing unnecessary NTLM access to AD CS is a prompt access reduction action. |
| 16.11 — Securely Manage Certificates | AD CS is a certificate-management service directly implicated in the relay risk. | |
| Recommendation — Revoke unneeded NTLM access paths to certificate services. Harden certificate services so authentication cannot be relayed into certificate issuance. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Never Trust, Always Verify | Relay succeeds by abusing trust in an authentication path that should be verified. |
| Recommendation — Apply stronger verification to certificate-service access instead of trusting NTLM alone. | ||
| NIST SP 800-63 | IAL/Authenticators — Authenticator Assurance and Binding | The issue concerns whether an authentication method can be safely trusted for access. |
| Recommendation — Use stronger authenticator binding where service access must resist relay. | ||
Practitioner Guidance
What to prioritise: Treat AD CS as a boundary service and confirm whether it truly needs NTLM before making any broader hardening changes. If it does not, removal is the cleanest risk reduction. If it does, constrain usage to the smallest possible set of servers and paths.
What to verify: Check not only whether NTLM reaches the server, but also whether enrollment, management, or legacy client workflows rely on it. The common failure mode is disabling the wrong authentication path and discovering the dependency only after service impact.
Decision rule: If the certificate service can function without NTLM, turn it off there first. If it cannot, enable protection that weakens relayability and document the exception, because “accepted for compatibility” should be a temporary state, not a default.
Practitioner takeaway: The right first move is to prove whether NTLM is a real dependency on AD CS, then either remove it or tightly bound it. That sequence reduces relay risk without guessing at the compatibility blast radius.
Related resources from NHI Mgmt Group
- Why are NHIs a critical concern for security teams?
- What should security teams do first after discovering a collaboration account has exposed internal messages and credentials?
- How should teams reduce the risk of exposed AI credentials being abused?
- What steps should security teams take to prevent Shadow AI risks?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
