Key Points
- Weak or misconfigured AD CS certificate templates are the primary driver behind ESC1–ESC16 privilege-escalation paths. Hardening these templates is the single most effective way to reduce this attack surface.
- Effective Active Directory Certificate Services security begins with a solid architecture: a two-tier PKI with an offline root CA, dedicated administrative accounts, and granular audit logging.
- Organizations running AD CS alongside BYOD or cloud identity providers should evaluate cloud-native PKI to close the gaps AD CS was never designed to address.
Most organizations running Active Directory Certificate Services inherited their PKI configuration years ago. Templates were left at their defaults, enrollment permissions were never scoped, and audit logging was turned off — or never turned on. The result is an attack surface that tools like Certipy and Certify can enumerate in seconds.
The SpecterOps “Certified Pre-Owned” research identified 8 escalation techniques in 2021. By 2025, that number reached 16 (ESC1 through ESC16), all exploiting AD CS misconfigurations. This article covers the active directory certificate services best practices to address those risks. We’ll address ad cs security hardening and discuss ad cs certificate template security and operational monitoring.
What Is AD CS and Why Does It Need Hardening?
Active Directory Certificate Services, or AD CS, is the Windows Server role that turns your domain into a certificate authority (CA). It issues X.509 digital certificates for user authentication, device authentication, code signing, encryption, and more. AD CS relies on certificate templates: preconfigured policies that define what a certificate can do, who can request it, and how the subject name is built.
The problem: AD CS ships with 32 default templates, many of which have overly broad permissions. Several allow any authenticated user to enroll. Some permit the requester to specify the certificate’s subject name, which is the exact condition behind ESC1, the most exploited AD CS vulnerability.
Hardening AD CS means reducing that default attack surface by tightening template permissions, separating administrative roles, enabling audit trails, and removing components you do not need.
Active Directory Certificate Services Best Practices: Architecture
Before touching individual templates, get the foundation right. Here’s how.
Use a Two-Tier PKI Hierarchy
Deploy an offline root CA and one or more online issuing (subordinate) CAs. The root CA signs the issuing CA certificates, then stays powered off and disconnected from the network. This protects the root private key, which is the single most valuable cryptographic asset in your PKI.
If your root CA is currently domain-joined and online, plan a migration to take it offline. Renew the root CA certificate when half its validity period has elapsed, and document that renewal date as a recurring task.
Protect the Root CA Private Key with an HSM
If budget allows, store the root CA private key in a Hardware Security Module. An HSM keeps the key in tamper-resistant hardware and prevents extraction, even by administrators with physical access to the server.
Enforce Role Separation
AD CS defines four permission levels: Read, Manage CA, Issue and Manage Certificates, and Request Certificates. The best practice is to strip Domain Admins and Enterprise Admins of CA management rights during installation and then assign those rights to a dedicated CA Admins group.
Create a separate group for template management. No individual user account should hold CA permissions. Instead, use dedicated administrative accounts exclusively.
Remove the Web Enrollment Role Service
The AD CS Web Enrollment component (certsrv) uses NTLM authentication and is the direct attack vector for ESC8 relay attacks. If you do not have a documented business need for this component, do not install it. If it is already installed, remove it.
AD CS Certificate Template Security Best Practices
Templates are where most misconfigurations live. Audit every published template according to these best practices.
Never Use Default Templates in Production
Duplicate a relevant default template and configure the copy to your requirements. Default templates carry broad permissions that are difficult to track. Working from copies gives you a clean audit trail and the ability to version your changes.
Lock Down Enrollee-Supplied Subject Names
The CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is the root cause of ESC1. When enabled, the requester can specify any Subject Alternative Name (SAN), including a domain admin’s UPN. If a template also includes an authentication EKU (Client Authentication or Smart Card Logon), any enrolled user can impersonate any other user in the domain.
To remediate, disable “Supply in the request” on every template that includes an authentication EKU. If you need enrollee-supplied subjects for a specific workflow, require CA manager approval on that template.
Restrict Authentication EKUs
Templates configured with “Any Purpose” EKU or no EKU at all are vulnerable to ESC2. A certificate with an unrestricted EKU can be used for client authentication, server authentication, code signing, or just about anything.
Audit every published template. Each one should have the minimum set of EKUs required for its intended function. Remove Any Purpose, and do not leave the EKU field blank.
Scope Enrollment Permissions to Named Groups
Remove “Authenticated Users” and “Domain Computers” from enrollment and autoenrollment ACLs on sensitive templates. Replace them with named security groups that contain only the accounts that need that specific certificate type.
For high-sensitivity templates like Enrollment Agent and Key Recovery Agent, unpublish the template when it is not actively needed. Publish it only for the enrollment window, then unpublish again.
Disable Private Key Export
The “Mark private key as exportable” option should be disabled on every template unless you have a documented exception. An exportable private key means anyone with access to the certificate store can extract the key and use it on another machine, enabling certificate theft and lateral movement.
Shorten Validity Periods
Shorter certificate lifetimes reduce the window of exposure if a certificate is compromised. Align validity periods with your threat model: 1 year is a common baseline for user and computer certificates, with 90-day or shorter periods for high-privilege use cases.
Pair short lifetimes with automated renewal. AD CS supports autoenrollment for domain-joined devices, but scope it tightly — autoenrollment on broadly permissioned templates is one of the fastest ways to expand your attack surface.
Audit Logging and Monitoring for AD CS
Misconfigured templates create exploitable vulnerabilities. Missing audit logs allow attacks to go undetected. Here’s how to close those gaps.
Enable CA Audit Logging
Open the CA management console (certsrv.msc), navigate to CA Properties > Auditing, and enable all audit categories. Set the audit filter registry value to 127 to capture every auditable event.
Configure Windows Security Audit Policies
Use Group Policy to enable “Audit Certification Services” under Advanced Audit Policy Configuration > Object Access. This captures certificate request, issuance, and revocation events in the Windows Security event log.
Forward Logs to a SIEM
CA event logs which are stored only on the CA server are useless if the server is compromised. Forward ADCS audit logs and Windows Security logs to a SIEM or centralized log platform. Build detection rules for:
- Certificate requests with enrollee-supplied subject names
- Certificates issued from templates that were recently modified
- Failed enrollment attempts from unexpected accounts
- Changes to template ACLs or EKU configurations
Windows Server 2025 introduced enhanced ADCS audit logging with richer event data, making correlation and anomaly detection significantly easier. If you are still running Server 2019 or earlier, the upgrade is worth prioritizing for this capability alone.
AD CS Limitations That Best Practices Cannot Fix
Even a fully hardened AD CS deployment has structural constraints that template-level controls do not address.
No Native Support for Non-Windows Devices
AD CS certificate enrollment relies on Active Directory domain membership. macOS, Linux, iOS, Android, and Chromebook devices cannot natively enroll for certificates through AD CS without third-party tooling or workarounds like NDES.
BYOD Is an Afterthought
Self-service certificate provisioning for unmanaged devices does not exist in AD CS. IT teams end up building manual enrollment workflows or skipping certificate-based authentication for BYOD entirely, which creates a security gap.
No Real-Time Identity Validation at Authentication
AD CS issues certificates, but it does not participate in the authentication decision. A certificate remains valid until it expires or is manually revoked. There is no automatic revocation when a user is disabled in Entra ID or a device falls out of compliance in Intune.
On-Premises Infrastructure Overhead
Running AD CS means maintaining Windows Server instances, patching, HSM licensing, CRL distribution points, and OCSP responders. Each component adds operational cost and another potential point of failure.
When to Consider Cloud-Native PKI Over AD CS
AD CS best practices alone will not close the gap if any of the following applies to your environment:
- A mixed fleet of Windows, macOS, iOS, Android, or Chromebook devices
- BYOD users who need certificate-based Wi-Fi or VPN access
- A cloud identity provider (Entra ID, Okta, Google Workspace) as the primary directory
- A need for real-time access revocation tied to identity provider signals
- Distributed sites where maintaining on-prem CA infrastructure is impractical
When these conditions are present, extending AD CS with a cloud-native PKI is critical to maintain secure, scalable certificate operations.
Cloud-native PKI platforms handle certificate issuance, lifecycle management, and revocation from a managed service. They integrate directly with identity providers and MDMs like Intune, Jamf, Google Workspace, Kandji to automate enrollment for both managed and unmanaged devices. Authentication decisions happen in real time, with the RADIUS server checking user and device status against the identity provider on every connection.
SecureW2 JoinNow Dynamic PKI uses modern issuance protocols (ACME Device Attestation and Dynamic SCEP) that bind certificates to verified device identity, not just domain membership. JoinNow Cloud RADIUS performs real-time identity lookups against Entra ID, Okta, or Google Workspace at every 802.1X authentication event, so access is revoked the moment a user is disabled or a device falls out of compliance.
For organizations that need to maintain AD CS for legacy workloads, SecureW2 runs alongside it, issuing certificates for the devices and users AD CS cannot reach, without requiring you to rip and replace your existing PKI.
Strengthen AD CS Security or Move Beyond It with SecureW2
Hardening AD CS certificate templates is not optional — it is the single most effective control against privilege escalation in Microsoft environments. Start with architecture (offline root CA, role separation), lock down templates (disable enrollee-supplied subjects, restrict EKUs, scope enrollment ACLs), and build detection around certificate request activity.
For the gaps AD CS cannot close, like BYOD, non-Windows devices, real-time identity-driven revocation, schedule a demo with SecureW2 to see how cloud-native PKI and Cloud RADIUS extend certificate-based authentication to your entire environment.
Frequently Asked Questions
What are the most common AD CS vulnerabilities?
The most exploited AD CS vulnerabilities are ESC1 (enrollee-supplied subject names on authentication templates), ESC8 (NTLM relay against the Web Enrollment endpoint), and ESC4 (weak template ACLs that allow low-privilege users to modify template settings). All three stem from default or misconfigured certificate template settings. The SpecterOps "Certified Pre-Owned" research cataloged the original 8 techniques; the community has since identified 16 distinct escalation paths (ESC1 through ESC16).
How do I audit AD CS certificate templates for security issues?
Start by running `certutil -v -template` to export all published templates. Review each template for enrollee-supplied subject names enabled, overly broad enrollment permissions (Authenticated Users), authentication EKUs combined with the supply-in-request flag, and exportable private keys. Tools like Certipy (`certipy find`) and PSPKIAudit automate this process and flag vulnerable configurations.
Can AD CS issue certificates to non-Windows devices?
Not natively. AD CS certificate enrollment depends on Active Directory domain membership and Windows autoenrollment. Non-Windows devices (macOS, Linux, iOS, Android) require workarounds like the Network Device Enrollment Service (NDES) with SCEP, which adds infrastructure complexity and lacks the granular policy controls available to domain-joined Windows clients.
Should I migrate from AD CS to cloud PKI?
Migration makes sense when your environment has outgrown what AD CS was designed for — particularly if you support BYOD, use a cloud identity provider as your primary directory, or need real-time access revocation tied to device compliance. Many organizations run a hybrid model: AD CS for legacy Windows workloads and a cloud-native PKI for everything else.
What changed for AD CS in Windows Server 2025?
Windows Server 2025 introduced enhanced audit logging for ADCS, providing richer event data for certificate request and issuance tracking. These improvements make SIEM correlation and anomaly detection significantly more effective. Microsoft also published updated hardening guidance addressing several ESC techniques that were disclosed after Server 2019.
