Three Apple tokens, three annual expiries, three different failures
Managing Apple devices from Intune depends on three separate credentials — the APNs push certificate, the ADE/DEP enrolment token and the VPP token — created in different portals, bound to different Apple accounts, and each expiring twelve months after creation. Admins routinely conflate them, and each one breaks something different when it lapses. Here is the one-page matrix that keeps all three straight.
The problem
Intune cannot manage a single iPhone, iPad or Mac without an Apple MDM push certificate (APNs). Add Automated Device Enrolment through Apple Business Manager and you also hold an ADE/DEP enrolment token. Deploy apps through Apps and Books and you hold a VPP token as well. Three credentials, three portals, and every one of them expires a year after it was created.
“There are at least 3 separate tokens… each of these expires one year after creation and needs renewing before they expire.” — Brian Reid, c7solutions.com
The failure modes are wildly different, which is why admins get caught. If the push certificate lapses, Reid warns, “all your iOS devices will stop syncing with Intune and after x days will go non-compliant.” A lapsed ADE token, by contrast, leaves existing devices untouched but silently kills new enrolments. A lapsed VPP token is the sneakiest of the three: installed apps keep running normally, so nobody notices until an app push or an update quietly fails weeks later.
Who hits this: anyone running Apple devices from Intune — and especially teams where the person who originally created the tokens has moved on, taking the Apple ID (and any renewal warning emails) with them.
Why it happens
This is Apple's MDM architecture, not an Intune quirk. Three distinct trust relationships have to exist, and each is anchored by its own short-lived credential:
- APNs certificate — the push channel. Apple requires all MDM traffic to be triggered via the Apple Push Notification service, and the certificate authorising your tenant to send those pushes is issued at
identity.apple.comfor 365 days. No valid certificate, no way to wake a device: check-ins stop, policy stops flowing, compliance data goes stale, devices tip into non-compliant, and Conditional Access can then start locking users out. - ADE/DEP enrolment token — the trust between Apple Business Manager (or School Manager) and Intune. It is a server token downloaded from ABM for your specific MDM server entry. When it expires, ABM stops syncing with Intune, enrolment profile assignment fails, and new or freshly reset devices can no longer enrol automatically.
- VPP token — the Apps and Books licence channel, downloaded per location from ABM. When it expires, app deployment, app updates and licence assignment or reclamation all stop — while every already-installed app keeps working, which masks the failure completely.
Three aggravating factors turn an annual chore into an outage:
- Different portals. APNs renews via
identity.apple.com, the other two viabusiness.apple.com, and all three have to be re-uploaded or completed in the Intune admin centre. There is no single “renew everything” button. - Account binding. Each credential is tied to the Apple account that created it. The APNs certificate in particular must be renewed with the same Apple ID — replace it using a different account and every Apple device has to be re-enrolled. If that account was a departed admin's personal Apple ID, you have a problem long before expiry day.
- Staggered dates. The three credentials were almost never created on the same day, so you get three (or more — multiple ADE tokens and multiple VPP location tokens are common) independent annual deadlines, each capable of breaking something different.
The fix
Publish a one-page token matrix for your tenant and put named owners and dates against every row. Here is the template:
| Credential | Where it renews | What breaks when it lapses | Account rule |
|---|---|---|---|
| APNs / MDM push certificate | Intune admin centre → Devices → Enrollment → Apple → Apple MDM Push certificate (download CSR) → identity.apple.com → Renew the existing certificate → upload back into Intune | Devices stop syncing and receiving policy; compliance goes stale and devices go non-compliant; if the certificate is replaced rather than renewed, every Apple device must re-enrol | Must renew with the same Apple ID that created it. Never delete and recreate. |
| ADE/DEP enrolment token | business.apple.com → download a new server token for the same MDM server entry → Intune admin centre → Devices → Enrollment → Apple → Enrollment program tokens → renew | ABM sync stops; enrolment profile assignment fails; new and wiped devices cannot enrol automatically. Existing enrolled devices keep working. | Renew from the same ABM organisation against the same MDM server record. |
| VPP / Apps and Books token | business.apple.com → Apps and Books → renew the location token → Intune admin centre → Tenant administration → Connectors and tokens → Apple VPP tokens | App deployment, app updates and licence assignment/reclaim stop — but installed apps keep quietly working, masking the failure | Renew the token for the same location with the same ABM account; a token from a different account breaks licence tracking. |
Then do these five things today:
- Inventory the real dates. In the Intune admin centre, check Tenant administration → Connectors and tokens (and the Apple enrolment blades). Record the expiry date of the push certificate, every ADE token and every VPP token — estates with several ABM locations or MDM server entries have more than three.
- Record which Apple account created each one. Store the account name and its credentials in your password manager or runbook next to the expiry date. If any token hangs off a personal Apple ID — especially a leaver's — plan a controlled migration now, on your schedule, not at expiry.
- Move to a role-based Managed Apple Account (for example
mdm@yourdomain.comin ABM) with a shared mailbox behind it, so Apple's own expiry warning emails reach the team rather than one person's inbox. - Set two reminders per credential — 60 days and 14 days out — in a shared team calendar, each naming the owner and linking to the renewal steps in the matrix. Intune shows warnings in the portal, but warnings nobody is looking at do not count.
- Rehearse the APNs rule with the team: renew, never replace. The same-Apple-ID requirement is the single most expensive thing to get wrong on this page — getting it wrong means re-enrolling the entire Apple estate.
How Decolla handles it
Straight answer: Decolla does not manage Apple tokens. Decolla is zero-touch Windows device provisioning that runs over your own Intune and Autopilot tenant, so the Apple side of a mixed estate stays entirely in your hands — the matrix above is the fix, and it works with or without us.
What Decolla does do is attack the same underlying failure mode — undocumented, unowned moving parts that break a year later — on the Windows half of the estate. Before anything runs, Decolla produces a written, itemised plan of every change it will make in your tenant, with the delivery method and a reversibility class (automatic, reversible, or flagged irreversible) stated per item, for you to approve first. Its Library of 260+ pre-built, industry-tested policies, scripts and fixes covers recurring helpdesk issues and built-in hardening, and every change Decolla itself makes can be rolled back per item. If a written plan with owners, dates and consequences named up front is how you want your Windows provisioning to work too, Decolla is pre-launch and taking waitlist sign-ups.
Sources
- Brian Reid (c7solutions.com) — Renewing Apple tokens in Intune
- Microsoft Learn — Manage Apple certificates and tokens in Intune
- Intune Mac Admins — Frequently asked questions
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