ESC1 in Active Directory Certificate Services

ESC1 is an Active Directory Certificate Services misconfiguration involving certificate templates. ESC1 exists when a user or computer can request an authentication-capable certificate while supplying identity information that should not be under their control.

This matters because certificates can act like credentials. If a certificate can be used for authentication, and a requester can influence the identity placed into that certificate, the requester may be able to obtain a certificate that authenticates as another user or computer. ESC1 is one of the most important AD CS risks to understand because it combines several common template settings into a dangerous outcome.

What is ESC1?

ESC1 is a common name for an AD CS escalation path where a certificate template allows unsafe certificate enrollment.

A typical ESC1-style condition includes:

The certificate template is published to an issuing CA.
The certificate can be used for authentication.
Low-privilege users or computers can enroll.
The requester can supply subject or Subject Alternative Name values.
No strong approval or authorization requirement prevents abuse.

Not every environment labels this as ESC1, and ESC names are not Microsoft product features. They are commonly used by the security community to describe AD CS escalation paths.

For defenders, the label is less important than the condition: Can an account request a certificate that authenticates as someone or something else? If the answer is yes, the template should be treated as high risk.

Why ESC1 matters

ESC1 matters because it can turn certificate enrollment into identity impersonation. In a risky configuration, a requester may be able to obtain a certificate that contains identity information for another account. If that certificate is trusted for authentication, the requester may be able to authenticate as that account. The impact depends on which identity can be represented in the certificate and how certificate-based authentication is configured.

Potential impact may include:

User impersonation
Computer account impersonation
Privileged account compromise
Persistent access through long-lived certificates
Bypass of password resets
Access to services that trust certificate authentication
Domain escalation if privileged identities can be targeted

This is why ESC1 is often treated as one of the highest-priority AD CS template risks.

How certificate templates create ESC1 risk

Certificate templates define how certificates are issued. Microsoft notes that certificate templates simplify CA administration by allowing administrators to issue certificates preconfigured for selected tasks.

From a security perspective, several template settings matter most:

Extended Key Usage
Enrollment permissions
Subject name settings
Subject Alternative Name handling
Issuance requirements
Approval requirements
Template ACLs
Private key settings
Validity period

ESC1 risk usually appears when these settings combine in a dangerous way. A single setting may not be enough by itself. For example, a template that allows client authentication may be legitimate. A template that allows broad enrollment may also be legitimate. The risk becomes serious when broad enrollment, authentication capability, and requester-controlled identity fields exist together.

Authentication-capable certificates

The first important condition is whether the certificate can be used for authentication.

Templates deserve closer review when they include purposes such as:

Client Authentication
Smart Card Logon
PKINIT Client Authentication
Any Purpose
No EKU restriction in some scenarios

These purposes may allow a certificate to authenticate as a user, computer, or service.

Requester-supplied subject and SAN values

The second important condition is whether the requester can supply identity information.

Certificate identity information may appear in fields such as:

Subject
Subject Alternative Name
User Principal Name
DNS name
Email name
Other name values

A safer design usually builds subject information from Active Directory. A riskier design allows the requester to supply subject or SAN values in the request. Requester-supplied identity fields can be legitimate for some web server or application certificate workflows. For example, a web server certificate may need a specific DNS name. The risk increases when requester-supplied identity fields are allowed on a template that can also be used for authentication.

Enrollment permissions

The third important condition is who can request the certificate. Enrollment permissions determine which users, groups, computers, or service accounts can enroll in a template. Broad enrollment becomes dangerous when paired with authentication capability and requester-supplied identity information.

Groups to review carefully include:

Domain Users
Authenticated Users
Domain Computers
Everyone
Large application groups
Help desk groups
Non-PKI administrator groups
Service accounts

Broad enrollment on a low-impact template may be fine. Broad enrollment on an authentication-capable template with requester-supplied identity fields is usually high risk.

Published templates

A certificate template must generally be published to an issuing CA before users can request certificates from it.

That distinction matters.

Template state	Risk meaning
Published to an issuing CA	The template may be available for enrollment
Not published	The template exists, but may not be actively enrollable
Published to multiple CAs	The exposure may be broader
Old but still published	The template may remain usable even if the original business need is gone

A risky template that is published should be prioritized over a risky template that is not currently available for enrollment. However, unpublished templates should not be ignored. They may still have weak ACLs, may be published later, or may be copied into new templates.

Common ESC1 pattern

A common ESC1 pattern looks like this:

Condition	Why it matters
Template is published	Users or computers may be able to request certificates
Client Authentication is allowed	The certificate may be usable for authentication
Low-privilege users can enroll	The template is broadly reachable
Requester can supply SAN	The requester may influence the identity in the certificate
No approval required	The certificate may be issued automatically
Long validity period	The certificate may remain useful for a long time

The strongest risk usually comes from the full combination.

Why approval requirements matter

Approval requirements can reduce ESC1 risk if they are properly configured and operated.

Examples include:

Manager approval
Authorized signatures
Enrollment agent requirements

Approval is not a perfect control. It depends on who can approve requests, whether approvers understand the risk, and whether request details are reviewed carefully. However, approval requirements can prevent automatic issuance of sensitive certificates. For high-impact authentication templates, defenders should review whether approval is required and whether the approval process is meaningful.

Why template ACLs still matter

Even if a template is not currently vulnerable to ESC1, weak template permissions can allow someone to make it vulnerable later.

High-risk rights include:

GenericAll
GenericWrite
WriteDacl
WriteOwner
WriteProperty
Full Control

A principal with write access to a certificate template may be able to change settings such as EKUs, subject name behavior, enrollment permissions, or issuance requirements. Template ACL review should be part of every ESC1 review.

ESC1 vs other AD CS risks

ESC1 is focused on unsafe certificate template enrollment behavior.

It is different from other AD CS risks such as:

Risk area	Main idea
ESC1	Dangerous template allows requester-controlled identity and authentication-capable certificate enrollment
NTLM relay to AD CS	Authentication is relayed to an enrollment endpoint to request a certificate
Weak CA permissions	Non-PKI administrators can manage or abuse the CA
Weak template ACLs	Users can modify templates into unsafe states
Enrollment agent abuse	A certificate request agent can request certificates on behalf of others
Weak certificate mapping	Certificates may map to identities in unsafe ways

These risks can overlap. For example, AD CS web enrollment exposure can combine with risky templates and NTLM relay paths. Microsoft specifically recommends protections such as Extended Protection for Authentication or signing features to help protect services that permit NTLM authentication, and its AD CS relay mitigation guidance includes disabling NTLM on AD CS IIS endpoints where possible.

How to find ESC1 exposure

An ESC1 review should answer five questions:

Is the template published to an issuing CA?
Can the certificate be used for authentication?
Who can enroll?
Can the requester supply subject or SAN values?
Is approval or another strong issuance control required?

If the template is published, authentication-capable, broadly enrollable, requester-controlled, and automatically issued, it should be treated as high risk.

PowerShell: Find published certificate templates

Published templates are associated with enterprise CAs.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKIEnrollmentService)" `
  -Properties dNSHostName, certificateTemplates |
  Select-Object Name, dNSHostName, certificateTemplates

Focus first on templates published to active issuing CAs.

PowerShell: Find templates with Client Authentication EKU

Client Authentication is one of the most important EKUs to review.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$ClientAuthEku = "1.3.6.1.5.5.7.3.2"

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, pKIExtendedKeyUsage |
  Where-Object { $_.pKIExtendedKeyUsage -contains $ClientAuthEku } |
  Select-Object Name, displayName, pKIExtendedKeyUsage

This is not automatically a list of ESC1 templates. It is a starting list of authentication-capable templates to review.

PowerShell: Review subject name flags

Subject name flags can help identify templates where the requester may be able to supply subject information.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, msPKI-Certificate-Name-Flag |
  Select-Object Name, displayName, msPKI-Certificate-Name-Flag

These values require interpretation. Treat this as a review aid, not a complete risk determination.

PowerShell: Review enrollment flags

Enrollment flags can help identify whether approval, autoenrollment, or other issuance behavior may be configured.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, msPKI-Enrollment-Flag |
  Select-Object Name, displayName, msPKI-Enrollment-Flag

Use this with GUI review or deeper parsing before making a final decision.

PowerShell: Review template permissions

Template permissions are important because weak ACLs can create or worsen ESC1 exposure.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$TemplateName = "TemplateName"
$TemplateDn = "CN=$TemplateName,CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC"

Get-Acl "AD:\$TemplateDn" |
  Select-Object -ExpandProperty Access |
  Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, IsInherited

Review unexpected permissions carefully, especially write, owner, and permission-modification rights.

PowerShell: Export templates for review

This export can help create a working review file.

$ConfigNC = (Get-ADRootDSE).configurationNamingContext

Get-ADObject `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC" `
  -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName, pKIExtendedKeyUsage, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag |
  Select-Object Name, displayName, pKIExtendedKeyUsage, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag |
  Export-Csv .\certificate-template-review.csv -NoTypeInformation

This does not replace proper template analysis, but it gives teams a starting point.

GUI: Review certificate templates

Open the Certificate Templates console (certtmpl.msc).

Review high-impact templates for:

Published status
Application policies
Client Authentication
Smart Card Logon
Any Purpose
Subject name settings
Enrollment permissions
Autoenrollment permissions
Issuance requirements
Private key export
Validity period
Template security permissions

Start with authentication-capable templates.

GUI: Review published templates on the CA

Open the Certification Authority console (certsrv.msc)

Then review:

Certification Authority
  CA Name
    Certificate Templates

This shows templates currently published on the CA. A risky template that is published should usually be prioritized over one that is not actively available.

How to remediate ESC1

ESC1 remediation usually involves changing the dangerous combination of template settings.

Common remediation options include:

Remove the template from issuing CAs if it is not needed.
Restrict enrollment permissions.
Remove broad groups from Enroll or Autoenroll.
Disable requester-supplied subject or SAN values where possible.
Remove authentication EKUs if authentication is not required.
Require manager approval or authorized signatures for sensitive templates.
Shorten certificate validity periods where appropriate.
Remove private key export if not required.
Correct weak template ACLs.
Replace risky templates with safer purpose-built templates.
Monitor certificate requests after remediation.

Do not change production templates blindly. Confirm dependencies first.

Safe remediation workflow

A safer workflow looks like this:

Confirm the template is published.
Confirm whether issued certificates are actively used.
Identify certificate owners and dependent systems.
Determine whether authentication is required.
Review who currently has enrollment rights.
Create a safer replacement template if needed.
Test the replacement template.
Move users or systems to the replacement.
Remove or restrict the risky template.
Monitor for failed enrollments or authentication issues.
Review existing issued certificates and revoke if appropriate.

Certificate template changes can affect VPN, Wi-Fi, smart cards, applications, device authentication, and internal services. Test carefully.

Detection opportunities

ESC1 detection should include both configuration monitoring and certificate issuance monitoring.

Monitor for:

New certificate templates
Certificate template modifications
Template permission changes
Templates published to CAs
Changes to subject name settings
Changes to EKUs or application policies
Changes to enrollment permissions
Certificate requests from authentication-capable templates
Certificate requests involving privileged users
Certificate requests with unusual subject or SAN values
Certificate issuance from unexpected users or systems

Certificate templates should not change frequently. Treat unexpected changes as suspicious until validated.

Common mistakes

Only checking the template name

Template names can be misleading. Review the actual settings, permissions, and published status.

Treating Client Authentication as automatically bad

Client Authentication is common and often required. The risk depends on enrollment permissions, subject control, approval, and usage.

Ignoring published status

A risky template that is published to a CA is more urgent than a risky template that is not currently available for enrollment.

Forgetting about Autoenroll

Autoenrollment can increase exposure if certificates are issued broadly without direct user action.

Ignoring template ACLs

Weak template ACLs can allow a template to become vulnerable later, even if it is currently safe.

Removing templates without checking dependencies

Templates may support Wi-Fi, VPN, smart cards, domain controllers, applications, or device identity. Validate before changing.

Assuming certificate revocation solves everything

Revocation is important, but it depends on relying systems checking revocation properly. Fix the template configuration as well.

Practical recommendation

A practical ESC1 review should include:

Inventory published templates.
Identify authentication-capable templates.
Review templates that allow requester-supplied subject or SAN values.
Review enrollment and autoenrollment permissions.
Identify broad enrollment on authentication-capable templates.
Review issuance approval requirements.
Review template ACLs.
Prioritize templates that are published, authentication-capable, broadly enrollable, and requester-controlled.
Validate business dependencies.
Restrict or replace risky templates.
Monitor template changes and certificate issuance.

Start with published templates that support authentication. Those are usually the most important.

Summary

ESC1 is an AD CS certificate template risk where a requester may be able to obtain an authentication-capable certificate while controlling identity information in the request. The danger comes from a combination of settings: authentication-capable EKUs, broad enrollment permissions, requester-supplied subject or SAN values, weak approval requirements, and published templates.

Defenders should focus on identifying published authentication-capable templates, reviewing who can enroll, checking whether requesters can supply identity information, and correcting risky template permissions. ESC1 is important because certificates can act like credentials, and a misissued certificate can create impersonation, persistence, or privilege escalation paths.