The most common cause of a fleet outage is an expiry date
Almost every total loss of MDM control we have been called into was a certificate or token that lapsed. It is the most preventable outage in mobility.
When an entire mobile fleet stops being manageable overnight, the cause is rarely an attack, a bad policy push or a platform failure.
It is a date that passed.
Mobile device management runs on a stack of credentials that all expire on their own schedule, are all renewed through a different portal, and are all owned — in most organisations — by nobody in particular. When one lapses, the symptoms are dramatic and the diagnosis takes far longer than the fix.
The ones that actually bite
The APNs certificate. Apple’s push certificate is the connection between your MDM and every Apple device you manage. It lasts a year. When it expires, the server can no longer send anything to any iOS or macOS device — no policy, no app, no wipe, no lock. Worse, renewing it with the wrong Apple ID generates a new certificate rather than a renewal, and every device has to be re-enrolled. That is the single most expensive mistake available in this field, and it is made by someone every week.
Apple Business Manager server tokens. The .p7m token linking your MDM to ABM expires annually. When it lapses, zero-touch enrolment stops. Existing devices keep working, so nobody notices until a batch of new handsets arrives and refuses to configure themselves — which is invariably the week the rollout was scheduled.
Android Enterprise binding. The managed Google Play binding does not expire on a fixed clock, but it does break when the service account behind it is disabled or the person who created it leaves. Same effect: new enrolments fail, existing devices carry on.
VPP / Apps and Books tokens. Expire annually, per location. App assignment silently stops working.
SCEP and NDES certificates. The certificate authority infrastructure issuing device certificates has its own expiry chain, including the CA certificate itself. When that goes, devices lose Wi-Fi and VPN access — which users report as a network outage, sending everyone to look in the wrong place.
Identity federation certificates. Token-signing certificates for federated authentication. Rare now that most identity is cloud-hosted, and catastrophic when it happens.
Code-signing and provisioning profiles. In-house applications distributed outside the public stores stop launching when the provisioning profile expires — on every device at once, on a date nobody recorded.
Why it keeps happening
It is not ignorance. It is that the expiry information lives in seven different places and the ownership is genuinely ambiguous.
- The renewal reminders go to the mailbox of whoever set it up, who may have left.
- Several of these credentials are created under an individual’s account rather than an organisational one, so the notification never reaches a team.
- The consequences do not appear at expiry. Push stops working immediately, but enrolment tokens fail only when someone next enrols, so the gap between cause and symptom can be weeks.
- Nothing in the MDM console shows all of them together. You have to know to look.
The fix, which is boring and complete
One register, with dates and owners. Every certificate, token and binding in the environment, with its expiry date, the account it belongs to, the portal it is renewed in, and a named owner. This can be a spreadsheet. It is far better than what most environments have.
Calendar entries at 60, 30 and 7 days. In a shared calendar, not a personal one. The 60-day entry is the one that matters, because several of these renewals require access to accounts that take time to recover.
Organisational accounts, never personal. Every credential created under an account the organisation controls, with more than one person able to reach it. This is the single change that prevents most of the pain.
Renew, do not recreate. For the APNs certificate specifically: sign in with the exact same Apple ID used originally and use the renew action against the existing certificate. If you cannot access that Apple ID, solve that problem before the expiry date, not after — because the alternative is re-enrolling the fleet.
Monitor, if the platform lets you. Several MDM platforms expose token expiry through their API. If yours does, it belongs in whatever already alerts you at 3am.
What to do this week
Open the console and write down four dates: your APNs certificate, your ABM server token, your VPP token, and your SCEP CA certificate. If any of them is inside 90 days, deal with it now. If any of them is owned by an individual’s account, fix that too.
It takes about an hour and it removes the most common total-loss scenario in mobile fleet management.
More on how we operate mobile fleets as a service — expiry tracking is part of it, because it has to be somebody’s job.