NDES Monitoring: Events, Certificates, Availability, and Security Signals

An expired RA certificate doesn’t send an alert, it just quietly breaks enrollment for every device that tries afterward, all at once. A suspicious certificate request doesn’t look different from a legitimate one in a basic uptime check, it only shows up if you’re actually comparing who requested it against what it claims to be. NDES needs its own monitoring layer, distinct from general server health checks, because its failure and compromise patterns are genuinely its own. This is a complete reference for what that layer should actually cover.

This is the operational monitoring companion to our Microsoft NDES Hardening Guide and Common Intune and NDES Misconfigurations and How to Fix Them, and extends the posture-management argument from our continuous ADCS risk assessment guidance specifically to this one, high-consequence server.

TL;DR: Key Takeaways

NDES fails silently in ways general server monitoring won’t catch: an RA certificate expiring or autoenrollment quietly failing looks identical to normal operation right up until enrollment starts failing across your entire device fleet.
Certificate expiry monitoring needs to be explicit, not assumed: both RA certificates typically rely on autoenrollment, and autoenrollment failing silently is functionally the same outcome as the certificate actually expiring, track expiration directly rather than trusting the renewal process implicitly.
Security-relevant signals require correlation, not just log collection: a Requester-versus-Subject mismatch, the core detection pattern for certificate-based privilege escalation, only becomes visible when you’re actively comparing fields, not simply retaining the raw events.
Connector health is a distinct monitoring domain for Intune-driven deployments: the Intune Certificate Connector has its own service state, version currency, and issuance success rate, separate from NDES’s own health, and a gap in one can mask a problem in the other if they aren’t monitored independently.
Baseline first, then alert on deviation, most of what’s covered here only works if you know what normal looks like for your specific environment before you start flagging anomalies.

Why NDES Needs Its Own Monitoring Layer

Its availability failure mode is unusually consequential: NDES typically serves an entire device fleet’s certificate lifecycle, when it fails, the impact isn’t one user or one server, it’s every device attempting enrollment or renewal during the outage window.
Its security failure mode is unusually severe: compromise of its RA certificate’s private key, covered in depth in our hardening guide, enables certificate-based impersonation of essentially any identity, a risk category most general-purpose servers simply don’t carry.
Standard uptime and performance monitoring misses both, a server can report perfectly healthy CPU, memory, and response time metrics while its RA certificate has silently expired or while it’s actively serving fraudulent certificate requests.

IIS Telemetry

Log both the mscep and mscep_admin applications separately, they serve different purposes, client enrollment versus challenge password generation, and their normal traffic patterns and failure modes differ meaningfully enough to warrant distinct baselines.
Baseline response code distribution and alert on deviation, a spike in 403 responses commonly indicates a permission or authentication problem, a spike in 500 responses points toward a backend issue, frequently CA connectivity, both are worth catching proactively rather than only after enrollment failures are reported.
Track request volume against your actual expected baseline, a sudden spike or an unexpected drop in enrollment request volume are both worth investigating, one can indicate abuse, the other can indicate a broken dependency upstream of NDES itself.
Capture client IP and user agent information in your logs, useful both for legitimate troubleshooting and as an input to the suspicious enrollment detection covered further below.

NDES Service and Availability

Monitor the SCEP application pool and underlying service state directly, not just whether the server itself responds to a generic ping or basic health check, the application pool can be stopped or crashed while the underlying OS reports fully healthy.
Track application pool recycle frequency and correlate unexpected recycles with configuration changes, an unplanned recycle shortly after a flagged MSCEP registry change, covered in our hardening guide, is a corroborating signal worth investigating together rather than in isolation.
Run a synthetic test enrollment on a schedule, an actual, low-risk end-to-end enrollment test catches failures that a simple service-state check can miss, confirming the full pipeline, IIS, the RA certificate, and the backend CA, all still work together correctly.

RA Certificate Expiry

Track both RA certificates explicitly, don’t rely on autoenrollment succeeding silently: the CEP Encryption certificate and the Exchange Enrollment Agent (Offline Request) certificate both typically renew through autoenrollment, but a quietly failed autoenrollment cycle looks identical to a healthy one until the certificate actually expires.
Alert well ahead of expiration, not just at expiration, a 30 to 60 day advance warning gives your team time to investigate and manually intervene if autoenrollment genuinely failed, rather than discovering the problem only once enrollment has already stopped working.
Understand the blast radius if this monitoring is skipped, RA certificate expiration doesn’t degrade NDES gracefully, it stops the entire enrollment pipeline for every device attempting to enroll or renew, all at once, this is one of the highest-consequence, most preventable outages in a typical AD CS environment.

Request Failures

Correlate NDES-originated requests against the event ID patterns covered in our event ID 4886-4889 reference, applying the same received/issued/denied/pending lifecycle tracking specifically to the template NDES enrolls against.
Categorize failure reasons rather than tracking a single generic failure count, an expired or already-used challenge password, a template permission mismatch, and CA unreachability are three genuinely different problems requiring different responses, lumping them into one metric obscures which one you’re actually dealing with.
Track failure rate trend over time, not just an absolute daily count, a slowly climbing failure rate can indicate a developing problem, a certificate approaching expiration, a connectivity issue worsening, well before it becomes a full outage.

Suspicious Enrollment Signals

Apply the Requester-versus-Subject/SAN correlation to every NDES-originated request, the same core detection pattern covered throughout our broader event ID and attack path guidance, a mismatch here is one of the most reliable indicators of certificate-based privilege escalation attempts.
Watch for enrollment volume spikes from a single source, an unusual concentration of requests from one IP address or one account is worth investigating regardless of whether any individual request looks superficially valid.
Flag enrollment against templates outside your normal NDES workflow, if NDES is configured to serve a specific, limited set of templates, any request against a template outside that expected set deserves scrutiny.
Watch specifically for signals consistent with authentication bypass, a pattern of successful enrollments that don’t correlate cleanly with a valid challenge password lifecycle is worth investigating as a potential sign of the EnforcePassword tampering covered in our misconfiguration list, not dismissed as a logging gap.

Connector Health (Intune Certificate Connector)

Monitor the connector’s own service state independently from NDES’s health, a healthy NDES server behind an unhealthy or stopped connector still results in failed device enrollment, monitoring only one side of this pipeline leaves a real blind spot.
Track the connector’s last check-in or heartbeat status, visible in the Intune admin center, a connector that’s stopped checking in is a distinct failure mode from one that’s running but failing to issue certificates successfully.
Track installed connector version against current releases, an outdated connector can silently lack strong mapping support or issuance fixes, covered in our misconfiguration list, version drift here is easy to miss without explicit tracking.
Track issuance success and failure rate through the connector specifically, separate from failures occurring elsewhere in the broader NDES request pipeline, this distinction matters for correctly diagnosing where an enrollment problem actually originates.

Building This Into Posture Management

Establish real baselines before setting alert thresholds, every signal covered here is only useful relative to what’s normal for your specific environment’s volume and patterns, a threshold copied from generic guidance without adjustment produces either alert fatigue or missed detections.
Assign clear ownership for each monitoring domain, IIS telemetry, certificate expiry, and connector health may reasonably sit with different teams, make sure each signal actually has someone responsible for reviewing and acting on it.
Periodically validate the monitoring itself, not just the underlying system, a synthetic test enrollment that stops running silently is just as dangerous as the outage it was meant to catch, treat your monitoring pipeline with the same validation discipline as the infrastructure it watches.
Fold NDES monitoring into your broader continuous PKI risk assessment practice, rather than treating it as an isolated dashboard, the same drift and staleness risks covered in our continuous risk assessment guidance apply directly to monitoring infrastructure itself.

How Encryption Consulting Can Help

Building monitoring that actually catches an expiring RA certificate before it causes an outage, or a suspicious enrollment pattern before it becomes a compromise, requires knowing exactly which signals matter for this specific piece of infrastructure, not a generic server monitoring template.

Encryption Consulting’s PKI Services team supports this directly:

NDES monitoring design: building the IIS, service, certificate expiry, and connector health monitoring covered here, tailored to your actual environment and tooling.
Detection logic implementation: turning the Requester-versus-identity correlation and other suspicious enrollment signals into working alerts in your SIEM.
Baseline establishment: helping you determine realistic thresholds for your specific enrollment volume and patterns, rather than relying on generic defaults.
Connector health integration, correlating Intune Certificate Connector status with NDES’s own health so gaps in either don’t hide behind the other looking fine.
Ongoing posture management, integrating NDES monitoring into your broader continuous PKI risk assessment practice rather than leaving it as a standalone, easily neglected dashboard.

If your NDES environment doesn’t have monitoring covering all of this today, our PKI Services team can design and build it.

Conclusion

NDES monitoring done well covers four genuinely distinct domains: IIS-level operational telemetry, service and RA certificate availability, request failure and suspicious enrollment security signals, and, for Intune-driven deployments, connector health as its own separate concern. Build real baselines for each, alert on deviation rather than absolute thresholds copied from generic guidance, and validate the monitoring itself periodically, since a silently broken alert is no better than no alert at all. This is exactly the kind of continuous visibility that turns NDES from a black box you hope is working into infrastructure you can actually trust.

Want NDES monitoring that actually catches problems before they become outages or incidents? Talk to our PKI Services team about designing it. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Why does NDES need monitoring separate from general server monitoring? Because its failure modes are distinct: an expired RA certificate silently breaks enrollment for an entire device fleet at once, and its security-relevant events, like a Requester and Subject mismatch, don’t appear in generic server health checks at all. General uptime monitoring alone misses both.

What are the two RA certificates on an NDES server that need expiration monitoring? The CEP Encryption certificate and the Exchange Enrollment Agent (Offline Request) certificate. Both are typically set up for autoenrollment, but autoenrollment failing silently and the certificate actually expiring look identical from the outside until enrollment starts failing, explicit expiration tracking closes that gap.

What IIS response code pattern on NDES is worth alerting on? A spike in 403 responses on mscep or mscep_admin often indicates a permission or authentication problem, while a spike in 500 responses points toward a backend issue, commonly CA connectivity. Both are worth baselining and alerting on deviation, rather than only investigating after enrollment failures are reported.

How do you detect suspicious certificate requests through NDES specifically? Correlate the Requester field against the Subject and SAN content in certificate request events, a mismatch between who submitted the request and the identity it represents is a documented pattern associated with certificate-based privilege escalation. Also watch for volume spikes from a single source and enrollment attempts against templates that aren’t part of your normal NDES workflow.

What Intune Certificate Connector health signals should be monitored? The connector’s service state, its last check-in or heartbeat status visible in the Intune admin center, its installed version against current releases, and its certificate issuance success and failure rate specifically, distinct from failures occurring elsewhere in the NDES request pipeline.