ADCS Configuration Drift Detection: What to Monitor

Certificate templates aren’t the only thing that drifts. A CA’s registry configuration, its publication points, the services it depends on, its permissions, its HSM configuration, and the network path relying parties use to reach it can all change independently, none of it touching a single certificate directly, and each capable of quietly degrading your PKI’s security or availability. This is the infrastructure-level companion to our certificate template drift monitoring guide, covering every other drift point that matters.

TL;DR: Key Takeaways

This guide is scoped to infrastructure, not certificate templates: for EKU, enrollment flag, and subject control drift specifically, see our dedicated template drift guide, this covers everything else.
Registry, permission, and service configuration can all drift with zero certificates ever being touched, none of it shows up in a certificate inventory review.
Publication point drift is especially dangerous because it’s silent, a changed CDP/AIA URL doesn’t break new issuance, it orphans validation for certificates already in circulation.
Network dependency drift, firewall rules, reverse proxy configuration, DNS records, is often invisible to the PKI team entirely, since it’s frequently owned by a different team altogether.

CA Registry

Monitor CRL and delta CRL period settings, an unexpected change here alters how current your revocation data is without touching a single certificate.
Monitor the AuditFilter value specifically, covered in depth in our audit logging guide, a reduction here quietly weakens your entire evidentiary trail.
Monitor dangerous policy flags, EDITF_ATTRIBUTESUBJECTALTNAME2 and similar settings, given how rare a legitimate reason to enable them actually is.
Monitor RenewalValidityPeriod and related renewal settings, an unexpected change here only surfaces at the next renewal, often long after the actual change occurred.

Certificate Templates (Summary)

Templates are covered in full depth in our dedicated guide, this section exists only to confirm template drift belongs in your overall monitoring scope, not to duplicate that guide’s detail here.
At minimum, confirm your template drift monitoring is actually running, as part of this broader infrastructure review, rather than assuming it’s covered elsewhere without verifying.

CDP/AIA

Monitor publication URL configuration for any change, this is silent and delayed damage, a changed URL doesn’t affect new issuance, it orphans validation for every certificate already issued referencing the old location.
Monitor whether publication still uses an abstracted hostname, covered in our migration guidance, a regression back to a literal server name reintroduces exactly the fragility that abstraction was meant to solve.
Monitor actual reachability, not just configuration, a correctly configured CDP that’s become unreachable from a specific network segment is drift too, even though nothing about its configuration technically changed.

Audit Policy

Monitor both audit prerequisites together, the CA’s own AuditFilter and the OS-level Certification Services subcategory, drift in either one silently breaks your event collection.
Treat Event 4885 as a standing, high-priority signal on its own, since it specifically logs changes to the audit filter itself.
Confirm the “Force audit policy subcategory settings” policy hasn’t been reverted, covered in our audit logging guide, this specific setting resolves a real conflict between legacy and advanced audit policy that can silently reappear.

Services

Monitor Certificate Services, NDES’s application pool, and Online Responder service states independently, each can fail while the others, and the underlying OS, report healthy.
Monitor service account configuration for each, a service account change is itself a drift event worth flagging, distinct from the service’s running state.
Correlate unplanned service restarts against configuration change events, a restart shortly after a flagged change is corroborating evidence worth investigating together.

Permissions

Monitor CA-level Manage CA and Manage Certificates rights, covered in depth in our attack path and Tier 0 guidance, a broader-than-documented grant here has a wider blast radius than any single template misconfiguration.
Monitor local administrator group membership on every CA and NDES server, drift here often happens through routine IT operations rather than deliberate PKI administration, which is exactly why it needs its own explicit check.
Monitor NTAuth store membership, an unexpected addition or removal here affects Kerberos certificate-based authentication trust across your entire domain.

HSMs

Monitor HSM partition access control lists for unexpected principals, this is a Tier 0-equivalent asset, and its access list deserves the same drift scrutiny as any other Tier 0 permission set.
Monitor for unexplained key container creation, a new container appearing without a corresponding, authorized change is worth investigating regardless of whether anything else looks unusual.
Monitor HSM client and firmware version currency, drift here isn’t malicious, but it’s exactly the kind of silent gap that causes a migration or renewal to fail unexpectedly months later.

Network Dependencies

Monitor firewall rules governing CA and NDES traffic, a rule change made for an unrelated reason can silently break or, worse, silently over-expose PKI infrastructure.
Monitor reverse proxy configuration for NDES, covered in our NDES hardening guidance, this is a deliberate architectural exception and any drift in it deserves scrutiny given what it’s protecting.
Monitor DNS records for abstracted CDP/AIA and enrollment hostnames, an unexpected CNAME change here has the same silent, delayed impact as a direct publication URL change.

How Encryption Consulting Can Help

Monitoring infrastructure-level drift across registry settings, permissions, services, HSMs, and network dependencies together, rather than as disconnected concerns owned by different teams, is what actually closes the gap most PKI monitoring leaves open.

Encryption Consulting’s PKI Services team supports this directly:

Infrastructure baseline and drift detection design: building the comparison logic across every category in this guide, tailored to your environment.
Cross-team coordination: closing the gap where network and infrastructure changes affecting PKI are made by teams outside your PKI group entirely.
Integration with template drift and compliance monitoring, so infrastructure and template drift are tracked together, not as separate, disconnected efforts.
Alerting and remediation support, turning detected drift into tracked, resolved findings.

If your PKI monitoring covers certificates but not the infrastructure underneath them, our PKI Services team can close that gap.

Conclusion

Certificate template drift gets most of the attention, for good reason, but a CA’s registry, publication points, services, permissions, HSM configuration, and network dependencies can all drift independently, and several of them do so silently, with damage that only surfaces much later. Monitor all eight categories here as a genuine, connected practice, and pair this with dedicated template drift monitoring rather than treating either as sufficient alone.

Is your PKI monitoring covering the infrastructure underneath your certificates, not just the certificates themselves? Talk to our PKI Services team. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What’s the difference between this guide and template drift monitoring specifically? This guide covers infrastructure-level configuration drift across the CA itself, publication points, services, permissions, HSMs, and network dependencies. Certificate template attribute drift, EKUs, enrollment flags, and subject controls specifically, is covered in full depth in our dedicated template drift monitoring guide.

Why does CA registry configuration need drift monitoring at all? Because settings like CRLPeriod, AuditFilter, and policy flags live outside the certificate database entirely and can be changed without any certificate ever being touched. A registry change here can silently alter CA behavior in ways that only surface later as a validation failure or an audit gap.

Can a CDP or AIA URL change without anyone noticing? Yes, if publication configuration isn’t actively monitored. A changed publication URL doesn’t break anything immediately for the CA issuing new certificates, but it can silently orphan validation for every certificate already issued referencing the old location.

How often should infrastructure-level AD CS configuration drift be reviewed? Continuously where automated monitoring is feasible, and at minimum as part of a monthly health check for anything not yet automated, since registry, permission, and service configuration can all change between any two scheduled review dates.