APNs certificate expired past the grace window: when it means a physical wipe of every phone
If the Apple MDM push (APNs) certificate in your Intune tenant has expired, the blast radius depends on one thing: whether your enrolment profiles are user-removable. Here is how to work out which situation you are in, what can still be recovered, and the renewal pattern that stops it ever happening again.
The problem
Every Apple device managed by Intune depends on a single tenant-wide certificate: the Apple MDM push certificate (APNs). It is valid for 365 days. When it lapses, every iPhone, iPad and Mac in the tenant stops responding to management at once. As one administrator put it on Apple Support Communities, "all connected devices lose connection to Intune… even after creating a new certificate."
The symptoms are easy to misread as something else: devices show stale check-in times, policy changes never land, remote lock and wipe commands sit queued indefinitely, and app deployments stall. Users often notice nothing at first, so the expiry is frequently discovered days or weeks late — which matters, because Microsoft documents only a 30-day grace period after expiry in which the situation is still recoverable without touching devices.
Past that window, the outcome splits by enrolment profile type:
| Profile type | Typical enrolment | Recovery after the certificate is unrecoverable |
|---|---|---|
| User-removable management profile | User-driven Company Portal enrolment (BYOD or corporate) | User removes the management profile in Settings and re-enrols via Company Portal. Disruptive but self-service. |
| Non-removable management profile | Automated Device Enrollment (ADE, formerly DEP) with a locked profile | The profile cannot be removed by the user or by MDM (the MDM channel is dead). The device must be erased and re-provisioned through Setup Assistant. |
Community guidance on a certificate that had been expired for 30 days is blunt: "If your MDM profile is not user removable, you will need to completely wipe and reset the devices." For a locked-down corporate fleet on ADE profiles, that is a hands-on-every-device event — collecting, wiping and re-running Setup Assistant on every phone.
Why it happens
The APNs MDM push certificate is not just a transport credential — the device's enrolment is cryptographically bound to it. When a device enrols, its management profile is tied to the certificate's topic (a UID derived from the certificate). This has three consequences:
- Renewing keeps the topic; creating anew changes it. A renewed certificate keeps the same topic, so existing devices carry on as if nothing happened. A new certificate has a different topic, and devices enrolled under the old one will never talk to it. This is why "just make a new certificate" does not reconnect anything — a point that trips up many admins in the community threads.
- Renewal requires the original Apple ID. The certificate can only be renewed in the Apple Push Certificates Portal by signing in with the same Apple ID that created it. If that was a departed admin's personal Apple ID, renewal may be impossible even though the certificate is technically still renewable.
- An expired certificate gets a documented 30-day grace period. Microsoft's documentation is explicit: "Once the certificate expires, there is a 30-day grace period to renew it." Within those 30 days the certificate can still be renewed with its topic preserved, and devices reconnect. Past day 30, only a new certificate — and therefore fleet-wide re-enrolment — is possible. The community case of a certificate expired for 30 days shows what the far side of that window looks like: for non-removable profiles, the advice was a complete wipe and reset.
The decay timeline after expiry
- Day 0: APNs pushes stop. Intune can no longer wake devices; remote actions (lock, wipe, sync) queue and never execute. Devices keep running their last-applied policies.
- Days 1–30: Check-ins go stale. Compliance status ages towards the tenant's compliance status validity period (30 days by default in Intune). App and policy updates do not deploy.
- Around day 30: Devices whose compliance status has lapsed are marked non-compliant. If you use Conditional Access, users start losing access to email and corporate resources — often the first moment anyone notices.
- Day 30 — the documented grace period ends: the certificate can no longer be renewed. Every device must be re-enrolled — self-service for user-removable profiles, erase-and-rebuild for non-removable ADE profiles.
The fix
Work through this triage in order — the earlier steps are dramatically cheaper than the later ones.
1. Establish where you are
In the Intune admin centre, go to Devices → Device onboarding → Enrollment, open the Apple tab and select Apple MDM Push Certificate. Note the expiry date and the Apple ID shown against the certificate. Confirm you can actually sign in to identity.apple.com with that Apple ID today — an inaccessible Apple ID is the same emergency as an expired certificate, just on a delay.
2. Certificate still valid: renew it now, correctly
- In Intune, download the certificate signing request (CSR).
- Sign in to the Apple Push Certificates Portal with the same Apple ID that created the certificate.
- Choose Renew against the existing certificate — never Create a Certificate. Creating a new one changes the topic and orphans every enrolled device.
- Upload the renewed
.pemback into Intune.
Devices are unaffected; they reconnect on their next push.
3. Expired within the last 30 days: renew inside the grace period
Expiry is not immediately terminal — Microsoft documents a 30-day grace period after expiry in which the certificate can still be renewed. Renew it exactly as above; because the topic is preserved, devices reconnect once the renewed certificate is uploaded to Intune. Treat this as a same-day action all the same: every day that passes consumes the fixed 30-day window, and at day 30 the only remaining option is re-enrolment.
4. Expired past the grace period (or the Apple ID is lost): plan the re-enrolment
There is no technical undo. Create a new certificate, then split the fleet:
- User-removable profiles: instruct users to remove the management profile (Settings → General → VPN & Device Management) and re-enrol via Company Portal. Communicate in waves so the helpdesk is not swamped.
- Non-removable ADE profiles: each device must be erased and re-provisioned through Setup Assistant. Schedule it like the logistics exercise it is: confirm what data lives only on-device, prioritise executives and frontline-critical devices, and stage loaner devices if you have them. Devices assigned in Apple Business Manager will pick up the enrolment profile again during Setup Assistant.
5. Make the renewal impossible to miss silently
Prevention is the only real answer here, and it must not depend on one person's memory:
- Use a role-based Apple ID (for example
apple-mdm@yourdomain.com), never a personal one, with credentials and MFA recovery documented in your password vault. - Assign a named renewal owner — a person, with a deputy, not a team alias nobody reads.
- Set calendar reminders at T-60, T-30 and T-7 before expiry, in a shared calendar the owner and deputy both see.
- Check the certificate in your leaver process for IT staff: if the departing admin created it, verify portal access before their last day.
- Apply the same pattern to the neighbouring annual renewals — the ADE (enrolment programme) token and VPP (apps and books) tokens fail in similarly ugly ways.
How Decolla handles it
Straight answer first: Decolla does not fix this problem, and nothing can once the certificate is unrecoverable — Decolla provisions Windows devices over your own Intune and Autopilot tenant, and it does not manage Apple devices or renew APNs certificates.
What Decolla does address is the underlying failure mode: an expiry-dated tenant dependency with no named owner. Every Decolla build produces a written, itemised plan before anything runs, and that plan itemises the expiry-dated items it depends on — with the expiry date and a designated renewal owner recorded against each — so a renewal deadline is never an unowned fact buried in a portal. The same discipline in this article's step 5 is, in other words, built into the paperwork rather than left to memory. Each planned item also carries its delivery method and a reversibility class, and Decolla can roll back its own changes per item.
Decolla is pre-launch and currently waitlist-only.
Sources
- Microsoft Learn — Get an Apple MDM Push certificate for Intune (365-day validity, the 30-day renewal grace period, and the admin-centre path)
- Apple Support Communities thread 253988386 — MDM push certificate expired for 30 days; wipe required for non-removable profiles
- Apple Support Communities thread 253056504 — devices lose connection to Intune after APNs certificate expiry, even after creating a new certificate
- Apple Support Communities thread 254818563 — expired APNs certificate and device re-enrolment
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access