A certificate template is a predefined set of rules, stored in Active Directory, that an Enterprise Certification Authority applies every time it issues a certificate. Templates decide what a certificate contains, who may request it, how long it is valid, which cryptographic settings it uses, and what it can be used for. They make certificate issuance across Microsoft Active Directory Certificate Services (AD CS) consistent, repeatable, and easy to govern, instead of letting every requester define properties on their own.
Enterprises can issue and manage hundreds of thousands of digital certificates every year across users, computers, web servers, applications, devices, VPNs, and smart cards. If each request had to be configured by hand, certificate management would quickly become inconsistent, slow, and hard to secure. Microsoft addresses this through certificate templates.
Certificate templates are the rule sets that AD CS Enterprise CAs use to standardize issuance. Rather than letting every requester choose certificate properties independently, a template specifies exactly what a certificate should contain, who can request it, how long it stays valid, which algorithms it uses, and what it may be used for.
One important point to keep in mind: unlike certificates themselves, certificate templates are not part of the X.509 standard. They are a Microsoft-specific capability in Enterprise CAs integrated with Active Directory. Organizations using standalone CAs or other PKI platforms may apply similar policy controls, but they do not use Microsoft certificate templates.
What Is a Certificate Template
A certificate template is an Active Directory object that defines the policy an Enterprise CA applies whenever it issues a certificate. It works as a blueprint for the certificate’s contents and its enrollment requirements.
When a user, computer, or application submits a request, the Enterprise CA identifies the requested template, checks that the requester has permission to use it, and issues a certificate that matches the template’s configuration. That removes manual decision-making during enrollment and keeps certificates consistent across the organization. A template can define the certificate purpose, subject name format, key size, cryptographic provider, validity and renewal periods, key usage, extended key usage (EKU), enrollment permissions, and private key settings. Because these policies live centrally in Active Directory, administrators manage issuance from one place rather than configuring each certificate individually.
How Certificate Templates Work
Enrollment begins when a user, device, or service requests a certificate. The request references a specific template, and the Enterprise CA retrieves that template’s configuration from Active Directory.
Before issuing, the CA evaluates several conditions. It confirms the requester has enrollment permissions, applies any required approval policy, checks the cryptographic requirements, and validates that the template’s conditions are satisfied. Only then does it generate a certificate that conforms to the template. The separation of duties is the key idea: the template defines the issuance policy, and the Enterprise CA enforces that policy during enrollment.
What a Certificate Template Defines
A template can control nearly every aspect of an issued certificate. The settings administrators configure most often are below.
| Template setting | Purpose |
|---|---|
| Certificate purpose | Whether the certificate is for users, computers, web servers, code signing, smart cards, or other uses |
| Subject name | How the identity is populated, automatically from Active Directory or supplied by the requester |
| Cryptographic settings | Key algorithm, key length, cryptographic provider, and hashing requirements |
| Validity period | The certificate lifetime and its renewal timing |
| Key usage and EKUs | How the certificate may be used, such as TLS server authentication, client authentication, or code signing |
| Enrollment permissions | Which users, groups, or computers may request the certificate |
| Private key protection | Exportability, archival, hardware-backed storage, and any user-interaction requirement |
These controls keep certificates appropriate for their intended workload while cutting down configuration errors.
Certificate Template Versions
AD CS has introduced several template versions, often called schema versions, as Windows Server has evolved. Getting the version right matters, because cryptographic capabilities such as CNG depend on it.
| Version | Introduced with | Key capabilities |
|---|---|---|
| Version 1 | Windows 2000 | Built-in templates that cannot be modified, only their permissions can be changed |
| Version 2 | Windows Server 2003 | Customizable templates, enrollment permissions, template superseding, key archival, and autoenrollment support |
| Version 3 | Windows Server 2008 | All Version 2 features plus Cryptography Next Generation (CNG), Key Storage Providers (KSPs), and elliptic-curve cryptography (note: the NSA Suite B algorithm profile introduced with this version was deprecated in favour of CNSA 1.0 in 2015 and superseded by CNSA 2.0 in 2022) |
| Version 4 | Windows Server 2012 | TPM key attestation, key-based renewal, renew with the same key, and the ability to specify multiple providers |
Modern deployments generally use Version 3 or Version 4 templates, since these support current cryptographic providers and standards. Because a Version 4 template requires a Windows Server 2012 or later CA and a Windows 8 or later recipient, the compatibility settings on the template determine which schema version is actually created.
Post-Quantum Readiness and Certificate Templates
Microsoft Active Directory Certificate Services on Windows Server 2025 now supports post-quantum cryptography. The May 2026 Patch Tuesday update introduced ML-DSA-44, ML-DSA-65, and ML-DSA-87, the Module-Lattice-Based Digital Signature Algorithm standardised by NIST as FIPS 204, for certificate signing operations in AD CS.
Post-quantum certificate templates have two requirements: the template must use a CNG Key Storage Provider (not a legacy Cryptographic Service Provider), and the Request Handling purpose must be set to Signature, since ML-DSA supports signing operations only. These requirements mean that only Version 3 or Version 4 templates can carry PQC algorithms.
Composite certificates, combining a classical algorithm such as ECDSA with an ML-DSA signature, are also supported, allowing relying parties that do not yet understand post-quantum formats to continue validating signatures using the classical component.
Organizations planning a PQC migration should note that existing certification authorities cannot be upgraded in place. Post-quantum support requires deploying a new, parallel CA hierarchy alongside the existing production environment. Cryptographic agility, designing templates and enrollment workflows so algorithm choices can be updated without a full infrastructure rebuild, should be a guiding principle for any template architecture designed today.
For organizations subject to CNSA 2.0, new National Security System acquisitions must support CNSA 2.0 algorithms from 1 January 2027, with full migration required by 31 December 2031. NIST IR 8547 sets a parallel deprecation runway for classical asymmetric algorithms across the broader federal and commercial landscape, with disallowance targeted for 2035. Certificate template planning today, including CNG provider migration, parameter-set selection, and parallel CA hierarchy design, should account for both timelines.
Why Do Certificate Templates Matter
Templates are one of the main reasons Enterprise PKI stays manageable at scale. Without standardized issuance policy, administrators would have to review and configure every request individually, raising both effort and security risk.
Templates improve consistency, since similar systems receive identical configurations, and they strengthen security by enforcing approved algorithms, restricting who can enroll, preventing inappropriate certificate use, and keeping policy control central. As organizations move to shorter certificate lifetimes and more automation, consistent issuance policy matters even more, and templates are the foundation that makes large-scale certificate lifecycle management practical.
Common Mistakes
A frequent mistake is modifying built-in Version 1 templates rather than duplicating them. The supported approach is to duplicate an existing template, which lets administrators customize settings while preserving the defaults. Duplicating a Version 1 template also upgrades it automatically to Version 2, removing the vulnerability addressed by CVE-2024-49019 (patched November 2024), which allowed an attacker with enrollment rights to embed arbitrary Application Policies into a certificate request and obtain certificates beyond the template’s intended purpose.
Misconfigured certificate templates are also one of the most critical privilege-escalation vectors in Active Directory environments. The ESC vulnerability class covers a range of template and CA misconfigurations that enable attackers to obtain certificates for high-privilege accounts.
ESC1 occurs when a template has the Enrollee Supplies Subject flag enabled while also granting enrollment rights to low-privileged accounts such as Domain Users. This combination lets an attacker request a certificate for any account, including a Domain Administrator, and authenticate as that account.
APT29 and UNC5330 exploited this pattern in 2022 and 2024 respectively to achieve full domain compromise. ESC4 arises when low-privileged accounts hold WriteProperty, WriteDacl, or WriteOwner rights on a certificate template object in Active Directory, letting them modify the template’s configuration and introduce ESC1-style weaknesses.
Both misconfigurations are preventable through strict least-privilege template permissions, disabling the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag on templates that do not require it, and regular auditing.
Granting enrollment permissions too broadly is another common issue, because allowing unnecessary users or systems to request certificates raises the risk of unauthorized issuance and privilege escalation. Administrators also tend to define certificate purposes too widely; combining several unrelated EKUs in one template violates least privilege and makes certificates harder to manage over their lifecycle.
Finally, templates are often left unreviewed, so a template that once matched policy drifts out of date as cryptographic guidance, certificate lifetimes, and business needs change.
Security Best Practices
Templates should follow least privilege, allowing enrollment only for authorized users, devices, and services. Require strong algorithms, appropriate key lengths, and non-exportable private keys wherever practical, especially for sensitive certificates.
Review template permissions regularly: confirm that low-privileged accounts such as Domain Users and Authenticated Users do not hold Enroll rights on authentication-capable templates, that no non-PKI-admin principals hold WriteProperty, WriteDacl, or WriteOwner rights on template objects (ESC4 vector), and that the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is disabled on all templates that do not explicitly require it.
Run Certipy or Microsoft Defender for Identity’s AD CS security posture assessments to enumerate misconfigured templates. Retire obsolete templates so they cannot be used by accident. Protect private keys in hardware using a Hardware Security Module or a TPM to reduce the risk of key compromise.
Scope EKUs narrowly, keeping unrelated uses in separate templates rather than bundling them.
Integrate template governance with lifecycle management, so issued certificates are monitored, renewed, revoked, and audited across their operational life. Configure CRL Distribution Point (CDP) and OCSP Authority Information Access (AIA) extensions in each template so relying parties can verify revocation status; templates serving externally-facing certificates must specify publicly reachable CDP and OCSP URLs, not internal-only endpoints.
Applied consistently, these steps keep issuance both secure and predictable as the environment grows.
How Encryption Consulting Can Help
A well-designed template estate is the difference between a TLS and certificate program that scales cleanly and one that accumulates risk in misconfigured issuance policy. As a cryptography-focused practice, Encryption Consulting brings purpose-built PKI expertise that broad cybersecurity firms cannot replicate.
Through its Enterprise PKI Services, EC helps design, deploy, and optimize Microsoft AD CS environments and the issuance policy around them, covering template architecture, enrollment workflows, CA hierarchy design, cryptographic policy, and governance, keeping the deployment audit-ready and aligned with NIST, FIPS, eIDAS, and WebTrust, with root and subordinate CA keys protected by FIPS 140-3 Level 3 HSMs. CertSecure Manager complements AD CS with centralized certificate discovery, inventory, lifecycle automation, expiration monitoring, and compliance reporting across the enterprise.
Certificate mismanagement and expired credentials are preventable risks, and EC’s practitioners identify and remediate them before they trigger an incident. As organizations plan their post-quantum migration, EC’s PQC Readiness Assessment maps the full AD CS transition pathway, from generating a Cryptographic Bill of Materials (CBOM) through CertSecure Manager and migrating CSP-bound templates to CNG Key Storage Providers, to designing and deploying a parallel ML-DSA CA hierarchy on Windows Server 2025 and selecting the right parameter sets for each certificate workload.
Whether you are standardizing certificate issuance, modernizing a legacy AD CS deployment, or preparing templates for post-quantum cryptographic requirements, EC delivers without disruption, so digital trust stays engineered rather than left to chance.
Conclusion
Certificate templates are the policy engine behind issuance in Microsoft AD CS. By defining how certificates are created, who may request them, and how they are protected across their lifecycle, templates help organizations stay consistent, strengthen security, and automate certificate management at scale.
As enterprise environments expand and certificate lifetimes shorten, well-designed templates are not just an administrative convenience; they are a foundational part of secure, scalable PKI operations. A practical first step is to inventory the templates currently published on your issuing CAs, retire any that are unused or overly broad, and confirm that each remaining template enforces current cryptographic settings and least-privilege enrollment.
