ESC3 is an Active Directory Certificate Services exposure involving certificate templates that issue Certificate Request Agent certificates. These certificates allow an authorized person or service to submit certificate requests on behalf of another user. This capability has legitimate uses. Organizations may use enrollment agents for smart card deployments, identity registration workflows, Windows Hello for Business, or other processes where a trusted registration authority validates a user before requesting a certificate for them.
The risk appears when an enrollment agent certificate is available to users who should not have it, or when the Certification Authority does not restrict which identities and templates that agent may act on behalf of. A compromised or improperly issued enrollment agent certificate may allow someone to obtain an authentication certificate representing another user, including a privileged account.
ESC3 is primarily a problem of delegated certificate enrollment. The template issuing the enrollment agent certificate is one part of the exposure. The templates that accept on-behalf-of requests and the enrollment agent restrictions configured on the CA are equally important.
What Is a Certificate Request Agent?
A Certificate Request Agent, commonly called an enrollment agent, is a trusted identity authorized to request certificates for someone else.
The enrollment agent first obtains a certificate containing the Certificate Request Agent application policy. Its object identifier is: 1.3.6.1.4.1.311.20.2.1
The enrollment agent can then sign a certificate request submitted on behalf of another identity. The CA validates the agent’s certificate and signature before deciding whether to issue the requested certificate. Microsoft describes this process as enrollment on behalf of another user and documents the use of authorized signatures and the Certificate Request Agent application policy for these workflows.
A simplified legitimate workflow looks like this:
- A trusted registration authority verifies a user’s identity.
- The registration authority obtains or uses an enrollment agent certificate.
- It creates a certificate request for the user.
- The enrollment agent signs the request.
- The CA verifies the request and issues the certificate.
The problem is not that this capability exists. The problem is granting it too broadly or failing to restrict how it can be used.
Why ESC3 Matters
Certificates can function as credentials. When a certificate supports client authentication, smart card logon, or another authentication purpose, possession of its private key may allow authentication as the identity represented by the certificate. An enrollment agent certificate can therefore become a credential-issuing capability. Rather than authenticating directly as another user, the holder may be able to request a new certificate for that user.
The potential impact depends on the configuration. An exposed enrollment agent may be limited to a specific population and a tightly controlled certificate template. In a poorly restricted environment, the same certificate may be able to request authentication certificates for privileged users. This can create serious impersonation and privilege escalation paths without requiring the target user’s password.
How ESC3 Works Conceptually
A typical ESC3 path involves two certificate templates. The first template issues the enrollment agent certificate. It contains the Certificate Request Agent application policy and allows the requesting identity to enroll. The second template accepts requests signed by an enrollment agent. This template may issue authentication-capable certificates and requires an authorized signature using the Certificate Request Agent policy.
The sequence is:
- A user enrolls in a template that issues an enrollment agent certificate.
- The user uses that certificate to sign a request on behalf of another identity.
- The request targets a template that supports enrollment-on-behalf-of.
- The CA accepts the enrollment agent’s signature.
- A certificate is issued for the selected identity.
- That certificate may be usable for authentication.
The Two Templates Defenders Must Review
ESC3 cannot be evaluated by looking at only one template. You have to look at the enrollment agent template and on-behalf-of template.
Enrollment Agent Template
The first template issues the Certificate Request Agent certificate. It becomes dangerous when broad or low-privilege groups can enroll, manager approval is not required, authorized signatures are not required, and the template includes the Certificate Request Agent application policy. This template effectively determines who may become an enrollment agent.
On-Behalf-Of Template
The second template determines what the enrollment agent can request and what the resulting certificate can do. A common legitimate configuration requires one authorized signature using the Certificate Request Agent application policy. The resulting certificate may contain Smart Card Logon, Client Authentication, or another application policy required by the business process. Microsoft uses this general design in documented certificate trust deployments. This template determines which certificates an enrollment agent may obtain for other identities.
When Does ESC3 Become Dangerous?
The most concerning configuration is an enrollment agent template available to a broad group, combined with an on-behalf-of template that issues authentication-capable certificates for sensitive identities.
Defenders should evaluate several questions together:
- Who can enroll in the enrollment agent template?
- Does the template require manager approval?
- Does it require an authorized signature?
- Which users or computers may the agent act on behalf of?
- Which certificate templates may the agent use?
- Does the resulting certificate support authentication?
- Are enrollment agent restrictions configured on the CA?
- Is certificate issuance monitored?
An enrollment agent certificate is not automatically a vulnerability. It becomes dangerous when its authority exceeds the operational need.
Enrollment Agent Restrictions
Enterprise Certification Authorities can restrict enrollment agents. These restrictions can limit which enrollment agents may request certificates, which templates they may use, and which users or groups they may act on behalf of. Without appropriate restrictions, an enrollment agent may have broader authority than administrators intended.
Microsoft Defender for Identity specifically recommends using enrollment agent restrictions at the CA level to limit which users can act as enrollment agents and what they can request.
Restrictions are particularly important when enrollment agent certificates support automated services. A service may need to enroll certificates only for a defined user group and only through a specific template. It rarely needs unrestricted authority across the domain.
ESC3 Compared with ESC1 and ESC2
ESC1, ESC2, and ESC3 all involve certificate templates, but they represent different security problems.
| Risk | Primary Issue |
|---|---|
| ESC1 | A requester can influence the identity placed in an authentication-capable certificate |
| ESC2 | A template issues certificates with Any Purpose or unrestricted usage |
| ESC3 | An enrollment agent certificate can be used to request certificates on behalf of other identities |
ESC1 focuses on requester-controlled identity information. ESC2 focuses on overly broad certificate purposes. ESC3 focuses on delegated enrollment authority. The risks may overlap. For example, a broadly available Any Purpose certificate may sometimes be useful in enrollment-agent scenarios, while an ESC3 path may ultimately request a certificate from another risky template.
What Defenders Should Review
Begin with an inventory of every published certificate template and identify templates containing the Certificate Request Agent application policy. Then identify templates configured to require authorized signatures. These are potential on-behalf-of templates and should be reviewed alongside the enrollment agent templates that can satisfy their issuance requirements.
The review should determine:
- Which templates issue enrollment agent certificates
- Which identities have Enroll or Autoenroll permissions
- Whether manager approval is required
- Whether the template itself requires authorized signatures
- Which templates accept Certificate Request Agent signatures
- Whether issued certificates support authentication
- Whether enrollment agent restrictions exist on each issuing CA
- Whether the workflow is still actively used
Every enrollment agent workflow should have a documented owner, business purpose, approved population, and review date.
PowerShell: Find Enterprise Certification Authorities
The following query identifies enterprise CAs and the templates they publish:
$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, certificateTemplatesUse the results to determine which CAs publish enrollment agent or on-behalf-of templates.
PowerShell: Inventory Certificate Template Application Policies
Certificate templates are stored in the Configuration naming context. The following query retrieves the template name and encoded application policy values:
$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$TemplateBase = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC"
Get-ADObject `
-SearchBase $TemplateBase `
-LDAPFilter "(objectClass=pKICertificateTemplate)" `
-Properties displayName, pKIExtendedKeyUsage |
Select-Object displayName, pKIExtendedKeyUsageLook for the Certificate Request Agent object identifier 1.3.6.1.4.1.311.20.2.1. This query provides an initial inventory. It does not determine whether the template is fully vulnerable because permissions, issuance requirements, publication status, and CA restrictions must also be reviewed.
PowerShell: Find Templates with the Certificate Request Agent Policy
The following example filters templates that explicitly contain the Certificate Request Agent object identifier:
$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$TemplateBase = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigNC"
$RequestAgentOID = "1.3.6.1.4.1.311.20.2.1"
Get-ADObject `
-SearchBase $TemplateBase `
-LDAPFilter "(objectClass=pKICertificateTemplate)" `
-Properties displayName, pKIExtendedKeyUsage |
Where-Object {
$_.pKIExtendedKeyUsage -contains $RequestAgentOID
} |
Select-Object Name, displayName, pKIExtendedKeyUsageReview every matching template, even if it is not currently published. An unpublished template may still become relevant if someone with sufficient permissions can publish it later.
PowerShell: Review Published Templates on a CA
On a CA with the AD CS administration tools installed:
Get-CATemplateCompare the published templates with the Active Directory inventory. A template is only directly usable through a CA when that CA publishes it, but dormant templates should still be reviewed for permissions and future exposure.
Graphical: Review Enrollment Agent Templates
Open the Certificate Templates console by running:
certtmpl.mscFor each suspected enrollment agent template, review the following tabs:
General
Confirm the template name, validity period, renewal period, and whether the template is still required.
Extensions
Open Application Policies and look for Certificate Request Agent.
Security
Identify every user, group, computer, or service account with Enroll or Autoenroll permission.
Issuance Requirements
Determine whether CA certificate manager approval or authorized signatures are required.
Subject Name
Confirm how the subject is constructed and whether the requester can supply identity information.
An enrollment agent template should never be available to broad groups without a carefully documented reason.
Graphical: Review On-Behalf-Of Templates
For templates designed to accept enrollment agent requests, review the Issuance Requirements tab.
Look for:
- This number of authorized signatures: 1 or greater
- Policy type required in signature: Application policy
- Application policy: Certificate Request Agent
Also review the Extensions tab to determine whether the resulting certificate supports Client Authentication, Smart Card Logon, or another authentication purpose. Authorized signatures are a legitimate control when they ensure a trusted enrollment agent approves the request. The control becomes risky when enrollment agent certificates themselves are too easy to obtain.
Graphical: Review Enrollment Agent Restrictions
Open the Certification Authority console:
certsrv.mscOpen the CA properties and review the Enrollment Agents tab, where supported by the CA configuration and operating system version.
Determine whether restrictions specify:
- Which enrollment agents are authorized
- Which certificate templates they may use
- Which users or groups they may enroll on behalf of
A configuration that allows all enrollment agents to enroll for all users through all templates should receive careful scrutiny.
How to Reduce ESC3 Exposure
The most effective approach is to reduce enrollment agent authority to the smallest scope required by the business process. Remove enrollment agent templates that are no longer needed. For required templates, limit Enroll permissions to dedicated registration authority accounts or tightly controlled service identities. Avoid granting enrollment rights to Domain Users, Authenticated Users, or broad operational groups. Configure enrollment agent restrictions on each issuing CA. Limit agents to specific on-behalf-of templates and approved user groups. Where the workflow supports it, require certificate manager approval or additional authorized signatures.
Protect the private keys associated with enrollment agent certificates. If a service performs enrollment on behalf of users, run it under a dedicated identity, harden the host, restrict interactive sign-in, and consider hardware-backed private key protection. The on-behalf-of template should also be narrowly scoped. It should issue only the EKUs required for the workflow and should not provide broader authentication capabilities than necessary.
Safe Remediation Workflow
Enrollment agents often support business-critical identity processes, so remediation should begin with discovery rather than immediate removal.
- Identify all enrollment agent templates.
- Identify every user and service permitted to enroll.
- Find templates that accept enrollment agent signatures.
- Document the application or business process using each template.
- Review CA-level enrollment agent restrictions.
- Determine which users and templates each agent genuinely requires.
- Test tighter permissions and restrictions in a controlled environment.
- Reissue enrollment agent certificates where necessary.
- Revoke certificates that should no longer be trusted.
- Monitor enrollment failures and authentication issues after changes.
Removing or restricting an enrollment agent without understanding its dependencies may disrupt smart card issuance, certificate-based sign-in, automated provisioning, or device enrollment.
Detection Opportunities
ESC3 detection should focus on enrollment agent certificate issuance, on-behalf-of requests, template changes, and unexpected certificate use. High-value monitoring opportunities include certificate requests involving enrollment agent templates, authentication certificates issued for privileged identities, requests submitted by unusual registration authority accounts, and sudden changes in the volume of on-behalf-of enrollment. Review CA auditing and certificate request records for the requester, requested subject, template, disposition, and issuance time. Compare this information with approved enrollment workflows.
Also monitor changes to:
- Template application policies
- Template enrollment permissions
- Authorized signature requirements
- Enrollment agent restrictions
- Published templates
- CA officer and manager permissions
Changes to these settings should be rare and tied to approved PKI administration activity.
Common Mistakes
Reviewing only the enrollment agent template
The on-behalf-of template determines what certificate can ultimately be issued. Both sides of the workflow must be reviewed.
Assuming authorized signatures eliminate risk
Authorized signatures help only when the enrollment agent certificate is issued and protected correctly. A broadly available agent certificate undermines the control.
Failing to configure CA-level restrictions
Template permissions may limit who can obtain an enrollment agent certificate, but CA restrictions define how broadly that certificate may be used.
Treating enrollment agents like ordinary user certificates
An enrollment agent certificate can authorize certificate issuance for other identities. It should be protected more like a privileged credential.
Leaving legacy enrollment workflows in place
Smart card or registration workflows may remain configured long after they stop being used. Old templates, service accounts, and certificates should be removed after validation.
Practical Recommendation
Treat enrollment agent certificates as privileged credentials.
Every environment using enrollment-on-behalf-of should be able to answer four questions:
- Who is authorized to act as an enrollment agent?
- Which templates may each agent request?
- Which users or groups may each agent represent?
- Where and how is the enrollment agent private key protected?
If any answer is unclear, the enrollment agent design needs further review.
At a minimum, restrict enrollment permissions, configure CA-level enrollment agent restrictions, protect agent private keys, remove unused templates, and monitor all on-behalf-of issuance involving privileged identities.
Summary
ESC3 is an Active Directory Certificate Services exposure involving Certificate Request Agent templates and enrollment-on-behalf-of workflows. An enrollment agent certificate allows a trusted person or service to sign certificate requests for another identity. This is a legitimate and sometimes necessary capability, but it becomes dangerous when too many users can obtain agent certificates or when the CA does not restrict what those agents may request. Defenders must review both parts of the workflow: the template that issues the enrollment agent certificate and the template that issues certificates on behalf of other users. CA-level enrollment agent restrictions, template permissions, authorized signature requirements, authentication EKUs, and private key protection all affect the real level of risk. A secure deployment limits each enrollment agent to a defined business process, specific certificate templates, and an approved user population. Enrollment agent certificates should be treated as privileged credentials and monitored accordingly.
References
- Microsoft Learn: Active Directory Certificate Services Overview
- Microsoft Learn: Certificate Template Concepts
- Microsoft Learn: Manage Certificate Templates
- Microsoft Learn: Certificate Security Posture Assessments
- Microsoft Open Specifications: Enroll on Behalf of Request and Renewal
- SpecterOps: Certified Pre-Owned, Abusing Active Directory Certificate Services