Certificate deployment projects get all the attention; certificate renewal gets an incident review. The failure pattern is depressingly consistent: everything works for one or two years, then devices start dropping off Wi-Fi in ones and twos — usually the devices that were in a drawer, on a shelf in a warehouse, or with a user on long leave. This guide explains how Intune renewal actually behaves, the traps built into it, and how to see problems coming instead of discovering them through help-desk tickets.
How renewal works
Intune SCEP and PKCS profiles include a renewal threshold, expressed as a percentage of the certificate's lifetime. When the remaining lifetime drops below that threshold, the device becomes eligible to renew, and on a subsequent check-in it requests a new certificate. For SCEP this is a full re-enrolment: a new key pair, a new CSR, a new certificate — the old one isn't extended, it's replaced. Once the replacement is in place, connections use the new certificate and the old one ages out harmlessly.
Three properties of this design create every pitfall that follows:
- Renewal is device-initiated and requires check-in. No check-in, no renewal. Intune cannot push a certificate to a device that isn't talking to it.
- The renewal window is a fraction of lifetime, not a fixed period. A 20% threshold on a two-year certificate is roughly 146 days; the same threshold on a one-year certificate is 73 days; on a 90-day certificate it's 18 days. Shorten the certificate and you shorten the safety margin proportionally, unless you raise the threshold.
- The whole issuance pipeline must be healthy at renewal time. The SCEP endpoint, the CA, the connector if you have one — an outage in any of them doesn't fail loudly; it just means renewals quietly don't happen while the clock runs.
Pitfall 1: the offline-device death spiral
The classic. A laptop is put in a cupboard in March. Its Wi-Fi certificate enters the renewal window in April and expires in June. In September someone pulls it out for a new starter — and it can't join the Wi-Fi, because its certificate is expired, and it can't renew the certificate, because renewal requires checking in with Intune, which requires connectivity, which required the certificate. The device is stuck in a loop that only a manual intervention breaks.
Mitigations, roughly in order of value:
- Size the renewal window against your real offline patterns. If devices routinely go dark for a school summer holiday, a factory shutdown, or parental leave, the renewal window must be longer than the longest plausible gap. With a two-year certificate and a 30–40% threshold, you get a window measured in many months.
- Keep a bootstrap path onto the network. A wired connection that doesn't require 802.1X for known MDM traffic, a dedicated onboarding SSID, or simply documented guidance that a device on any internet connection (home Wi-Fi, hotspot) can check in and renew — because Intune check-in only needs internet, not corporate network. This last point is the saving grace: an expired Wi-Fi certificate strands the device on corporate Wi-Fi only. Make sure support staff know that "connect it to a hotspot and sync" is the fix, not re-enrolment.
- Don't let certificate lifetime and device refresh cycles interact badly. Devices due for replacement soon after their certificate expiry date are the ones nobody prioritises — until they're reissued to someone else.
Pitfall 2: what "expired" actually breaks
An expired client certificate doesn't damage the device; it just stops authenticating. But the blast radius depends on what else depended on that connectivity:
- On corporate Wi-Fi with EAP-TLS, the device falls off the network — and if it has no other route to the internet, it also stops syncing with Intune, receiving policy, and reporting inventory. From the admin console it just goes stale, which is easy to misread as a lost or dormant device rather than a certificate problem.
- For Always On VPN device tunnels, the tunnel stops establishing, which on some configurations breaks the very connectivity used for domain and management traffic.
- Some RADIUS deployments also perform revocation checks; an expired certificate fails before revocation even enters the picture, but the diagnostic path looks similar, and both surface to the user as generic "can't connect".
The pattern to internalise: certificate expiry rarely announces itself as certificate expiry. It announces itself as devices going quiet.
Pitfall 3: trusting deployment status instead of certificate state
Intune's profile deployment status tells you the profile applied successfully — past tense, possibly long ago. It does not tell you the certificate currently on the device is valid, unexpired, or successfully renewed. A device can show a compliant, successfully-deployed SCEP profile while holding a certificate that expires on Friday because renewals have been failing for a month.
Monitor certificate state, not deployment state. The Intune admin centre exposes an inventory of certificates issued via its profiles, including expiry dates — review it on a schedule, sorted by soonest expiry. Whatever your issuing CA is (ADCS, Cloud PKI, a third-party service), it has its own view of issued and expiring certificates; the CA-side view catches things the MDM-side view misses, such as issuance volume dropping to zero, which is your earliest signal that the renewal pipeline itself is broken. If you have log tooling, a simple weekly count of certificates issued is one of the highest-value, lowest-effort monitors in this whole space: healthy fleets renew continuously, so a flat line means trouble.
Pitfall 4: renewal-time changes behaving like new deployments
Because SCEP renewal is re-enrolment, any change you've made to the profile since original issuance takes effect at renewal — new SAN configuration, different key size, changed validity. Usually that's what you want. Occasionally it isn't: a profile edit made for new devices reaches your existing fleet gradually over the following renewal cycle, so an error in it also rolls out gradually, evading the "we changed something and everything broke at once" detection heuristic. Treat SCEP profile edits with the same care as new deployments, and decode a freshly issued certificate after any change to confirm it contains what you intended.
Also remember that renewal produces a new key and new certificate, so anything that pinned the old certificate — a hand-configured system mapping specific thumbprints, an allowlist on a NAC — breaks silently at each device's individual renewal moment. Standard EAP-TLS validating chain and identity is immune; bespoke thumbprint-based integrations are not.
Pitfall 5: the infrastructure certificates you forgot
Device certificates renew automatically; the certificates around them often don't:
- The RADIUS server's own certificate expires on its own schedule, and when it does, every client fails at once — a much worse day than gradual client expiry.
- Issuing CA and root CA certificates have their own lifetimes. A CA cannot issue certificates that outlive it, so as a CA certificate approaches expiry, issued lifetimes silently compress, dragging renewal windows in with them.
- NDES/registration authority certificates and connector certificates in on-prem setups expire and stop issuance entirely — usually discovered via a wave of failed enrolments.
Put every one of these in a calendar with reminders at 90 and 30 days. It's not sophisticated, but it's the control that actually prevents the worst incidents in this list.
A sane baseline
If you're setting this up fresh: pick a one- or two-year client certificate lifetime, set the renewal threshold so the window comfortably exceeds your longest realistic offline period (20% is a common floor; go higher for fleets with long idle patterns), make sure support knows the hotspot-and-sync recovery path, review the certificate expiry report monthly, watch issuance volume weekly, and calendar the infrastructure certificate dates. None of it is difficult — the difficulty is only in believing, during the deployment project, that the renewal problem is real. It is. It's just scheduled for later.