Your Guide To Understanding Active Directory Certificate Services

Introduction

Active Directory Certificate Services (AD CS) is the Windows Server role most enterprises reach for first when they need an on-premises Certificate Authority, and it is also one of the most commonly misconfigured pieces of enterprise identity infrastructure in active use today. This guide covers what AD CS actually does, its six role services, where it genuinely helps an organization, and where its real risks lie, including the documented certificate-based privilege escalation paths that security researchers have been tracking since 2021.

The applications AD CS supports include secure wireless networking, Virtual Private Networks (VPN), Internet Protocol Security (IPSec), Network Access Protection (NAP), Encrypting File Systems (EFS), and smart card logon, among others.

In Short: What Is AD CS?

Active Directory Certificate Services (AD CS) is a Windows Server role, first shipped in Windows Server 2008 and still supported in Server 2022 and Server 2025, that lets an organization run its own Certificate Authority to issue, manage, and revoke Public Key Infrastructure (PKI) certificates for encryption, authentication, and digital signatures without relying on a third-party CA for internal use cases.

Executive Summary

• AD CS bundles six distinct role services, from the Certificate Authority itself to web-based enrollment for devices outside the domain.
• Its main advantage over a third-party CA is cost and control: no per-certificate fees, and full ownership of the CA hierarchy and policy.
• Its main risk is not a code-level vulnerability but misconfiguration. SpecterOps’ 2021 “Certified Pre-Owned” research catalogued a family of privilege escalation paths, now widely referred to as ESC1 through ESC8 and beyond, that let a low-privileged user obtain a certificate that impersonates a Domain Admin.
• CVE-2022-26923 (“Certifried”) showed exactly how severe this class of risk can get, and Microsoft’s phased strong certificate mapping rollout under KB5014754 reached full enforcement in February 2025.
• Windows Server 2025 added support for issuing post-quantum ML-DSA certificates from an AD CS Certificate Authority, making crypto-agility planning relevant to AD CS deployments specifically, not just cloud PKI.

Why This Still Matters

DigiCert’s Trust Pulse Survey, published July 2, 2025, found that nearly half of enterprises experienced a certificate related outage in the past year, with 37.5% of incidents tied specifically to expired certificates and 18.5% of affected organizations reporting losses exceeding $250,000. An AD CS environment left unmonitored, whether because the team that built it has moved on or because certificate templates were never audited after initial deployment, is exactly the kind of environment where that risk accumulates quietly.

The certificate lifespan problem is compounding this. Under CA/Browser Forum Ballot SC-081v3, approved April 11, 2025, publicly trusted TLS certificate validity drops from 398 days to 200 days starting March 15, 2026, then to 100 days from March 15, 2027, and to 47 days from March 15, 2029 onward. That schedule applies to publicly trusted certificates rather than an internal AD CS hierarchy directly, but it sets the operational bar every certificate authority, internal or external, is now measured against.

Longer term, NIST finalized its post quantum cryptography standards, FIPS 203, 204, and 205, on August 13, 2024, and Microsoft has already responded at the platform level: Windows Server 2025’s AD CS role now supports issuing ML-DSA certificates directly from a Certificate Authority. Any organization still running AD CS on Server 2019 or earlier should treat that gap as a planning input, not just a routine upgrade decision.

The Six Role Services That Make Up AD CS

AD CS is not a single service but a set of six role services that can be installed individually depending on what an organization needs.

Role Service	What It Does
Certificate Authority (CA)	Issues and manages public-key certificates. Can be deployed as an Enterprise CA (domain-joined, integrated with Active Directory) or a Standalone CA (offline, not domain-joined, typically used as an air-gapped Root CA).
Certification Authority Web Enrollment	Lets clients outside the domain request and download certificates through a browser, including cross-forest requests where forest trust has been established.
Online Responder	Runs the Online Certificate Status Protocol (OCSP), answering real-time queries about whether a specific certificate is still valid, as an alternative or supplement to publishing a full Certificate Revocation List (CRL).
Network Device Enrollment Service (NDES)	Issues certificates to non-domain-joined network devices such as routers, firewalls, and switches using the Simple Certificate Enrollment Protocol (SCEP), and is also the typical bridge used for MDM-managed mobile and macOS device enrollment.
Certificate Enrollment Web Service	Allows domain and non-domain devices to enroll and renew certificates over HTTPS, primarily to support automated client requests rather than manual browser-based enrollment.
Certificate Enrollment Policy Web Service	Publishes enrollment policy, including which CAs are available and which certificate templates a client is permitted to request, to clients outside the traditional domain enrollment path.

A Certificate Authority can be configured as either an Enterprise CA or a Standalone CA. An Enterprise CA must be a domain member and can issue certificates for digital signatures, browser authentication, and secure email. A Standalone CA does not require Active Directory Domain Services and can run entirely offline, which is the recommended configuration for a Root CA that should never be connected to a live network.

What AD CS Gets Right

AD CS lets an organization bind the identity of a person, device, or service to a corresponding private key without paying per-certificate fees to a third-party CA. That gives enterprises a cost-effective way to manage the distribution and use of certificates at scale, once the initial deployment and staffing investment is made.

Concretely, AD CS provides the PKI an organization needs to secure web servers with SSL/TLS, enforce certificate-based authentication, apply digital signatures to documents, and encrypt email through S/MIME, all under policies the organization controls directly rather than a provider’s terms of service.

Where Active Directory Certificate Services Falls Short

Operational and Cost Challenges

Deploying and running a Microsoft CA well is not a side project. It requires a dedicated team with real PKI experience to get the initial hierarchy right, and that team has to stay current on best practices afterward to keep the CA reliable. The overhead of hardware, deployment, and ongoing expert staffing makes AD CS more expensive in practice than its “free with Windows Server” license cost suggests.

Known Security Misconfiguration Risks (ESC1 Through ESC8 and Beyond)

The most serious AD CS risk documented in recent years is not a code vulnerability in AD CS itself but misconfiguration of certificate templates and CA permissions. SpecterOps’ 2021 “Certified Pre-Owned” research defined a family of escalation paths, now commonly labeled ESC1 through ESC8, and expanded further by later community research, where a low-privileged domain user can request or obtain a certificate that lets them authenticate as a far more privileged account, in the worst case a Domain Admin.

CVE-2022-26923, publicly known as “Certifried,” is the clearest real-world illustration of this risk class: a standard user’s default right to join machines to the domain could be combined with a certificate request to impersonate a Domain Controller and compromise the entire domain. Microsoft’s response, delivered through KB5014754, introduced strong certificate mapping and rolled it out in phases, reaching full enforcement in February 2025. Any AD CS environment that has not reviewed its certificate templates and CA permissions against the ESC categories since 2021, or confirmed it is compliant with the KB5014754 enforcement timeline, should treat that as an overdue audit rather than optional hardening.

macOS and Non-Domain Device Enrollment

AD CS Web Enrollment is not natively consumed by macOS. Apple devices typically enroll through an MDM profile using the ADCertificate payload or SCEP, usually fronted by NDES rather than the browser-based enrollment path domain-joined Windows clients use. Organizations with a significant macOS or mixed-device fleet should plan for this MDM-and-SCEP-based path from the outset rather than treating it as an edge case discovered after rollout.

Decision Matrix: When AD CS Fits, and When It Does Not

Use Case	Security Impact	Operational Effort	Automation Fit	Recommended Owner
Internal Windows domain authentication and smart card logon	Medium, contingent on template hygiene	Medium, once deployed correctly	Medium, native AD integration handles most renewal	PKI Administrators
Air-gapped, offline Root CA for a high-assurance internal hierarchy	High, this is the root of trust for the domain	High, manual ceremonies and physical security required	Low by design	Security Architects, PKI Administrators
Certificate issuance to non-domain network devices (routers, firewalls, IoT)	Medium to high, depends on NDES exposure	Medium, NDES setup and SCEP configuration	Medium, SCEP automates renewal once configured	Platform Teams
Auditing existing certificate templates and CA permissions for ESC1 through ESC8 exposure	High, this is a direct privilege escalation path	Medium, tooling exists but requires expertise to interpret	Medium, tools like Certipy and PSPKIAudit can be scheduled	Security Architects, Compliance
Mixed Windows, macOS, and mobile device certificate enrollment at scale	Medium, depends on MDM integration quality	High if not planned for AD CS alone	High with MDM plus NDES/SCEP, low if attempted through Web Enrollment alone	Platform Teams, PKI Administrators

Who Should Care About This

AD CS decisions rarely stay contained to a single team. Here is what each stakeholder should take away.

PKI Administrators

Run the CA day to day and own certificate template configuration. Action item: audit every certificate template against the ESC1 through ESC8 categories and confirm KB5014754 strong certificate mapping enforcement is active, not just installed.

Security Architects

Own the CA hierarchy design and its blast radius if compromised. Action item: confirm the Root CA is genuinely offline and standalone, and document which role services are actually needed versus installed by default.

Platform Teams

Own device enrollment paths, including NDES, SCEP, and MDM integration for non-Windows devices. Action item: confirm macOS and mobile enrollment is routed through MDM and NDES rather than an ad hoc workaround.

Compliance Teams

Own confirming that certificate template and CA permission audits actually happen on a schedule, not just after an incident. Action item: request the date of the last ESC1 through ESC8 review and the current KB5014754 enforcement status as standing audit evidence.

CISOs

Own the decision to keep AD CS in-house, layer on additional posture management, or shift certificate lifecycle work to a managed platform. Action item: weigh the ongoing cost of expert internal staffing against the risk of an unaudited CA sitting quietly inside the domain.

Our Take: How Encryption Consulting Supports AD CS Environments

Active Directory Certificate Services is used to establish an on-premises Public Key Infrastructure, capable of creating, validating, and revoking public key certificates for encrypting files, emails, and network traffic. Getting real value from it long term depends less on the initial installation and more on ongoing template hygiene, permission audits, and certificate lifecycle discipline.

Our CertSecure Manager platform automates certificate discovery, deployment, renewal, and revocation across an AD CS environment, closing exactly the kind of unaudited-template gap the ESC misconfiguration research exposed. For a deeper, AD CS-specific look at moving beyond native tooling toward unified cryptographic posture management, see our related guide on modernizing ADCS. Organizations that would rather offload CA operations entirely can evaluate our PKI-as-a-Service platform, which runs the CA hierarchy on FIPS 140-3 Level 3 HSM-backed keys while your organization retains ownership and control. On the post-quantum front, our PQC Center of Excellence and PQC Readiness Assessment help teams plan the move toward ML-DSA and other post-quantum algorithms ahead of a forced migration, and our CBOM Secure cryptographic discovery and inventory platform gives security architects full visibility into which algorithms and key sizes an existing AD CS hierarchy is actually issuing today.

Conclusion

AD CS remains a capable, cost-effective way to run an on-premises Certificate Authority, and it is not going away: it is still fully supported in Windows Server 2022 and 2025, and Server 2025 now issues post-quantum ML-DSA certificates directly. What has changed since this role first shipped is the maturity of attacker tradecraft against it. The ESC1 through ESC8 misconfiguration categories and the Certifried vulnerability turned “we already have AD CS running” into a question that deserves a template-by-template audit, not an assumption that default settings are safe. Organizations that treat AD CS as a one-time deployment rather than an ongoing security surface are the ones most likely to discover the gap the hard way.

Frequently Asked Questions

What is the main takeaway from this guide to Active Directory Certificate Services?

AD CS is a capable, cost-effective on-premises Certificate Authority role, but its biggest real-world risk is certificate template and CA permission misconfiguration, documented as the ESC1 through ESC8 privilege escalation categories, rather than a flaw in the software itself.

Why does this matter for enterprise PKI teams?

Enterprise PKI teams often deploy AD CS once and rarely revisit its configuration afterward, which is exactly the pattern that lets ESC-category misconfigurations and stale certificate templates accumulate undetected for years.

What risks increase if AD CS templates and permissions are never audited?

Unaudited templates and permissions raise the risk of a low-privileged user escalating to Domain Admin through an ESC-category misconfiguration, as demonstrated by CVE-2022-26923, and increase the odds that KB5014754 strong certificate mapping enforcement is not actually active.

Which teams should own AD CS security reviews?

PKI administrators own day-to-day template and CA configuration, security architects own the hierarchy design and blast radius, platform teams own device enrollment paths, compliance verifies audit cadence, and the CISO owns the in-house-versus-managed decision.

How does AD CS connect to certificate lifecycle management?

AD CS issues and revokes certificates, but it does not automatically discover every certificate in use, flag risky templates, or enforce renewal at scale on its own. Certificate lifecycle management tooling closes that gap by adding discovery, automated renewal, and template auditing on top of the native role.

How should organizations measure whether their AD CS deployment is secure?

Track the date of the last ESC1 through ESC8 template and permission audit, confirm KB5014754 strong certificate mapping is in full enforcement rather than compatibility mode, and monitor for certificate-related outages tied to expired or misconfigured certificates.

What should be audited or monitored regularly on an AD CS deployment?

Regularly review certificate template permissions against the ESC misconfiguration categories, confirm the Root CA remains offline and standalone, verify strong certificate mapping enforcement status, and check that NDES and Web Enrollment endpoints are not more broadly exposed than necessary.

How does AD CS fit into cloud, hybrid, or multi-CA PKI environments?

AD CS can operate as one CA in a hybrid model alongside cloud-native platforms such as AWS ACM Private CA or Google Cloud Certificate Authority Service, but it needs its own dedicated review cadence, since ESC-category risks and certificate template sprawl are specific to how AD CS manages permissions inside Active Directory.

What common mistakes should teams avoid with AD CS?

Common mistakes include never revisiting certificate templates after initial deployment, leaving the Root CA connected to the network instead of offline and standalone, assuming macOS devices will enroll the same way domain-joined Windows clients do, and treating KB5014754 as installed rather than confirming full enforcement.

What should be refreshed quarterly for an AD CS deployment?

Review certificate template permissions against current ESC misconfiguration research, confirm strong certificate mapping enforcement status, check for newly published CA/Browser Forum validity period changes, and revisit whether Windows Server 2025’s ML-DSA support changes the crypto-agility roadmap.