Certificate Template Drift Monitoring for Microsoft ADCS

A certificate template hardened correctly today can become exploitable tomorrow with zero new vulnerability, zero new tool, and one attribute change. Templates are ordinary Active Directory objects, anyone with sufficient rights can modify one at any time, which means a point-in-time hardening exercise only proves a template was safe on the day it was reviewed. This is the continuous layer our ESC1-ESC16 hardening guide doesn’t cover on its own: what to baseline, which specific field changes matter, and how to alert on drift before it becomes an exploited path.

TL;DR: Key Takeaways

Templates drift because they’re AD objects, not because anyone is necessarily doing anything malicious: a project-driven permission change, a well-intentioned EKU addition, or a cloned template can each silently reintroduce a hardened-away risk.
A handful of specific attributes account for nearly all meaningful risk: enrollment flags, name flags, EKUs, application policy, RA signature requirements, schema version, and the security descriptor together determine a template’s actual exploitability.
Permission drift is dangerous even with no other change, a WriteDACL or WriteOwner grant to an unexpected principal lets that principal create any other misconfiguration on demand later.
Not every change deserves the same alert severity, a display name edit and a removed manager-approval flag are not the same event, and treating them identically either causes alert fatigue or buries the finding that actually matters.

Why Point-in-Time Hardening Isn’t Enough

A hardening review, including a full ESC1-ESC16 assessment, proves your templates were safe on the day it ran, it makes no claim about the day after, since nothing about a passed assessment prevents someone from changing a template’s configuration the following week.
This is the same gap covered in our broader continuous risk assessment guidance, applied specifically to templates, one of the highest-value, most frequently targeted objects in the entire hierarchy.
Drift monitoring closes that gap by watching for the specific change, not waiting for the next scheduled review, the difference between catching a dangerous change in hours versus discovering it during next quarter’s assessment.

Establishing a Template Baseline: What Fields to Capture

msPKI-Enrollment-Flag: the bitmask controlling manager approval, publication to AD, and other issuance behavior, this is the field ESC1’s manager-approval bypass lives in.
msPKI-Certificate-Name-Flag: the bitmask controlling whether the subject and SAN are built from AD or supplied by the enrollee, the core switch behind ESC1-style subject spoofing.
pKIExtendedKeyUsage and msPKI-Certificate-Application-Policy: the EKU and application policy OIDs a template grants, covering both standard EKU misuse and the ESC15 application-policy override path.
msPKI-RA-Signature: the number of authorized signatures required, governing enrollment agent behavior tied to ESC3.
msPKI-Template-Schema-Version: directly relevant to ESC15 exposure on unpatched CAs, covered in our dedicated CVE-2024-49019 guide.
msPKI-Certificate-Policy: issuance policy OIDs, relevant to the ESC13 privileged-group-linkage pattern.
msPKI-Minimal-Key-Size and the full nTSecurityDescriptor: minimum cryptographic strength and the complete access control list, capture the ACL in full, not a summary, since the specific principals and rights granted are what actually matter.
Capture this baseline with PSPKI or an LDAP export, version it, and timestamp every snapshot, a baseline that isn’t itself dated and retained has nothing reliable to compare future states against.

High-Risk Changes to Watch For

Any change that reproduces a known ESC pattern deserves priority attention, covered in full in our ESC1-ESC16 detection playbook, drift monitoring and that playbook’s detection logic are meant to work together, not separately.
The specific transitions worth alerting on immediately: enrollee-supplied subject enabled where it wasn’t, manager approval removed, a client authentication or smart card logon EKU added, Certificate Request Agent EKU added without corresponding agent restrictions, and any application policy OID appearing that wasn’t there before.
Treat a template that’s cloned or renamed as its own event worth reviewing, a new template inheriting a permissive configuration from an existing one is a common, easy-to-miss way old risk resurfaces under a new name.

Permission Drift

Monitor the full security descriptor for new WriteDACL, WriteOwner, or GenericAll grants, covered in depth in our attack path guidance, a principal with these rights can modify the template’s own configuration later, effectively manufacturing any other finding in this guide on demand.
Watch for Enroll or Autoenroll permission expansion to broad groups, Authenticated Users or Domain Computers being added to a previously narrowly-scoped template meaningfully increases its exposure even if nothing else about the template changed.
Watch for changes to enrollment agent restrictions specifically, a restriction being loosened or removed on a template with the Certificate Request Agent EKU reopens the ESC3 path even if the EKU itself was never touched.

EKU Changes

Alert on any addition of client authentication, smart card logon, or Any Purpose EKUs, to a template that didn’t previously carry them, these are the specific capabilities that turn a template into a viable identity-impersonation path.
Alert on any Application Policy OID change independently of the standard EKU field, this is the specific mechanism behind ESC15, and a change here can grant equivalent capability without the standard EKU field showing anything unusual at all.
Confirm removals as well as additions, an EKU or application policy entry disappearing can indicate an accidental configuration error breaking legitimate use, worth catching for operational reasons even when it isn’t a security concern.

Enrollment Flag Changes

Treat removal of the manager-approval flag as the single highest-severity change covered in this guide, this one bit determines whether a request against an enrollee-supplied-subject template gets a human review before issuance, removing it on such a template makes ESC1 immediately exploitable with no other change required.
Watch for changes to publication behavior, an unexpected change to whether a template’s certificates publish to AD can indicate broader configuration tampering even when it isn’t dangerous on its own.
Correlate enrollment flag changes with the corresponding CA-level change events, covered in our audit logging guidance, a template change with no corresponding authorized change ticket is worth escalating regardless of which specific flag moved.

Subject Control Changes

Alert immediately when enrollee-supplied-subject is enabled on a template that previously built its subject from Active Directory, this single transition is the foundation of ESC1, and it’s meaningful even before checking whether the EKU or approval settings also changed.
Watch for SAN source changes specifically, a shift from AD-derived SAN values to enrollee-supplied ones carries the same risk as the broader subject control change, and can occur independently of it depending on how the template is configured.
Treat this category as a leading indicator, not a standalone concern, a subject control change combined with a permissive EKU and no approval requirement is the complete ESC1 pattern, catching the first change gives you a chance to intervene before the other two conditions are also met.

Alert Thresholds

Treat any single high-risk field change as an immediate, critical alert, regardless of how minor “just one attribute” sounds, manager approval removal, enrollee-supplied-subject enablement, or a new high-privilege EKU each independently warrant this severity.
Treat unexpected permission grants as critical as well, a WriteDACL, WriteOwner, or GenericAll grant to an unreviewed principal deserves the same urgency as a direct configuration change, since it enables one.
Treat schema version and RA signature changes as medium severity, worth prompt review but less immediately exploitable on their own than the changes above.
Treat cosmetic changes, like a display name update with no other field affected, as low-severity, informational logging, not a paged alert, reserve urgent attention for the fields that actually determine exploitability.
Treat simultaneous changes across many templates as its own critical signal, independent of what any individual change looks like, a batch modification pattern is consistent with either a scripted, authorized administrative change or something considerably less benign, and deserves confirmation either way.

How Encryption Consulting Can Help

Building genuine template drift monitoring, correctly scoped to the fields that actually matter and tuned to avoid burying critical findings under cosmetic noise, is exactly the kind of detail-heavy detection engineering that benefits from real AD CS expertise.

Encryption Consulting’s PKI Services team supports this directly:

Baseline establishment: capturing and versioning a complete, accurate configuration snapshot across every template in your hierarchy.
Drift detection implementation: building the specific comparison logic and alert thresholds covered in this guide into your actual SIEM or monitoring platform.
Integration with ESC1-ESC16 detection: ensuring drift monitoring and periodic assessment work together rather than as disconnected efforts.
Alert tuning, calibrating severity so genuinely dangerous changes get immediate attention without drowning your team in low-value notifications.
Ongoing template governance, integrated into the broader continuous risk assessment and compliance monitoring practices covered throughout our AD CS series.

If your certificate templates were hardened once but haven’t been watched since, our PKI Services team can build the continuous monitoring that keeps them that way.

Conclusion

Hardening a certificate template is a snapshot, drift monitoring is what keeps that snapshot true. Baseline every field that actually determines exploitability, enrollment flags, name flags, EKUs, application policy, RA signatures, schema version, and the full security descriptor, and alert with severity that matches real risk: a removed approval requirement or a new WriteDACL grant deserves immediate attention, a display name change doesn’t. Pair this continuous layer with the periodic depth of a full ESC1-ESC16 assessment, neither one replaces the other.

Were your certificate templates hardened once but never watched since? Talk to our PKI Services team about building continuous drift monitoring. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Which certificate template attributes should be included in a drift monitoring baseline? msPKI-Enrollment-Flag, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Certificate-Application-Policy, msPKI-RA-Signature, msPKI-Template-Schema-Version, msPKI-Minimal-Key-Size, msPKI-Certificate-Policy, and the template’s full security descriptor (nTSecurityDescriptor) together cover every field that materially affects a template’s risk profile.

What is the single highest-severity certificate template change to alert on? Removal of the CT_FLAG_PEND_ALL_REQUESTS bit from msPKI-Enrollment-Flag on a template that allows enrollee-supplied subjects, since this disables manager approval on exactly the template configuration ESC1 depends on, turning a previously safe template into an immediately exploitable one with a single attribute change.

Why is permission drift on certificate templates dangerous even without any EKU or flag changes? Because a WriteDACL, WriteOwner, or GenericAll grant to an unexpected principal lets that principal modify the template’s own security descriptor later, effectively creating any other misconfiguration on demand rather than requiring one to already exist.

Does template drift monitoring replace a one-time ESC1-ESC16 assessment? No. An ESC1-ESC16 assessment establishes whether your templates are safe today. Drift monitoring is what keeps that assessment’s findings valid tomorrow, by alerting the moment a previously safe configuration changes, rather than waiting for the next scheduled scan to notice.

Should a change to a template’s display name trigger the same alert as an EKU change? No. Cosmetic changes like a display name update warrant a low-severity, informational log entry, while changes to enrollment flags, EKUs, subject controls, or permissions warrant immediate, high-severity alerts, since these are the specific fields that determine whether a template is exploitable.