ADCS Telemetry Guide: Events, Metrics, Logs, and Alerts

Every other piece of AD CS monitoring guidance eventually asks the same unstated question: what should actually be collected in the first place. This is that reference, a foundational catalog of every event, metric, log, and alert worth capturing across CA events, service status, request latency, failures, CRL publication, OCSP, database health, and suspicious changes, built specifically to feed a SIEM and support ongoing posture management, not just answer a single, narrow question.

This guide is the collection-layer foundation underneath ADCS Threat Hunting Playbook, ADCS ESC1-ESC16 Detection Playbook, and Continuous ADCS Risk Assessment vs One-Time Audits, all of which depend on the telemetry cataloged here actually being collected.

TL;DR: Key Takeaways

Four distinct telemetry types apply throughout AD CS: events (discrete occurrences), metrics (numeric measurements over time), logs (detailed records needing correlation), and alerts (threshold-triggered notifications built on the other three).
Certificate request lifecycle events are the single highest-value data source, correlated by Request ID, they touch issuance volume, failure patterns, and approval queue health all at once, and connect to nearly every other category in this guide.
CRL and OCSP health are related but distinct monitoring domains, OCSP carries failure modes, signing certificate expiration and array synchronization specifically, that CRL monitoring alone doesn’t cover.
Suspicious configuration changes are usually low-volume and high-signal, AuditFilter reductions, CA-wide policy flags, and template ACL changes happen infrequently enough that any occurrence deserves scrutiny.
This is a collection reference, not a detection or response guide, use it to build your SIEM ingestion foundation, then layer the detection logic from our threat hunting and ESC detection playbooks on top.

How to Use This Guide

Each category below distinguishes between events (what happened), metrics (how much, how fast, how often), logs (where the detail lives), and alerts (when to actually notify someone). Build collection for all four types per category before layering detection logic on top, a SIEM with events but no metrics, or metrics with no alerting thresholds, leaves real gaps in what you can actually see.

CA Events

Event ID	Meaning	Category
4886	Certificate request received	Request lifecycle
4887	Certificate request approved and issued	Request lifecycle
4888	Certificate request denied by CA policy	Request lifecycle
4889	Certificate request set to pending	Request lifecycle
4868	Pending request denied by a certificate manager	Request lifecycle
4885	CA audit filter changed	Configuration integrity
4890-4898	CA configuration, security settings, key archival, and database row changes	Configuration
100	Certificate Services failed to load or verify the current CA certificate	Service health

Correlate everything through Request ID, this is the field tying 4886, 4887, 4888, and 4889 together for a single request, covered in full detail in our dedicated event ID reference.
Enable both prerequisite audit settings before expecting any of this data to appear, the CA’s own AuditFilter and the OS-level Certification Services audit subcategory, covered in our audit logging deep dive, missing either produces silent gaps in this entire category.

Service Status

Track Certificate Services state directly, running, stopped, or crashed, distinct from general server uptime metrics, a healthy OS can still have a stopped or crashed CA service.
Track NDES’s SCEP application pool state independently, this can fail while the underlying IIS service and OS both report healthy.
Track the Online Responder service state per instance, particularly relevant in an array configuration where individual members can fail independently of the array as a whole.
Log service restarts and correlate their timing against configuration change events, an unplanned restart shortly after a flagged configuration change is a corroborating signal worth investigating together.

Request Latency

Measure the time between request receipt (4886) and final disposition (4887, 4888, or 4869), as a metric tracked over time, not just a per-request detail, a trending increase often surfaces a developing CA performance or HSM connectivity issue before it becomes an outright failure.
Measure client-side CRL and CA certificate retrieval latency separately, from an actual relying-party perspective, not just server-side publication timing, this is what your topology monitoring guidance depends on for genuine chain-validation health.
Measure OCSP response latency independently, a responder that’s technically up but responding slowly can cause client-side timeouts that look like an outage without ever generating a clean failure event.

Failures

Categorize failures by root cause, not a single aggregate count, policy-based denials, HSM or key access errors, database timeout errors like the 0x80070006 handle-invalid error, and NDES challenge password expiration are genuinely different problems requiring different responses.
Track failure rate as a trend per category, a slowly rising denial rate concentrated on one requester or template is a different signal than an isolated spike tied to a known, temporary CA maintenance window.
Correlate renewal-specific failures against the exact error signatures covered in our renewal troubleshooting guide, rather than treating every CA error as equally uninformative.

CRL Publication

Track base and delta CRL publication success and timing independently, a healthy base CRL with a silently failing delta CRL produces confusing, intermittent revocation-check failures that are easy to misdiagnose.
Measure actual publication latency against your configured CRL period, don’t just confirm publication eventually happened, confirm it happened within the window your configuration and relying parties actually expect.
Confirm reachability from multiple network segments, not just the CA’s own subnet, a CRL that publishes successfully but is unreachable from a remote site is a real, distinct failure mode.
Track per-partition publish status if you’ve implemented CRL partitioning, covered in our partitioning architecture guide, an aggregate “CRL published” status can mask a single failing partition.

OCSP

Track responder health and, separately, signing certificate expiration, these are genuinely distinct failure modes, a fully operational responder with an expired signing certificate stops being trustworthy even though the service itself reports healthy.
Track array controller and member synchronization state, covered in depth in our OCSP configuration management guide, a member showing configuration inconsistent with its controller is worth investigating on its own.
Track response latency and error rate as ongoing metrics, not just binary up/down status, a responder returning slow or intermittently failing responses degrades client experience well before it counts as a full outage.

Database Health

Track database size and growth trend over time, a rapidly growing, unmaintained database is both a performance risk and, per our maintenance guidance, the leading cause of the handle-invalid timeout error during large dumps.
Log every occurrence of the 0x80070006 handle-invalid error specifically, treating recurrence as a signal worth investigating rather than a one-off nuisance.
Confirm backup completion status as its own tracked metric, distinct from the CA’s operational health, covered in our backup and disaster recovery guidance, a failed or silently skipped backup is invisible unless it’s explicitly monitored for.
Log every maintenance operation performed against the database, cleanup, compaction, and integrity checks, as part of your operational history, not just your change management records.

Suspicious Changes

Monitor the MSCEP registry key for the specific values covered in our NDES hardening guidance, correlated with Event ID 4657 (value changed) and 4670 (permissions changed), this remains one of the highest-signal, lowest-noise detection sources in the entire environment.
Alert on every CA-wide policy flag change, EDITF_ATTRIBUTESUBJECTALTNAME2 and similar settings, given how rare legitimate changes to these specific flags actually are.
Monitor certificate template ACLs for unexpected grants, WriteDACL, WriteOwner, or GenericAll appearing outside a documented change window, covered in depth in our ESC detection playbook.
Treat any reduction in the CA’s own AuditFilter setting (Event 4885) as a standing, high-priority alert, a legitimate reason to reduce a Tier 0 system’s own audit visibility is genuinely rare.

Building This Into a SIEM and Posture Management Program

Map each telemetry type to the right collection mechanism, Windows Event Forwarding or a SIEM agent for events, scheduled scripted checks for configuration-state metrics, synthetic retrieval tests for CRL/OCSP/AIA latency and reachability, native Azure Monitor integration if your publication points are cloud-hosted.
Build alerting thresholds from real baselines, not generic defaults, every metric in this guide only becomes actionable once you know what normal looks like for your specific environment’s volume and patterns.
Layer detection logic on top of this foundation, don’t try to build it directly on raw, uncollected data, the hunts in our threat hunting playbook and the checks in our ESC detection playbook both assume the telemetry cataloged here is already flowing.
Revisit this catalog as your environment changes, a new CRL partitioning deployment, a new OCSP array member, or a new Azure-hosted publication point each add new telemetry sources this guide’s categories already account for, but your specific instrumentation needs to be extended to cover them.

How Encryption Consulting Can Help

Building complete AD CS telemetry collection, across events, metrics, logs, and alerts, spanning every category in this guide, is foundational infrastructure work that’s easy to build partially and not notice the gaps until an incident or outage exposes them.

Encryption Consulting’s PKI Services team supports this directly:

Telemetry architecture design: building complete collection across every category in this guide, mapped to your actual SIEM platform and infrastructure.
Baseline establishment: determining realistic thresholds for your specific request volume, latency patterns, and configuration change frequency.
Gap assessment: reviewing your current monitoring against this full reference to identify exactly which categories are incompletely instrumented.
Detection logic layering, building the threat hunting and ESC detection playbooks on top of a properly collected telemetry foundation.
Ongoing posture management integration, keeping telemetry collection current as your CA hierarchy, publication infrastructure, and dependent services evolve.

If your AD CS telemetry doesn’t yet cover every category in this guide, our PKI Services team can build it out completely.

Conclusion

Good AD CS detection and response depend entirely on good collection, and collection is where most environments have quiet, unnoticed gaps. Build events, metrics, logs, and alerts across all eight categories here, CA events, service status, request latency, failures, CRL publication, OCSP, database health, and suspicious changes, before layering detection logic on top. This is the foundation the rest of our operational and security guidance assumes is already in place.

Want your AD CS telemetry built out completely across every category here? Talk to our PKI Services team. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What’s the difference between an AD CS event, metric, log, and alert? An event is a discrete occurrence, like a certificate being issued. A metric is a numeric measurement tracked over time, like request latency or database size. A log is the detailed record an event or metric gets written to, often needing correlation across multiple entries. An alert is a threshold-triggered notification built on top of one or more of the other three.

What is the single most useful telemetry source for AD CS overall health? Certificate request lifecycle events (4886, 4887, 4888, 4889) correlated by Request ID, since they cover issuance volume, failure patterns, and approval queue health all from one consistent data source, and connect directly to almost every other telemetry category in this guide.

Should CRL and OCSP health be monitored the same way? No. CRL health depends on publication success, timing, and reachability at every configured distribution point. OCSP health depends additionally on responder service state, array synchronization, and signing certificate expiration, a distinct set of failure modes that CRL monitoring alone won’t catch.

What telemetry indicates a suspicious configuration change rather than routine administration? Changes to the CA’s AuditFilter setting (Event ID 4885), CA-wide policy flags like EDITF_ATTRIBUTESUBJECTALTNAME2, unexpected template ACL modifications, and MSCEP registry changes correlated with an unplanned service restart all warrant investigation, since legitimate administration rarely touches these specific settings.

Is request latency really worth tracking for a CA? Yes. The time between a request being received and a final disposition, along with client-side retrieval latency for CRLs and OCSP responses, often surfaces developing problems, an overloaded CA, a failing HSM connection, a degrading network path, well before they become outright failures.