ADCS Audit Logging Deep Dive

Most AD CS audit logging problems aren’t detection problems, they’re plumbing problems: a filter category that was never enabled, an OS-level audit policy setting that silently conflicts with a legacy one, events sitting only in a local log nobody’s actually forwarding anywhere, or a SIEM integration nobody’s validated since the day it was built. We’ve covered the newer enhanced logging capabilities as part of our broader roundup of AD CS product changes. This is the standalone reference for the whole pipeline: categories, filter, collection, retention, fields, SIEM integration, and how to actually confirm it’s working.

For what these events actually mean once you’re collecting them, see Microsoft ADCS Event IDs 4886-4889 Explained.

TL;DR: Key Takeaways

Audit logging requires two separate layers configured together: the CA’s own AuditFilter bitmask, and the operating system’s audit policy subcategory, missing either one means no events at all, regardless of how the other is configured.
The AuditFilter covers seven distinct categories, not one on/off switch: from certificate request issuance to CA configuration changes, each category has its own bit value, and the common baseline of 127 enables all seven together.
Legacy and Advanced Audit Policy settings can silently conflict: the “Force audit policy subcategory settings” policy exists specifically to resolve this, and skipping it is a common, quiet cause of missing events even when everything else looks correctly configured.
A local-only Security log is not a logging strategy, it’s a single point of failure, vulnerable to size rollover and to tampering if the CA itself is ever compromised, forwarding to centralized storage is a standing requirement, not an optional enhancement.
Validation isn’t a one-time setup step, confirming the full pipeline, from CA event generation through to SIEM arrival, needs to be tested periodically, not assumed correct forever after the initial build.

The Two-Layer Requirement Nobody Explains Clearly

Layer one is the CA’s own AuditFilter setting, a bitmask stored in the CA’s registry configuration that determines which categories of activity the CA itself will generate audit events for.
Layer two is the operating system’s audit policy, which has to separately enable the Certification Services subcategory for those CA-generated events to actually be written to the Security log at all.
Both layers have to be correctly configured together, a CA with its AuditFilter set to 127 but no corresponding OS audit policy enabled produces no events whatsoever, and the reverse is equally true, this is the single most common reason organizations discover a logging gap only after they needed the data.

The CA Audit Filter: All Seven Categories Explained

Value 1, start and stop AD CS: logs when the Certificate Services process itself starts or stops.
Value 2, back up and restore the CA database: logs backup and restore operations against the CA’s database.
Value 4, issue and manage certificate requests: the category behind the request lifecycle events covered in our dedicated event ID 4886-4889 reference, this is usually the category with the highest event volume.
Value 8, revoke certificates and publish CRLs: logs revocation actions and CRL publication events.
Value 16, change CA security settings: logs changes to the CA’s own security configuration, a category worth weighting heavily given how consequential a security setting change can be.
Value 32, store and retrieve archived keys: logs key archival and recovery operations, directly relevant to the key recovery scenarios covered in our guide to recovering deleted user certificates.
Value 64, change CA configuration: logs broader CA configuration changes beyond security settings specifically.
Set the filter with certutil -setreg CA\AuditFilter <value>, followed by a Certificate Services restart, summing all seven values gives 127, the common baseline enabling every category together, a value worth using as a default rather than selectively enabling only a subset.
Watch for Event ID 4885 as a self-monitoring signal, this event logs whenever the audit filter itself changes, meaning any unauthorized attempt to quietly reduce your CA’s own audit coverage is, itself, audited.

Enabling the OS-Level Audit Policy

Enable the Certification Services subcategory under Advanced Audit Policy Configuration, found at Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Object Access → Audit Certification Services.
Use Group Policy rather than local security policy, applied to every CA server through a dedicated GPO, this persists reliably and isn’t at risk of being silently overwritten by a different policy application later, a real risk with settings configured only through local secpol.msc.
Enable “Audit: Force audit policy subcategory settings” specifically, this resolves a genuine conflict between legacy basic audit policy categories and the newer Advanced Audit Policy subcategories, without it, older, broader audit policy settings can silently override the more granular subcategory configuration you actually intended.
Confirm both settings applied correctly with auditpol /get /subcategory:"Certification Services", don’t assume a GPO applied successfully just because you pushed it, verify the actual resulting state on the CA server itself.

Event Collection and Forwarding

Treat a local-only Security log as a starting point, not a destination: events sitting only on the CA server itself are vulnerable to log size rollover on a busy CA, and to tampering entirely if the CA server is ever compromised, exactly the scenario where you’d most need reliable historical logging.
Forward events through Windows Event Forwarding or a SIEM collection agent, either approach gets events off the CA server and into centralized, access-controlled storage as they’re generated, rather than depending on someone remembering to pull them later.
Confirm network and firewall requirements support your chosen forwarding method, before assuming forwarding is working, WEC and most SIEM agents have specific connectivity requirements that are easy to overlook in a segmented network.
Apply the same forwarding configuration consistently across every CA in your hierarchy, a forwarding gap on one issuing CA, discovered only when you need historical data from it specifically, defeats the purpose of building this pipeline in the first place.

Retention

Size local Security log retention against actual request volume, a high-volume issuing CA generates a correspondingly high event volume, a default log size that was fine for a much smaller CA years ago can roll over and lose data far faster than expected.
Set centralized SIEM retention based on your actual compliance requirements, not a generic default, different frameworks and internal policies specify different minimum retention periods for security-relevant audit data, confirm what actually applies to your organization rather than assuming your SIEM’s out-of-box retention setting is sufficient.
Consider write-once or otherwise tamper-resistant storage for your retained audit data, particularly relevant for CA-related events specifically, given how consequential a compromised or manipulated audit trail would be for any subsequent investigation.
Confirm retention actually matches policy, don’t just configure it once and assume it holds, storage costs and retention settings have a way of getting quietly adjusted downward during unrelated infrastructure changes, periodic confirmation is worth the effort.

Fields Worth Mapping in Your SIEM

Request ID, the correlation key across the entire request lifecycle, map this as a dedicated, searchable field rather than leaving it buried in unparsed event text.
Requester and Attributes, the fields your detection logic actually depends on, covered in depth in our event ID reference, these need to be reliably extracted, not left as raw text your analysts have to manually parse during an investigation.
Disposition, on denial-related events, worth mapping as its own field to support the denial-rate monitoring covered in our detection logic guidance.
Event 4885 (audit filter changes) and events 4890 through 4898 (configuration and template changes), map these with the same rigor as request lifecycle events, since correlating a suspicious issuance against a recent configuration change is exactly the kind of investigation these fields need to support quickly.

SIEM Integration

Decide between raw XML and rendered event text parsing early, the underlying event data is more reliably structured as XML, but many SIEM platforms and analysts work more naturally with the rendered, human-readable event text, choose deliberately based on your platform’s actual parsing capability rather than defaulting to whichever is easier to set up initially.
Build specific field extraction for the Attributes field’s semi-structured content, this field carries multiple pieces of information (template name, subject, and on Windows Server 2025 with enhanced logging, SAN values, client OS, CSP, and authentication type) in a single text blob, extracting these into separate, queryable fields is what actually makes correlation and detection logic practical rather than theoretical.
Tag every ingested event with its source CA explicitly, in a multi-CA hierarchy, knowing which specific CA generated an event without having to cross-reference a separate asset inventory saves real time during an investigation.
Build your correlation rules on top of this foundation, the specific detection logic, Subject/SAN mismatches, denial rate spikes, post-configuration-change issuance, covered in our event ID reference, all depend on the field extraction described here actually being in place first.

Validation: Confirming the Pipeline Actually Works

Generate a real test certificate request, rather than assuming configuration correctness from settings alone, an actual enrollment against a low-risk template exercises the entire pipeline end to end.
Confirm the corresponding event appears in the local Security log first, this isolates whether a problem is at the CA/OS audit configuration layer or further downstream in your forwarding and SIEM pipeline.
Confirm the event arrives in your SIEM within the expected latency window, don’t just confirm eventual arrival, unusually delayed arrival is itself a signal worth investigating, a forwarding pipeline running meaningfully behind real time reduces the practical value of your detection logic.
Use Event 4885 as a periodic canary test, deliberately (and carefully, in a controlled window) toggling an audit filter category and confirming the resulting 4885 event is captured end to end validates that even audit-configuration-change monitoring itself is functioning.
Repeat this validation on a recurring schedule, not just at initial setup, configuration drift, forwarding infrastructure changes, and SIEM platform updates can all quietly break a pipeline that was correctly validated months earlier.

How Encryption Consulting Can Help

Building a genuinely complete AD CS audit pipeline, correctly configured at both the CA and OS layers, reliably forwarded, properly retained, and actually validated end to end, is exactly the kind of infrastructure work that’s easy to leave partially finished once the obvious pieces are in place.

Encryption Consulting’s PKI Services team supports this directly:

Full audit pipeline design and implementation: configuring AuditFilter categories, OS-level audit policy, and forwarding infrastructure correctly across your entire CA hierarchy, not just one representative server.
SIEM integration and field mapping: building the extraction and correlation foundation your detection logic actually depends on, tailored to your specific SIEM platform.
Retention policy alignment: sizing local and centralized retention against both your actual request volume and your real compliance requirements.
Pipeline validation testing, confirming your audit logging actually works end to end, not just that the individual settings are configured correctly in isolation.
Ongoing pipeline health monitoring, integrated into your broader continuous PKI risk assessment practice, so drift in your logging infrastructure itself doesn’t go unnoticed.

If you’re not confident your AD CS audit logging actually reaches your SIEM reliably, or want the full pipeline built correctly from the start, our PKI Services team can design and validate it.

Conclusion

AD CS audit logging is a pipeline, not a checkbox, the CA’s own AuditFilter, the OS-level audit policy subcategory, event forwarding, retention, and SIEM field mapping all have to be correctly built and kept working together. Most gaps aren’t sophisticated failures, they’re a category that was never enabled, a legacy-versus-advanced audit policy conflict nobody resolved, or a forwarding pipeline that was validated once and never checked again. Build all the layers deliberately, and validate the whole thing periodically, not just at initial setup.

Not confident your AD CS audit logging actually reaches your SIEM reliably? Talk to our PKI Services team about designing and validating a complete pipeline. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What are the seven categories in the AD CS AuditFilter bitmask? Start and stop AD CS (1), back up and restore the CA database (2), issue and manage certificate requests (4), revoke certificates and publish CRLs (8), change CA security settings (16), store and retrieve archived keys (32), and change CA configuration (64). Summing all seven values gives 127, the setting enabled when every category is checked.

Why do AD CS audit events still not appear even after setting the AuditFilter to 127? The AuditFilter is only half the requirement. The operating system’s own audit policy also has to enable the Certification Services subcategory, and if legacy audit policy settings and the newer Advanced Audit Policy subcategories conflict, the “Audit: Force audit policy subcategory settings” policy needs to be enabled so the subcategory setting actually takes precedence.

Should AD CS audit policy be configured through Group Policy or local security policy? Group Policy is the recommended approach specifically because it persists reliably and won’t be silently overwritten by another policy application later, which is a real risk with settings configured only through local security policy on the CA server itself.

Is it safe to rely only on the CA server’s local Security log for AD CS audit events? No. A local-only log is a single point of failure, vulnerable to log size rollover on high-volume CAs and to tampering if the CA server itself is ever compromised. Events should be forwarded to centralized, access-controlled storage, through Windows Event Forwarding or a SIEM collection agent, as a standing practice.

How do you validate that an AD CS audit logging pipeline is actually working end to end? Generate a real test certificate request, confirm the corresponding event appears in the local Security log, then confirm it arrives in your SIEM or central log store within the expected latency window. Periodically repeat this test rather than validating the pipeline once at setup and assuming it stays correct indefinitely.