How should security teams harden certificate templates to prevent ESC1 abuse in Active Directory Certificate Services?

Why This Matters for Security Teams

ESC1 is dangerous because certificate templates can turn ordinary enrollment rights into authentic identity impersonation, especially when templates allow subject alternative names and client authentication. That combination can let an attacker request a certificate for a privileged account and then use it to authenticate as that account. NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame the control problem: who can enroll, what attributes can be asserted, and whether approvals are enforced at issuance time.

Security teams often underestimate how quickly template misconfiguration becomes domain-wide privilege escalation, particularly when certificate services are treated as infrastructure rather than as an identity plane. In parallel, NHIMG research shows how often machine identity oversight is weak: in the Critical Gaps in Machine Identity Management report, 57% of organisations lack a complete inventory of machine identities, which makes risky templates harder to spot and govern. The real failure is usually not a single bad template, but missing ownership, weak review discipline, and no clear boundary between enrollment convenience and authentication trust. In practice, many security teams encounter ESC1 only after a certificate has already been abused for lateral movement, rather than through intentional template governance.

How It Works in Practice

Hardening certificate templates starts with treating each template as a trust policy, not a convenience setting. Review every template that permits client authentication, and remove the ability for untrusted requesters to supply arbitrary subject fields or SAN values. If a template does not need SANs, disable them. If it does need them, limit who can request them, what identities can be asserted, and whether CA manager approval is required before issuance.

There is also a lifecycle issue. Templates that remain enabled by default, or are copied from permissive legacy settings, create standing risk long after their original purpose has faded. Current guidance suggests mapping each template to a named owner, an explicit business use case, and a review cadence tied to both enrollment rights and certificate authentication behavior. Where possible, separate templates for device, service, and user scenarios so one enrollment path cannot cross trust boundaries.

Operationally, teams should:

• Restrict enrollment to approved users or groups, not broad directory roles.
• Disable unused templates and remove duplicate legacy templates.
• Require CA manager approval for templates that can authenticate as users or admins.
• Remove or tightly constrain subject and SAN supply by requesters.
• Audit who can enroll, who can approve, and which templates permit client authentication.

For baseline hardening, pair AD CS review with NIST SP 800-53 Rev 5 Security and Privacy Controls and compare template exposure to the attack paths documented in the Cisco Active Directory credentials breach analysis. These controls tend to break down in environments that allow legacy autoenrollment, broad request-agent delegation, and unmanaged template sprawl because permission paths become harder to distinguish from legitimate issuance.

Common Variations and Edge Cases

Tighter template controls often increase operational overhead, requiring organisations to balance issuance speed against abuse resistance. That tradeoff matters most where certificates support VPN, Wi-Fi, or application login and administrators are tempted to preserve broad enrollment “for reliability.” Current guidance suggests that convenience exceptions should be temporary and documented, not permanent defaults.

Some environments cannot remove SAN usage entirely because applications depend on alternative names or mapped identities. In those cases, the safer pattern is to constrain the template to a narrowly defined group, require approval for issuance, and prevent requesters from freely asserting identity attributes. There is no universal standard for this yet, but best practice is evolving toward explicit trust scoping rather than unrestricted subject control.

Another edge case is legacy PKI migration. Older templates may be copied into new CAs with inherited permissions that no longer match the intended trust model. That is where review discipline matters most: confirm whether client authentication is actually required, whether template duplication created hidden exposure, and whether approval workflows are enforced at the CA layer, not just in documentation. For teams building a broader NHI inventory and ownership model, NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is a useful reference point. The strongest controls still fail where template ownership is unclear and certificate issuance remains governed by inherited directory permissions rather than explicit policy.

Related resources from NHI Mgmt Group

• How should security teams prevent unwanted persistence in Active Directory and Entra ID?
• What breaks when Active Directory Certificate Services templates are too permissive?
• How should security teams prevent malicious Active Directory changes before they are committed?
• How should security teams use decoy certificate templates to detect AD CS abuse early?