Microsoft ADCS Event IDs 4886-4889 Explained

Four event IDs cover the entire lifecycle of a certificate request against a Microsoft CA: received, issued, denied, and set to pending. Individually they’re simple. Correlated correctly, across the same Request ID and against what the certificate was actually used for afterward, they’re one of the most useful detection surfaces AD CS gives you for free. This is a complete, standalone reference for events 4886 through 4889: meaning, fields, what’s normal, what’s suspicious, and how to actually build detection logic around them.

For the broader attack patterns these events help detect, see ADCS Attack Path Visualization for Defenders.

TL;DR: Key Takeaways

These four events cover the complete request lifecycle: 4886 (received), 4887 (approved and issued), 4888 (denied by CA policy), and 4889 (set to pending, awaiting manager approval).
The Request ID is the correlation key across all of them: every event tied to the same certificate request shares this value, which is how you reconstruct what actually happened to a specific request across multiple log entries.
4888 is not the same event as 4868: 4888 is the CA itself denying a request based on policy, 4868 is a human certificate manager denying a pending request through the console, both can appear for the same denial.
A mismatch between Requester and the Subject/SAN in the Attributes field is a genuine, well-documented detection signal, associated with real certificate template privilege escalation techniques, not a theoretical concern.
Both of two separate audit settings have to be enabled together for these events to appear at all, missing either one is the most common reason organizations discover they have no certificate request logging when they actually need it.

Prerequisite: Enabling These Events

Enable “Issue and manage certificate requests” on the CA’s Audit tab, found in the Certificate Services MMC snap-in’s CA properties, this is a CA-level setting distinct from Windows’ own audit policy.
Enable the Certification Services audit subcategory through auditpol, using AuditPol.exe /get /subcategory:"Certification Services" to check current status and the corresponding /set command to enable it if it isn’t already.
Both settings are required together, not either one alone, this is the most common reason organizations look for these events during an incident and find nothing logged, one of the two prerequisites was enabled and the other wasn’t.

Event ID 4886: Certificate Services Received a Certificate Request

What it means: logged the moment a certificate request arrives at the CA, before any decision has been made about issuing, denying, or queuing it for approval.
Key fields: Request ID (the correlation key for everything that happens to this request afterward), Requester (the account that submitted the request), and Attributes (the raw request attributes, including the certificate template and subject information supplied in the request).
Normal pattern: a 4886 followed shortly by either a 4887 (auto-approved and issued) or a 4889 (queued pending manager approval) for the same Request ID, from a requester and template combination consistent with expected enrollment activity.

Event ID 4887: Certificate Services Approved a Certificate Request and Issued a Certificate

What it means: the CA approved the request, based on its own policy and the associated certificate template’s configuration, and issued the certificate.
Key fields: the same Request ID from the corresponding 4886, Requester, and Attributes, giving you the full picture of what was actually issued and to whom when read alongside the originating 4886 entry.
Normal pattern: issuance against a template the requester has legitimate enrollment permissions for, with Subject and SAN values in the Attributes field that correspond to the requester’s own identity, not someone else’s.

Event ID 4888: Certificate Services Denied a Certificate Request

What it means: the Certification Authority itself denied the request based on policy, distinct from a human certificate manager denial, which is logged separately as event 4868. It’s possible to see both for the same request, sometimes with 4888 logged twice around a 4868 entry in between.
Key fields: Request ID, Requester, Attributes, plus a Disposition value (a numeric status code indicating the reason for denial), an SKI (Subject Key Identifier), and the Subject the request attempted to use.
Normal pattern: occasional denials tied to legitimate policy enforcement, an expired enrollment agent certificate, a template permission mismatch, or a malformed request. A denial rate spike concentrated on one requester or one template is worth investigating rather than assuming routine noise.

Event ID 4889: Certificate Services Set the Status of a Certificate Request to Pending

What it means: the request was queued for manager approval rather than being automatically approved or denied, this only happens for templates explicitly configured to require CA manager approval.
Key fields: the same Request ID, Requester, and Attributes fields carried through from the corresponding 4886 entry.
What happens next: a 4889 entry should eventually be followed by either a 4887 (a manager approved and issued it) or a 4868 (a manager denied it), a 4889 with no corresponding follow-up event is worth investigating as a request that may still be sitting unreviewed.

Important Fields Across All Four Events

Request ID: the single field that ties every event related to one specific certificate request together, this is your primary correlation key for reconstructing a request’s full lifecycle.
Requester: the account that actually submitted the request, this is the identity you compare against the Subject and SAN content to detect a mismatch.
Attributes: the raw request attributes, including the certificate template name and subject information, on Windows Server 2025 with enhanced audit logging enabled, this field carries meaningfully richer data, including SAN values, client OS, cryptographic service provider, and authentication type, covered in our roundup of 2025-2026 AD CS changes.
Disposition (on denial events): a numeric status code indicating how the request was processed, useful for distinguishing routine policy denials from more unusual failure patterns when correlated across many events.
SKI and Subject (on 4888): the Subject Key Identifier and the subject the denied request attempted to use, useful context for understanding exactly what was being requested when the denial occurred.

Normal vs. Suspicious Patterns

Normal: a clean 4886 → 4887 (or 4886 → 4889 → 4887/4868) sequence, from a requester with legitimate permissions against a template it’s authorized to use, with Subject and SAN content matching the requester’s own identity.
Suspicious: Subject or SAN content that doesn’t match the Requester’s own account, a request submitted by one account that identifies a different, potentially more privileged account in its subject or SAN is a documented pattern associated with certain certificate template privilege escalation techniques, not routine variance.
Suspicious: a concentrated denial pattern from one requester, repeated 4888 entries tied to the same account in a short window can indicate probing, an account attempting requests it doesn’t have permission for, testing which templates and configurations might succeed.
Suspicious: issuance shortly after a template or CA configuration change, a 4887 issuance closely following a 4891 (configuration entry changed) or 4898 (template loaded) event is worth a closer look, especially if the requester or template combination is unusual for your environment.
Suspicious: a 4889 with no follow-up event, a pending request that never resolves to either issuance or denial may represent an approval queue nobody’s actually reviewing, itself a process gap worth addressing independent of any specific security concern.

Correlation With Other Events

Correlate across the Request ID first, always, before drawing any conclusion about a specific request, pull every event sharing that Request ID to see the complete sequence rather than reacting to a single entry in isolation.
Correlate issuance forward to actual authentication use, a 4887 confirms a certificate was issued, a subsequent Event 4768 (Kerberos TGT request) with the PreAuthType field set to 16 on a domain controller confirms that certificate was actually used for certificate-based authentication, connecting issuance to real-world use rather than treating issuance alone as the endpoint of your investigation.
Correlate against configuration and template change events, 4890 through 4898 cover CA configuration changes, key archival, and template loading, a suspicious issuance pattern that follows one of these events closely in time deserves more scrutiny than one occurring in an otherwise stable configuration window.
Correlate against Active Directory object changes on PKI containers, covered in more depth in our attack path guide, since a directory-level permission change on a template can enable a subsequent issuance pattern that looks perfectly normal at the CA event level alone.

Sample Detection Logic

Flag Subject/SAN-to-Requester mismatches, for every 4886, 4887, and 4889 event, extract the Requester field and compare it against any Common Name, email address, or SAN entry present in the Attributes field, flag any case where they don’t correspond to the same identity.
Flag denial rate spikes per requester, track 4888 (and correlated 4868) counts per Requester over a rolling window, and alert when one account’s denial count crosses a threshold meaningfully above your environment’s normal baseline.
Flag issuance against recently modified templates, maintain a short list of templates that have had a configuration change (via 4891/4898) within a trailing window, and flag 4887 issuance events against any template on that list for closer review.
Flag stalled pending requests, track 4889 events that haven’t been matched with a corresponding 4887 or 4868 within an expected timeframe, surfacing them as an operational gap rather than letting them sit unreviewed indefinitely.

Troubleshooting

No events appearing at all: check both audit prerequisites, confirm “Issue and manage certificate requests” is enabled on the CA’s Audit tab and that auditpol confirms the Certification Services subcategory is actually enabled, both together, not just one.
Gaps in the Request ID sequence for a specific investigation, confirm you’re searching the correct log (these are Security log events) and that log retention or size limits haven’t rolled the earlier portion of the sequence off before you went looking for it.
Reconstructing a failed enrollment for root-cause troubleshooting, pull every event sharing the Request ID in question, the sequence itself, received, pending or denied, tells you exactly where in the process the request stopped and why, faster than reasoning from a single event in isolation.
Event log sizing on high-volume CAs, a CA processing a large enrollment volume generates a correspondingly large number of these events, confirm your Security log size and retention settings are sized for your actual request volume, not a default that was fine for a much smaller CA years ago.

How Encryption Consulting Can Help

Turning these four event IDs into genuine, working detection logic, correctly correlated across Request IDs and against actual certificate use, takes both AD CS domain knowledge and real SIEM or log analytics engineering, and getting the correlation wrong produces either alert fatigue or missed detections.

Encryption Consulting’s PKI Services team supports this directly:

Audit configuration review: confirming both prerequisite settings are correctly enabled across every CA in your hierarchy, not just the one you’re actively investigating.
Detection logic design: building Subject/SAN mismatch detection, denial-rate monitoring, and template-change correlation tailored to your actual environment and SIEM platform.
Incident investigation support: reconstructing certificate request lifecycles from these events during an active investigation, correlated against configuration changes and downstream authentication activity.
Log sizing and retention guidance, so high-volume CAs don’t silently lose historical event data before an investigation needs it.
Ongoing monitoring design, integrating this detection logic into your broader continuous PKI risk assessment practice.

If you want real detection logic built around these events rather than raw log data nobody’s actively correlating, our PKI Services team can build it with you.

Conclusion

Events 4886 through 4889 give you the complete lifecycle of every certificate request your CA processes, received, issued, denied, or queued for approval, correlated by Request ID. On their own they’re a useful audit trail. Correlated against the Requester’s own identity, against configuration change events, and against downstream authentication activity, they’re a genuine detection capability most environments already have available and aren’t fully using. Enable both audit prerequisites, build correlation around Request ID and identity mismatches, and treat a stalled pending request as seriously as an outright denial.

Want real detection logic built around your CA’s request lifecycle events? Talk to our PKI Services team about designing it for your environment. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What is the difference between Event ID 4888 and Event ID 4868? Event ID 4888 is logged when the Certification Authority itself denies a request based on policy. Event ID 4868 is logged when a human certificate manager denies a pending request through the console. Both can appear for the same denied request, and 4888 is sometimes logged twice with 4868 in between.

Why aren’t events 4886 through 4889 appearing in the Security log at all? These events require two separate settings enabled together: “Issue and manage certificate requests” on the CA’s Audit tab, and the Certification Services audit subcategory enabled through auditpol. Missing either one means these events simply won’t be logged, regardless of the other setting.

What field connects events 4886, 4887, 4888, and 4889 for the same certificate request? The Request ID. Every event tied to a specific certificate request shares the same Request ID value, which is how you reconstruct the full lifecycle of a request, submission, pending status, and final disposition, across multiple log entries.

What’s a reliable way to detect certificate template abuse using these events? Compare the Requester field against the Subject and SAN values contained in the Attributes field of events 4886, 4887, and 4889. A requester submitting a request whose subject or SAN identifies a different account, especially a more privileged one, is a known pattern associated with certificate template privilege escalation techniques.

Can a certificate issuance event be correlated with its actual use for authentication? Yes. Event 4887 confirms issuance, and a subsequent Event 4768 (Kerberos ticket request) with PreAuthType set to 16 on a domain controller confirms that the issued certificate was actually used for certificate-based authentication, letting you connect issuance to real-world use.