HomeKb › Three apple tokens intune
Knowledge base · Cross-platform

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:

Three aggravating factors turn an annual chore into an outage:

  1. Different portals. APNs renews via identity.apple.com, the other two via business.apple.com, and all three have to be re-uploaded or completed in the Intune admin centre. There is no single “renew everything” button.
  2. 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.
  3. 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:

CredentialWhere it renewsWhat breaks when it lapsesAccount rule
APNs / MDM push certificateIntune admin centre → Devices → Enrollment → Apple → Apple MDM Push certificate (download CSR) → identity.apple.comRenew the existing certificate → upload back into IntuneDevices 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-enrolMust renew with the same Apple ID that created it. Never delete and recreate.
ADE/DEP enrolment tokenbusiness.apple.com → download a new server token for the same MDM server entry → Intune admin centre → Devices → Enrollment → Apple → Enrollment program tokens → renewABM 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 tokenbusiness.apple.com → Apps and Books → renew the location token → Intune admin centre → Tenant administration → Connectors and tokens → Apple VPP tokensApp deployment, app updates and licence assignment/reclaim stop — but installed apps keep quietly working, masking the failureRenew 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:

  1. 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.
  2. 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.
  3. Move to a role-based Managed Apple Account (for example mdm@yourdomain.com in ABM) with a shared mailbox behind it, so Apple's own expiry warning emails reach the team rather than one person's inbox.
  4. 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.
  5. 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

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