Three separate Apple credentials sit between Apple Business Manager and Intune, and they expire on three separate clocks. When one lapses nothing announces it. Enrolled devices carry on until they do not, new enrolments stop, or app licences quietly refuse to assign. The Apple Business Manager Intune integration is really a set of tokens with different renewal rules and very different blast radii. This post covers what each one controls, what breaks when it expires, and the renewal step that invalidates a token that was working perfectly well.
The reflex when Apple devices misbehave is to look at the device, and the order to check things in is the subject of the Intune troubleshooting hub. But a whole class of Apple symptoms has nothing to do with the device and everything to do with a credential in the tenant that ran out. I have not renewed these tokens in production: the tenant behind this site is a lab with no enrolled Apple devices. Every fact below was verified against Microsoft Learn on 29 September 2026, and where the documentation is silent or disagrees with itself I say so rather than smoothing it over.
How the Apple Business Manager Intune connection is actually held together
Three credentials, three blades, three renewal conversations with Apple. They are not tiered and they do not cover for each other.
| Credential | Where Intune keeps it | Validity | What stops when it lapses |
|---|---|---|---|
| Apple MDM push certificate (APNs) | Devices, Enrollment, Apple tab | 365 days, plus a 30 day grace period | Management of every iOS, iPadOS and macOS device in the tenant |
| Enrollment program token (ADE) | Devices, Enrollment, Apple tab, Enrollment program tokens | Renewed yearly | Automated device enrolment for the serial numbers assigned to that token |
| Apple VPP or location token | Tenant administration, Connectors and tokens, Apple VPP tokens | One year | Volume purchased app assignment and licence reclaim |
One small thing the documentation will not tell you, because it is a symptom of the documentation rather than the product: the portal paths in Microsoft’s own Apple articles do not currently agree with each other. The push certificate article routes you through Devices, then Device onboarding, then Enrollment. The Apple token management article goes straight from Devices to Enrollment. The iOS automated enrolment article calls the destination the Apple mobile tab rather than the Apple tab. All three were live on 29 September 2026. The blades are the same blades, the navigation has been reorganised more recently than some of the prose, and if you are following a written runbook written by anybody, including Microsoft, expect the breadcrumbs to be one revision behind the portal.
The push certificate is the one that takes the whole platform with it
The Apple MDM push certificate is the single point of failure for Apple management in a tenant. Microsoft’s guidance on getting an Apple MDM push certificate for Intune is explicit: the certificate is valid for 365 days, it must be renewed annually to maintain iOS, iPadOS and macOS device management, and once it expires there is a 30 day grace period in which to renew it.
Read that grace period carefully. It is 30 days in which the renewal is still possible, not 30 days in which everything keeps working. Treating it as a buffer is how organisations end up re-enrolling an estate.
The renewal itself has one hard requirement that causes most of the real incidents. Microsoft’s instruction is to renew the certificate with the same Apple account used to create it. There is no recovery path if that account is gone, only a new certificate and a re-enrolment. The same article recommends using a company email address as the Apple ID and making sure the mailbox is monitored by more than one person, such as by a distribution list, and explicitly advises against a personal Apple ID.
That advice reads like boilerplate until you meet the tenant where the push certificate belongs to a contractor who left eighteen months ago. Everything that depends on the Apple platform goes with it, including the parts that feel unrelated, such as the custom compliance settings for macOS that only report because the device is still under management.
The ADE token, and the download button that invalidates it
The enrollment program token is narrower. It covers automated device enrolment for the serial numbers Apple Business Manager has assigned to that specific token, which is why organisations with several Apple Business Manager locations end up with several tokens. Microsoft’s ADE token setup documentation, checked on 29 September 2026, states plainly that the enrollment program token should be renewed yearly and that the Intune admin center displays the token expiration date. It also records the Apple ID used to download the server token, and notes that this is the Apple ID you will need in order to renew the token each year.
There is a warning on the Apple device and token management article that deserves to be read twice, because it describes an outage caused by curiosity: do not select Download Token unless you intend to renew the token, because doing so invalidates the token currently in use by Intune. There is no confirmation dialogue that explains this in those terms. An administrator checking whether the token is healthy, by downloading it to look at it, has just broken automated enrolment for every serial number on it.
The deletion path carries a similar edge. Removing a token requires removing its devices first, and the same article states that deleting devices from a token removes those devices from Intune management, so users still working on them lose access to corporate resources and apps managed by Intune.
Two more behaviours worth knowing. Changing the Apple ID used to create the token does not affect currently enrolled devices until they re-enrol, which means a renewal done under the wrong account can look completely successful for months and then fail on the first wipe and rebuild. And Intune blocks devices from enrolling when the token expires, though it does raise an alert before a token is due to expire. Enrolment failures caused by an expired token look identical to enrolment failures caused by policy, which is a good reason to rule out both the token and your Intune enrollment restrictions before you start reading device logs.
The VPP token, and the error you will actually be handed
The Apple VPP or location token governs volume purchased apps. Microsoft’s article on managing Apple volume purchased apps states that each token is valid for one year, and that a token shows an invalid status in Intune if it expired or if anything changed about the Managed Apple ID account used to set it up: a domain change, a password that was changed or has expired, or an account that was disabled.
That list matters because three of those four causes are not expiry at all. A password policy applied to the Managed Apple ID is enough to put a token into an invalid state months before its actual expiry date, which is not the failure most people are watching the calendar for.
The symptom administrators report is a licence assignment failure. The error string raised in Microsoft Q&A for this condition is license assignment failed with tokenexpired. (0x87d13b88), and the answer given there is the obvious one: renew the token from Tenant administration, Connectors and tokens, Apple VPP tokens, by uploading a fresh file from Apple Business Manager. The reason it is worth knowing the code is that the message says nothing about Apple Business Manager, and searching it is how most people find their way to the right blade.
Licence reclaim has its own conditions. Intune can only revoke a VPP app licence where the licence was assigned from Intune, the device is managed by Intune, and the Intune device record for that device still exists. Delete the device record first and the licence is stranded on Apple’s side of the fence with nothing in Intune left to release it.
The failure modes
These are the shapes an Apple Business Manager Intune credential failure actually arrives in.
- The Apple ID belongs to a person, and the person has gone. The push certificate and the ADE token can only be renewed with the account that created them. This is the one failure on the list with no clean remediation.
- Somebody downloaded the ADE token to check it. Automated enrolment stops for every device on that token, immediately, with no error anywhere that names the cause.
- A second VPP token was added without retiring the first. Apps stay bound to the token they were assigned from, so a tidy looking new token sits alongside app assignments that still point at the dead one.
- A token was renewed under a different Apple ID and looked fine. Enrolled devices are unaffected until they re-enrol. The bill arrives on the first rebuild, often months later, by which time nobody connects the two events.
- The push certificate grace period was treated as a buffer. Thirty days to renew is not thirty days of normal service.
- The device record was deleted before the licence was revoked. Intune will not reclaim a VPP licence for a device it no longer has a record of.
What I would do differently
Two of these are process, not configuration, which is why they get skipped.
First, the Apple credentials belong to a shared mailbox before they belong to anybody. Not a distribution list bolted on afterwards, which still leaves the Apple ID owned by whoever first signed in. The Apple account that creates the push certificate is effectively a tenant asset with a one year fuse, and the only good time to fix its ownership is before it matters.
Second, the three expiry dates live in two different parts of the admin center and Intune does not present them together. A single calendar entry 60 days ahead of the earliest of the three costs nothing and removes the entire class of problem. Sixty rather than thirty, because the renewal requires a working Apple Business Manager session and someone who can sign in to it, and neither of those is guaranteed on the day you discover you need them.
And a general point that applies well beyond Apple. Every certificate and token in Intune has an owner, a cadence and a blast radius, and the ones that cause outages are always the ones where nobody could name all three. The same reasoning applies to device certificate profiles, where the choice between SCEP and PKCS in Intune determines what happens on renewal day. Write the three facts down for every credential you own. It is a worse use of an afternoon than almost anything else you could do, and a better use than the afternoon it saves.
Last verified: 29 September 2026.
