Two credentials sit between Apple Business and Microsoft Intune. One of them, if you lose it, costs you future enrolments. The other, if you replace it carelessly, costs you the fleet. Organisations reliably build ceremony around the first and none at all around the second, because the first is the one with the expiry date in the portal.
This article is about the automated device enrolment token, what it actually is, and the four ways it fails that nobody plans for. [AB 7.1] builds the connection. This one argues about what you are building.
Two planes, two blast radii
The Apple MDM push certificate and the enrolment program token do different jobs and fail differently, and Microsoft draws the distinction in one sentence that deserves more prominence than it gets: changing the Apple ID used to create the enrolment program token does not affect currently enrolled devices until they re-enrol, which is unlike the Apple push notification certificate, where changing it requires all devices to re-enrol.
The push certificate is the management plane. It is how Intune reaches a device that is already yours. The enrolment token is the provisioning plane. It is how a device becomes yours in the first place.
Lose the push certificate and every managed Apple device in the estate stops taking instruction, and the recovery is a re-enrolment of the fleet. Lose the enrolment token and nothing currently managed notices; what breaks is the pipeline, and the symptom is that new hardware arrives and never offers the remote management pane.
That asymmetry sets the correct level of ceremony for each, and Microsoft muddies it. Read the token article’s sentence carefully and the thing that requires a fleet re-enrolment is the certificate being changed, which is what the troubleshooting article also says: renew the push certificate, do not replace it, because replacing it means re-enrolling every iOS and iPadOS device. Those two agree. The outlier is the push certificate article itself, which is the only page that addresses changing the associated Apple ID on its own, and which describes it as a routine matter of signing in with the new one, redownloading and reuploading, with no consequence stated at all. Whether that operation is genuinely benign or whether the consequence was simply never written into that page, Microsoft does not say. The prudent reading is the troubleshooting one, because it is the only version written by somebody who had watched it go wrong.
The push certificate is otherwise the better-documented credential of the two. It is valid for 365 days, Microsoft says so plainly, and there is a thirty day grace period after expiry in which you can still renew. Hold that number in mind, because the credential this article is about has no equivalent statement anywhere in Intune’s own documentation.
What the enrolment token actually is
Apple’s own description of the mechanism is the clearest one available and almost nobody quotes it. Every external device management service you create needs to be known to Apple and requires secure authorization using a two-step verification process. The verification process involves creating and installing a device management service token on your device management service. The certificate encrypts the token.
Unpacked, that is an asymmetric key exchange conducted by a human carrying files between two browser tabs. Intune generates a keypair and hands you the public half. You upload that half to Apple Business as part of creating a named device management service. Apple mints a token, encrypts it to that public key, and hands it back. You carry it to Intune, which can decrypt it because it holds the private half and nobody else does.
Three consequences fall out of that design and each one is load-bearing.
The trust relationship is between one Apple Business organization and one named service, not between Apple and Microsoft as companies. Nothing about your tenant is special to Apple. The service you create could be Intune, Jamf or something a contractor wrote, and Apple’s model does not distinguish. That is why Apple’s documentation never names Intune, and why its instructions repeatedly tell you to consult your device management service developer’s documentation. Apple names Microsoft Entra ID freely elsewhere in the same corpus, because identity is a seam Apple has chosen to own. Device management is one it has deliberately left as an interface.
The token is not a shared secret you can copy. It is encrypted to a specific public key. A second MDM cannot use it, and connecting a second MDM means a second service, a second public key and a second token, which is exactly what Apple’s support for connecting more than one device management service is for.
And the credential passes through a human being’s hands as two files. That is not an incidental implementation detail. It is the reason for most of what follows.
The credential is bound to a person, and that is the whole problem
Apple lists exactly three situations in which the active token on an external device management service must be replaced. When you create a new public key or generate a new token. When the user who downloaded the token changes their Managed Apple Account password. And, as a security measure, when the user who downloaded the original token leaves your organization.
Read the second and third of those again. A routine password rotation by one named individual invalidates the connection between your device register and your MDM. So does a resignation. This is an identity lifecycle problem wearing a certificate’s clothes, and it is handled almost everywhere by the person who happened to be doing the project on the day, signing in as themselves, because that is who was logged in.
The design answer is that the account which downloads the token is a control rather than a convenience. It wants a password lifecycle you have decided on rather than inherited, a documented successor, and a place in your leavers process that is not somebody’s memory. Microsoft’s own instruction is thinner than that and still worth following: use your organisation’s Apple ID rather than a personal one, and make sure future administrators know which account was used, in case you leave and the token needs to change hands.
There is a genuine tension here that the advice to “use a service account” glosses over. Apple requires the initial administrator account to carry a legal, human name, and returns accounts named things like IT Coordinator for correction. You cannot build a nameless service principal in Apple Business the way you would in Entra ID. What you can do is designate a specific named administrator as the token owner, record it, exclude that account from ordinary password rotation policy, and treat a change of holder as a planned piece of work rather than a side effect of a leaver ticket. That is weaker than a service principal and it is what the product supports.
Practitioners writing in 2026 land in the same place from experience rather than from the documentation. One puts it as using organisation-controlled accounts and making sure future Intune administrators know which account owns each certificate and token. Another, less usefully, recommends securely sharing the Apple ID credentials so they are available at renewal, which solves the continuity problem by creating a shared password. I would not do that, and I note that nobody I could find has published an account of actually living through a token outage caused by a password change. The failure mode is universally described in the abstract, which usually means it is either rare or unattributed when it happens.
The clock is displayed by the system that is not the source of truth
Apple’s statement is that external service tokens expire after one year and require replacement, followed immediately by a sentence that ought to end any assumption of a safety net: depending on the device management service, you may or may not get a warning that a token is going to expire.
Apple sends nothing. That is not an omission in the documentation, it is Apple telling you that the warning, if any, is your MDM’s job.
Now look at what Apple exposes about the connection. Editing a device management service lets you rename it, set device types, allow devices to be released, view or upload a new public key certificate, generate or download a new token, delete the service, view assigned devices, download a serial number list, and view the last connected IP address. That last item is the entire health surface. There is no expiry date, no last sync timestamp, no status indicator, and no counter of how many of the 250 permitted certificate files you have consumed.
Intune does show the token expiration date. So the authoritative record of when your access to Apple Business dies lives in the system Apple has no relationship with, and the system that owns the credential can only tell you which IP address last spoke to it. Any renewal process that depends on somebody noticing a date in the Intune admin center is a process with a single point of failure who has other work on.
Microsoft never states the day count for this token on any Intune article. It says to renew the enrolment program token yearly and stops. The figure of 365 days exists for the token only in Intune for Education, on two pages both revised in June 2026, one of which says Apple push certificates, enrolment program tokens and volume purchase tokens all expire 365 days after creation. If you print 365 as an Intune ADE fact, that is where it came from, and it deserves the qualifier.
What a lapsed token does to enrolled devices, which is a question with no answer
Apple documents that tokens expire, that replacement is required and that you may get no warning, and then documents nothing about the consequence. No page describes whether enrolled devices continue to function, whether the assignment survives, whether Setup Assistant still offers the enrolment pane on a newly activated device, or whether recovery is a fresh token or a fresh service.
Microsoft does not answer it either, and the shape of that silence is worth noticing. For Android enrolment tokens Microsoft states the equivalent plainly and repeatedly, across at least five live articles covering AOSP userless and user-associated devices, fully managed devices, dedicated devices and corporate-owned work profiles: replacing a token does not affect devices that are already enrolled, and revoking one has no effect on devices that are already enrolled. For Apple ADE the only comparable sentence anywhere is the Note quoted at the top of this article, and it is scoped to changing the Apple ID rather than to the token lapsing. Nothing says what happens when the credential itself expires. The absence is specific rather than general, which makes it harder to read as an oversight.
The field does not settle it. One vendor knowledge base, writing in 2022 about the pre-rename product, asserts that if you miss the renewal reminder nothing will stop working and you can catch up at your convenience, and offers no evidence. Several long community threads about expired tokens exist and every one of them is about the mechanics of the renewal failing rather than about what the expiry did in the meantime. Nobody writes down the part that would answer the question, presumably because they were too busy fixing it.
My own reasoning, and I am labelling it as reasoning rather than fact, is that a lapsed token stops the three things Microsoft says the token enables, which are syncing device information from Apple, uploading enrolment policies and assigning devices to policies, and does not unmanage anything, because managed devices talk to Intune over the push notification channel and never consult the enrolment token again after enrolment. Apple’s nearest statement supports the shape of that: a device management service that goes offline rather than being deleted leaves its devices using the last known management configuration until they are reassigned or erased. That is about network reachability rather than credential expiry and it should not be presented as covering this case.
What follows operationally is unaffected by the uncertainty. The renewal date belongs in a calendar you control, with an owner and a deputy, because the only two systems that could warn you have both told you they might not.
The one-click break
Downloading a token from Apple Business invalidates the token currently in use. Microsoft states it as a note on exactly two of its live pages: do not select Download Token unless you intend to renew the token, because doing so invalidates the token currently in use by Intune, and if you already downloaded it, complete the remaining steps to finish the renewal.
Note the severity Microsoft assigned that. It is a Note, not a Warning, and it is absent from the article most people reach first, absent from the tutorial, and absent from Intune for Education. The only Warning-severity callout in the whole token chain is attached to deleting a token, which is the action that requires you to delete every device first and is therefore the one nobody performs by accident.
Apple does put a confirmation in front of it. Two independent community reports, one from a vendor support engineer in April 2026 and one from an Apple Support Communities thread in February 2025, quote the dialog as saying that downloading a new server token will reset your existing one. The February 2025 thread adds a useful qualification, which is that the warning is scoped to the service entry you are standing on, so downloading a token against a newly created service does not touch a live one. Both are community-sourced and I am reporting them as such.
What makes this genuinely bad design is where the control lives. Microsoft describes it as the actions menu at the top right of the Apple Business page. In April 2026, days after the rename, an administrator with the Organization Administrator role, standing on the correct page, could not find it at all, and answered his own forum post four hours later having discovered it behind a small ellipsis inside each service panel. His verdict, and I would not improve on it, was that this should not be a subtle control. A second administrator replied a few days later having lost the same time to the same thing. Note that Microsoft and the field do not even agree on where it is.
So the shape of the hazard is an irreversible action, one click deep in an overflow menu, whose consequence is described in a sentence published by a different company, on two pages and not on the one you land on first. And Microsoft’s own troubleshooting procedure for a lost public key instructs you to select Download Token as step eight without repeating the warning at all, which means the documented recovery path for one problem deliberately triggers another and does not say so.
The same April 2026 thread carries something else worth recording, because it is the only field account of the rename period I found. The administrator’s ADE sync failed simultaneously across two separate MDM products with an error saying the token appeared to have been deleted, and his volume purchase tokens were revoked the following day. He confirmed the associated Apple account was not locked out and could still sign in. The thread never establishes a cause and closes with a pointer to Apple’s feedback form. One report is one report, and it is the kind of report that argues for treating the days after any Apple platform change as a period to watch your connections rather than assume them.
Three renewal procedures, and why your runbook cannot be a link
Microsoft currently publishes three live, mutually incompatible procedures for renewing this token.
| Apple mobile version | macOS version | Intune for Education version | |
|---|---|---|---|
| Order of operations | Download from Apple first, then Intune | Download from Apple first, then Intune | Start in Intune, then download from Apple |
| Apple role required | Administrator or Device Enrollment Manager | “Appropriate administrator permissions” | Not stated |
| Terminal button | Renew token | Create | Save |
| Renewal triggers listed | None | Password change, and the administrator leaving | None |
| Carries the invalidation note | Yes | Yes | No |
Those are three descriptions of one wizard. The two Intune ones differ on the Apple role you need, on whether the renewal triggers are stated at all, and on the label of the button you press at the end, which is the kind of discrepancy that stops an administrator mid-procedure at exactly the point where stopping is most expensive.
It gets worse below the surface. Microsoft Learn’s search index is serving content for these pages that does not exist on the live pages. A single search returns several conflicting renderings of the same two sections, all under the same addresses. One indexed variant contains a complete inline renewal procedure that the live page does not have, since the live page only cross-links out. Another warns against selecting a button called Download Server Token, a string that appears nowhere on the live page. If a colleague quotes you a procedure they found through search, they may be quoting a document that no longer exists.
There is a design principle underneath the irritation. A renewal that happens once a year, under time pressure, against a control that moved in the last twelve months, documented three incompatible ways by a vendor whose search index is unreliable, cannot be run from a bookmark. It has to be a written procedure that somebody in your organisation validated against the live product, carrying the date they validated it. That is more work than linking to Microsoft and it is the only version that survives contact with next April.
The naming situation compounds it. Microsoft’s admin center split the old Apple tab into an Apple mobile tab and a macOS tab, and its own articles have not caught up in any order you can reason about. The two policy articles dated May 2026 name the new tabs, and so do the Apple mobile token article dated April 2026 and the tutorial dated June 2026. The macOS token article and the Apple mobile management article, both revised in July 2026, still say Apple. So do the push certificate article and the troubleshooting article, the latter describing a navigation path that has not existed for years. The newest page is not the most current one, which removes the only heuristic a reader had.
Microsoft published no release note announcing the rename, the tab split, the article restructure or the move of every one of these pages to a new address. Two of its release note entries dated the week of 27 April 2026, a fortnight after the rename, still say Apple Business Manager, while a third entry in that same week uses the new Apple mobile tab name as though it had always been there.
Which limit actually binds
Intune publishes a limits table: one thousand enrolment policies per token, two hundred thousand devices per policy, two thousand tokens per Intune account, two hundred thousand devices per token, with a warning that exceeding the device figure produces sync problems. That table exists only on the Apple mobile page. A reader working from the macOS pages is given no limits at all.
Apple publishes one number and it is a different unit: you cannot upload more than 250 public key certificate files. Apple documents no limit at all on the number of device management services, and its affirmative statements are open-ended, so do not repeat 250 as a service limit.
The two count different things, and Apple’s is the one that binds, because Intune counts tokens inside one Intune account while Apple counts certificate uploads inside one Apple Business organization that may be feeding several MDM products. Apple also does not say whether that ceiling counts concurrent certificates or every certificate ever uploaded, nor whether replacing a token with a new public key permanently consumes a slot. Nobody in the field addresses it either. An organisation renewing annually across a handful of services will not find out for decades, and there is no counter in the interface to tell them where they stand, which is the more interesting fact.
The constraint people actually hit is neither number. A long Jamf Nation thread from administrators running large education estates reports Apple guidance of fewer than fifty tokens as a practical maximum, and a documented Apple service defect producing throttling errors when many tokens are associated with one MDM, with estates above fifty still failing intermittently. That is a pre-rename, Apple School Manager context and it is community-sourced, and it is the only real-world calibration available. If your design calls for a token per site, read that thread before you commit.
The delegation buried in the wizard
While you are creating the device management service, Apple offers a checkbox labelled Release Devices. What it grants is the ability for that service to release devices from Apple Business without anybody signing in to Apple Business.
[AB 6] set out what release costs: Activation Lock can no longer be managed through Apple Business, the device must be erased and restored, and a device released while at Apple for repair loses its replacement from the register permanently. This checkbox hands that authority to a software system, in a setup wizard, between uploading a certificate and downloading a token.
Apple cannot tell you what its default is. Its release devices page says the feature is enabled by default when you add a device management service and that you remove it by deselecting the option. Its page for linking an external service tells you not to select the checkbox next to Release Devices unless you want the service to have that ability, which is an instruction that only makes sense if the box is clear when the screen is drawn. Both pages carry the same published date, neither cross-references the other on the point, and the edit screen lists the setting as changeable without stating a default. I cannot resolve it from documentation and neither can anybody else.
Microsoft never mentions the checkbox. Not in the token articles, not in the policy articles, not in the tutorial, not in troubleshooting. Its Apple-side steps go straight from uploading the public key to downloading the token. An administrator following Microsoft’s procedure exactly will pass through that screen without being told there is a decision on it. Meanwhile a widely followed community deployment guide, written before the rename, instructs the reader to tick the box and does not explain the implications. Two conscientious administrators following two reasonable sources land on opposite settings.
This is a consent screen for destructive authority, presented mid-wizard, whose default the vendor cannot state and whose existence the other vendor does not acknowledge.
The only defensible posture is to read the checkbox on screen at creation, and to read it again on the edit screen afterwards, and to record what you found. That is not a satisfying answer. It is what happens when two vendors each assume the other is documenting the seam.
Which way the truth flows
One behaviour makes the direction of authority unambiguous and it catches people who are used to Intune being the system they administer. Delete a device from Intune while it remains assigned to the token in Apple Business and the device reappears in Intune on the next full sync. Full syncs run no more than once every seven days.
So a deletion in Intune is not a deletion. It is a temporary local edit with a fuse of up to a week, and the correct sequence is to unassign in Apple Business first. Microsoft says so explicitly and it is still the most common cause of a device that will not stay deleted.
The same asymmetry runs the other way. A device released in Apple Business takes up to forty-five days to disappear from the Intune devices page, reported as removed in the meantime, and Microsoft manages to state that window as both “up to 45 days” and “within 30 to 45 days” inside a single bullet. Neither figure is a promise you should build a reconciliation process around.
The token is the pipe. Apple Business is the record. Every design decision in this area gets easier once that ordering is fixed in your head, including the one about which system you go to first when something looks wrong.
[AB 7.1] builds the connection, including the recovery route for the certificate you are about to invalidate by closing a browser tab.
Apple Business
‹ Previous: [AB 6.2] Build Sheet: Adding Owned Devices with Apple Configurator
Next: [AB 7.1] Build Sheet: Connecting Apple Business to Intune ›
