TL;DR: AD CS template abuse is turning certificate issuance into a privilege path, with Netwrix highlighting ESC1 to ESC3 patterns and suspicious SAN UPN stamping. Certificate governance now has to treat template enrollment as an escalation control, not a routine check.
Editorial analysis by NHI Mgmt Group, based on content published by Netwrix: “Introduction to Netwrix's Security Research”.
Key questions
Q: Why does certificate validation belong in identity governance discussions?
A: Because validation determines which domain or IP address can receive a trusted certificate, which is a governance decision about authority and lifecycle control.
Q: What are the signs that an AD CS attack path is being abused?
A: Look for unusual certificate template requests, SAN or UPN values that do not fit normal enrolment patterns, and tooling associated with privilege escalation attempts.
Q: What breaks when AD CS templates are too permissive?
A: Permissive templates break the assumption that certificate issuance is tightly bound to the approved identity.
Practitioner guidance
- Review certificate template enrolment rights Map every template that can influence authentication outcomes, then remove enrolment paths that let low-trust identities request privileged certificates.
- Block user-controlled SAN and UPN handling Disable or tightly constrain templates where requesters can stamp UPN values into SAN fields or otherwise shape the identity claim in the certificate.
- Add AD CS events to identity monitoring Alert on suspicious template enrolments, unusual certificate requests, and tooling patterns associated with privilege escalation attempts.
Bottom line: AD CS template misconfiguration is not a narrow PKI problem when it can be used to escalate identity and privilege across the directory.
Glossary terms: Active Directory Certificate Services, Certificate template, SAN UPN Stamping, Privilege Escalation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
AD CS attack paths should now be treated as identity governance failures, not PKI edge cases. When a certificate template can be used to carry a privileged identity claim, the relevant control question is who can transform one identity state into another. That is an access governance issue with direct blast-radius implications, not a back-office certificate concern. Practitioners should bring AD CS into the identity control plane rather than leaving it in infrastructure administration.
A question worth separating out:
Q: How should teams decide whether AD CS belongs in their attack-path programme?
A: If a certificate template can change who a certificate authenticates as, AD CS belongs in attack-path governance. Teams should treat any path from ordinary user access to administrative identity via certificates as a priority for monitoring, policy tightening, and review. That is the point where PKI becomes a privilege pathway, not just an infrastructure service.
👉 Read our full editorial: Identity research is now focusing on AD CS attack paths