PKI Certificate Lifecycle: Enrollment, Renewal and Revocation

Most PKI writing stops at the moment a certificate is issued. That is the easy part. The hard part is everything after: a certificate has to be renewed before it expires, revoked when it should no longer be trusted, and watched the whole time, across thousands of devices that go offline, get wiped, change hands, and belong to people who eventually leave.

This post skips the "what is a PKI" material (the Intune PKI deep dive covers that) and follows one certificate through its whole life instead, then investigates the situations where the lifecycle goes wrong.

The Eight Stages

Enrollment. The device asks for a certificate, through a SCEP or PKCS profile in Intune. Nothing is trusted yet; this is just a request.

Issue. The CA checks the request against the certificate template and signs it. The template decides the maximum validity period and what the certificate may be used for.

Install. The certificate lands in the device's certificate store, with its private key ideally held by the TPM. From here on, the certificate's expiry date is fixed.

Use. The device presents the certificate to Wi-Fi, VPN or apps, and every one of those relying parties checks it independently: chain, purpose, validity and revocation.

Monitor. Someone (or something) watches for certificates nearing expiry, renewals that failed, and the health of the CRLs that relying parties depend on. This is the stage most organisations skip.

Renew. Before the certificate expires, the device gets a new one. In Intune this is driven by the renewal threshold, covered in detail below.

Revoke. If a certificate must stop being trusted before it expires (a retired device, a leaver, a compromise), the CA revokes it and publishes that fact.

Expire. Every certificate eventually reaches its end date and is rejected everywhere. That is by design. The goal is for expiry to happen only to certificates nobody needs any more.

Renewal Thresholds

Intune doesn't renew certificates on a schedule. Each SCEP and PKCS profile has a renewal threshold, a percentage of the certificate's lifetime. When the remaining lifetime falls below that percentage, the device requests a fresh certificate the next time it processes the profile.

The threshold is a trade-off:

• Too low and a device that is offline for a few weeks (long leave, a laptop in a drawer, a device in for repair) misses the whole window and expires.
• Too high and devices renew far more often than they need to, which multiplies CA load, CA database growth and the number of valid certificates per device in circulation.

One detail that catches people out: the template has the final say on validity. If the Intune profile asks for two years but the template's validity period is one year, the certificate is issued for one year, and the threshold is calculated against that.

Failed Renewal Scenarios

Renewal is just a new enrollment, so anything that breaks enrollment also breaks renewal. The difference is timing: an enrollment failure is noticed immediately, a renewal failure is noticed weeks later when the old certificate expires.

What Happens When a Certificate Expires?

At the exact moment of expiry, nothing happens on the device. The certificate is still in the store. What changes is that every relying party now rejects it:

• Wi-Fi: the RADIUS server rejects the authentication and the device falls off the network, usually noticed as "Wi-Fi stopped working this morning".
• VPN: the gateway rejects the connection; on Windows this often shows up as a certificate error from the VPN client.
• Apps: anything using the certificate for client authentication refuses the connection.

Recovery depends on why it expired. If the profile is still assigned and the device can reach Intune, the next time it processes the profile it requests a new certificate, and service returns on its own. If the device can only reach Intune through the network that now rejects it, someone has to give it another route first.

An expired CA certificate is a different order of problem: every certificate it issued becomes untrustworthy at once, because the chain can no longer be validated. CA certificates should be renewed long before they expire, which is why the deep dive recommends long CA lifetimes with deliberate renewal planning.

What Happens When a Device Is Deleted?

There are three different "goodbyes" a device can get in Intune, and they don't do the same thing to its certificates:

The risk is the third row. A device that is simply deleted from the portal, without being retired or wiped first, may keep its still-valid certificate and still-valid key. If that device is lost, sold or stolen, it can keep authenticating to Wi-Fi and VPN until the certificate expires, unless the certificate is revoked separately.

Intune's exact revocation behaviour varies by platform, by SCEP vs PKCS, and over time as the service changes, so check Microsoft's current documentation for the matrix that applies to you. The operational rule above holds regardless.

What Happens When the User Leaves?

Disabling a user's account feels like it should end everything. For certificates, it doesn't:

• Disabling the account doesn't revoke certificates. A user certificate stays mathematically valid until it expires or is revoked.
• Device certificates aren't tied to the user at all. A leaver's laptop still has a perfectly valid device certificate, and it will join the corporate Wi-Fi from the car park if nobody retires the device.
• Some relying parties will notice, some won't. NPS maps a certificate to an Active Directory account and refuses disabled accounts. A gateway or cloud RADIUS service that only checks the certificate itself will accept it until it is revoked.

A leaver process that includes certificates:

How Revocation Actually Works

Revoking a certificate is two separate events, and the gap between them is where the risk lives:

So the real time to revocation is roughly CRL publication interval plus the relying party's cache lifetime. With a weekly base CRL and no delta CRLs, a revoked certificate can keep working for about a week.

CRL vs OCSP

OCSP isn't magic: an AD CS Online Responder builds its answers from the CA's CRLs, so it is only as current as the CA's latest publication. Its real advantages are smaller requests and better scaling for large revocation lists.

For most Intune estates, well-run CRLs with delta CRLs are enough. Add OCSP when your relying parties support it and you have large numbers of revoked certificates. Either way, the HTTP locations (CDP for CRLs, AIA for OCSP) must be reachable from wherever your RADIUS servers and VPN gateways run, including cloud-hosted ones.

Certificate Monitoring

Every outage in this post is predictable. Certificates and CRLs have expiry dates written into them; you can see the problem weeks in advance if you look.

A simple CRL check you can schedule against each CDP URL:

$url  = "http://pki.contoso.com/CertEnroll/Contoso%20Lab%20Root%20CA.crl"
$file = "$env:TEMP\check.crl"
Invoke-WebRequest -Uri $url -OutFile $file -UseBasicParsing
certutil -dump $file | Select-String "NextUpdate"

Alert when the Next Update date is less than a few days away and no newer CRL has been published. For automating checks like this across many endpoints and reports, the patterns in building production-ready endpoint scripts apply directly.

Summary

A certificate's life has eight stages, and the dangerous ones come after issuance: renewal that silently fails, revocation that is slower than people assume, devices deleted without being retired, and leavers whose certificates outlive their accounts. Every one of those is predictable and preventable:

• Renewal: a threshold sized to your longest normal device absence, and redundant NDES and connectors so renewals never depend on one server.
• Offboarding: retire or wipe before delete, every time, and a leaver process that confirms revocation instead of assuming it.
• Revocation: delta CRLs, so revocation takes effect in hours or a day, not a week.
• Monitoring: watch certificate expiry, connector health and CRL Next Update dates, so expiry only ever happens to certificates nobody needs.

To see where each stage is configured, the implementation lab builds the full chain step by step.