Start by inventorying every certificate template that enables authentication, especially EKUs such as Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose, or SubCA. These settings can let a certificate authenticate as the subject until it is revoked or expires. Prioritise templates that are broadly enrollable, then remove unnecessary authentication EKUs and review the enrollment scope.
Why authentication-capable AD CS templates deserve first-pass inventory
AD CS templates that can issue authentication-capable certificates change the trust boundary because the certificate can function as proof of identity, not just encryption. The first task is to inventory every template that can be used for logon or other authentication flows, then identify which ones are broadly enrollable and which ones are tightly controlled. That is what determines blast radius and prioritisation.
Templates with Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose, or SubCA are especially important because they can be used to authenticate as the certificate subject until the certificate is revoked or expires. That makes the template itself a security control point, and a potential escalation path if its enrollment scope is too wide.
For a team trying to decide where to begin, the practical question is not whether certificates exist, but whether any template can produce a credential that other systems will trust for authentication. If the answer is yes, template inventory becomes a prerequisite to safe change.
Why broad enrollment scope raises the risk
A broadly enrollable authentication template creates a larger pool of potential misuse than a tightly scoped one. If many users, devices, or service accounts can request it, then compromise of any eligible principal can produce a reusable authentication artifact that may survive account hygiene problems, delayed revocation, or incomplete monitoring.
That is why prioritising the widest enrollment paths is the right first move. Broad enrollment combined with authentication EKUs can turn a certificate template into a high-value access path, especially when administrative review assumes the template is only being used for internal convenience or legacy compatibility.
Once the inventory is complete, teams should separate templates that are truly needed for authentication from those that only inherited authentication EKUs by default. Removing unnecessary EKUs and narrowing enrollment scope reduces the chance that the certificate becomes a standing path into systems that trust it.
What to review before changing templates
Before modifying anything, teams should confirm how each template is used, who can enroll, whether autoenrollment is enabled, and which systems accept the resulting certificate for authentication. The important distinction is between a template that exists in the environment and a template that can actually be used to gain access.
Review certificate lifetime, revocation behaviour, and any dependency on directory sync or application-specific trust. A template may look low risk in isolation but still matter if it is trusted by VPN, remote access, or internal applications that map certificate presentation directly to identity.
That review should also check for overlap between templates. If multiple templates provide the same authentication outcome, retire or restrict the weaker one so that administrators do not preserve unnecessary parallel paths to the same trust decision.
Risk and Threat Considerations
Authentication-capable templates can be abused as durable access credentials when enrollment is too broad or template settings are too permissive. The main exposure is certificate-based impersonation, where an attacker with enrollment access can obtain a certificate that remains accepted even after passwords are changed.
Failure mechanism: Overly broad enrollment, excessive EKUs, or weak template governance lets a requester obtain an authentication certificate that other systems trust as a valid identity assertion. If revocation is slow or poorly enforced, the resulting access can outlast the original compromise window.
Impact: An attacker may gain persistent access to internal services, privileged applications, or remote access paths without needing to keep the original account password. That increases the chance of stealthy lateral movement and makes incident containment harder.
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 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers certificate and authenticator lifecycle control for authentication-capable templates. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies because AD CS templates can serve as user authentication mechanisms. | |
| AC-6 — Least Privilege | Broad enrollment scope turns certificate issuance into excess access opportunity. | |
| Recommendation — Review and restrict template issuance paths that create authenticators. Limit certificate-based logon to explicitly approved user populations. Reduce enrollment and enrollment-agent permissions to the minimum required. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Authentication-capable certificates directly affect access decisions and trust boundaries. |
| A.8.5 — Secure authentication | Template EKUs determine whether issued certificates can authenticate users or systems. | |
| Recommendation — Restrict certificate templates that can be used for access decisions. Remove unnecessary authentication EKUs from templates. | ||
| OWASP ASVS | V6 — Authentication | Certificate-based logon is an authentication mechanism whose assurance must be controlled. |
| Recommendation — Validate that authentication paths using certificates are explicitly required and controlled. | ||
Practitioner Guidance
What to prioritise: Start with templates that combine authentication EKUs and broad enrollment, because those create the largest potential blast radius. Treat templates used for logon, smart card style authentication, or PKINIT as higher priority than templates that are only for non-authentication use.
What to verify: Confirm not just who can enroll, but whether the certificate can be mapped into an authentication flow anywhere in the environment. Also verify whether the certificate lifetime and revocation process are short and reliable enough to support your incident response expectations.
Practitioner takeaway: The safest first step is to inventory authentication-capable templates by reach and trust, then reduce the number of templates that can mint a certificate the environment will accept as identity.
Related resources from NHI Mgmt Group
- How should security teams harden certificate templates to prevent ESC1 abuse in Active Directory Certificate Services?
- How should security teams govern Active Directory service accounts?
- What breaks when Active Directory Certificate Services templates are too permissive?
- How should security teams govern Active Directory Certificate Services before small configuration changes become major PKI risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
