This build has a property almost nothing else in enterprise IT has: a credential that exists only for the lifetime of a browser tab. Close the wrong window and the certificate you downloaded ninety seconds ago is dead. Everything about how this article is sequenced follows from that one fact.
The worked estate is CatSnackJack, with a verified Apple Business organization, a federated domain, the Verizon supplier link from [AB 6.1], seven Configurator-added devices from [AB 6.2], and Intune already managing its Windows estate. What it does not have is any connection between the two, so no device it owns has ever been offered to Setup Assistant for enrolment.
Prerequisites. On the Apple side, a role whose permissions include viewing, adding and deleting device management services. On the Microsoft side, enough Intune rights to create an enrolment program token, which Microsoft does not state as a named role on any live page I could find; Intune Administrator covers it, and a narrower custom role is worth pursuing if you have the appetite. A tenant with Intune licences assigned to whoever will enrol. And a decision, made before you start, about which named account will own the token, because that decision is a control and step 1 exists to force it.
Timing. Steps 4 through 7 are one continuous sitting of about fifteen minutes and must not be interrupted, for the reason in the deck. Everything before them can be done at leisure. Do not start step 4 twenty minutes before a meeting.
Naming convention. Apple gives you one name to choose. You can rename it later from the service’s edit screen, so it is not irreversible, but it is the string every administrator will use to identify this connection, and Apple surfaces it inconsistently: the device list shows the service assignment only until a user signs in, at which point it shows the user’s name, and the device record shows no service at all until the device is enrolled. Choose it as though you cannot change it and you will not have to. Apple’s own constraints are that the name must be unique across your services, that it does not need to be a fully qualified domain name, and that you cannot use Unassigned or Reassigned.
| Artefact | Convention | CatSnackJack value |
|---|---|---|
| Device management service in Apple Business | Product, then organisation, then the platform scope it serves. Product first because you will one day evaluate a second MDM alongside this one and the list should sort by product. | Intune CatSnackJack Mobile, with Intune CatSnackJack Mac reserved if step 5 proves a second is needed |
| Intune public key file on disk | intune-public-key- then the service name, then the date, then .pem | A file named for the service it belongs to, so it cannot be confused with the one from the other service |
| Apple service token file on disk | apple-service-token- then the service name, then the date, then .p7m | Same reasoning. Two .p7m files in a downloads folder with default names are indistinguishable. |
| Token owner record | The named account, the date, the renewal date, the deputy, and the change record that authorised it | Held with the supplier register from [AB 6.1] |
Do not name the service after the person building it, after a project code, or after a date. All three have been tried and all three age into a name nobody can interpret.
Step 1. Decide who owns the token
Apple invalidates the token when the account that downloaded it changes its password, and again when that person leaves the organisation. Whoever is signed in during step 5 becomes a dependency of your provisioning plane, and if that is the consultant doing the build, the connection breaks on their last day.
Verification gate, and it is here rather than at step 5 because after step 5 the decision is made. Confirm all of the following before you sign in to Apple Business for this build. That the account is a Managed Apple Account belonging to the organisation rather than to an individual’s career. That it holds the permissions to view, add and delete device management services. That its password is on a lifecycle you have chosen rather than one it inherited from a default policy, because a scheduled rotation is now an outage. That it is excluded from the ordinary leavers automation, or explicitly included in a documented handover. And that a second named person can sign in as an Organization Administrator if the first is unreachable, which matters more than usual because Apple’s terms and conditions acceptance can lock most functionality until an Organization Administrator signs in, as [AB 3] set out.
Apple will not let you build a nameless service principal here. The initial administrator account must carry a legal human name, and accounts named for a function are returned for correction. So the achievable target is a designated named administrator with a documented successor rather than a true service identity, and pretending otherwise produces a runbook that cannot be followed.
Expected result: a named account, recorded in the token owner record, with a deputy named beside it. For CatSnackJack that is the IT manager rather than the consultant, which was a five minute conversation and is the reason this connection will still work in two years.
Step 2. Confirm the Apple side is actually ready
Three quick checks, all read-only, all in the browser. Skipping them produces a connection that works and does nothing, which is harder to diagnose than one that fails.
| Check | Where | Expected |
|---|---|---|
| The organization is verified | The organization’s details | Approved rather than pending. An unverified organization is on a sixty day clock that ends in deletion. |
| At least one device is in the register | Devices, then Inventory | Any device. Without one you cannot complete step 10, and a connection you cannot test is a connection you have not made. |
| The built-in device management service is off | Devices, then Management Services | Not present, or present and understood. See the gate below. |
Verification gate, and it is here because the way back is expensive rather than absent. Apple permits an external device management service and its own built-in service to coexist at tenant level, and says so plainly. At device level they are not interchangeable. Apple states that migrating to and from the built-in device management service is not supported, which removes the assisted migration flow with its deadlines and app preservation in both directions. Turning the built-in service off is documented and offers you a reassign-and-delete or an unassign-and-delete, but any device already enrolled in it has to be signed out and unenrolled first. So the route back exists and it costs a re-enrolment per device, plus the removal of an AppleCare+ for Business plan if you hold one. If somebody has switched the built-in service on to have a look, find out which devices it holds before you go further, and do not switch it on yourself as an experiment.
There is a related trap in the content token area that belongs to a later article and is worth a sentence here because the ordering matters. If your organization moved across from Apple Business Manager or Apple Business Essentials and you turn on built-in device management before making any app assignment using your primary location content token, Apple states that your primary organizational unit becomes reserved and the token stops appearing, so you cannot link a third-party device management service to distribute apps. Apple does not say whether that is recoverable. The reverse case is documented too: if you have already uploaded a content token to an external service and then want the built-in service, Apple tells you to remove that token first to avoid app licence inventory inconsistencies and assignment failures. The content token build sheet later in the series puts a gate in front of both. Do not touch built-in device management until you have read it.
Step 3. Get the push certificate in place first
Without an Apple MDM push certificate, enrolment fails regardless of how correct the rest of this build is. It is a separate credential with a separate lifecycle and it is the one that costs you the fleet, so it goes first and it gets its own owner record.
If one already exists, verify it rather than assume: read its expiry date and read which Apple account created it. That second value is the one that matters and it is the one nobody records.
If one does not exist, in the Intune admin center go to Devices, expand Device onboarding, select Enrollment, then the Apple tab, then Apple MDM Push Certificate. Select I agree, then Download your CSR. Then select Create your MDM push Certificate, which takes you to Apple’s push certificates portal, sign in with the organisation’s Apple account, select Create a Certificate, accept the terms, select Choose File, upload the CSR, and on the confirmation page select Download to obtain a .pem. Back in the admin center, enter the Apple ID you used, select the folder icon, choose the file and upload it. Renewal is complete when the certificate shows as active in both the admin center and Apple’s portal.
Verification gate for every future year, and put it in the runbook now while you are thinking about it. The certificate is valid for 365 days with a thirty day grace period after expiry. At renewal you must renew the existing certificate rather than replace it, and you must do so with the same Apple account that created it. Microsoft’s own troubleshooting guidance is explicit that replacing rather than renewing means re-enrolling every iOS and iPadOS device in the estate. Note that Microsoft’s push certificate article describes changing the associated Apple ID as a routine redownload with no consequence stated, which cannot be squared with the other two Microsoft statements on the subject. Follow the cautious version.
One identification tip worth recording, because in an estate with history you will one day be holding three certificates and no idea which is live. Each certificate has a unique identifier, visible as the subject ID in the certificate details, and the same value appears on an enrolled device under Settings, then General, then Device Management, then Management Profile, then More Details, then Management Profile, as the Topic value. That is how you match a certificate in Apple’s portal to the fleet actually depending on it.
Expected result: the push certificate shows as active in both the admin center and Apple’s portal, and its expiry date and owning account are in the runbook.
Step 4. Download the Intune public key, and do not close the tab
From here to step 7 is one continuous operation. Read all four steps before you begin.
In the Intune admin center go to Devices, expand Device onboarding, select Enrollment, then the tab for the platform family you are connecting, then under Bulk Enrollment Methods select Enrollment program tokens. Start a new token, agree to the permission prompt, and download the public key certificate.
Microsoft’s own articles disagree about the labels on that screen, and not in date order, so read the screen rather than trusting any procedure including this one. The two policy articles dated May 2026 name the tabs Apple mobile and macOS, 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, as does the push certificate article, and the troubleshooting article describes a navigation path that has not existed for years. On the entry control, one live article says Add and two say Create. On the download control, one says Download the Intune public key certificate required to create the token and another says Download your public key. Since the newest page is not the most current one, you cannot pick by date. Confirm against the screen and write down what you actually saw, with the date, because that record is worth more than any of the four articles.
Verification gate, and it is the reason this step is not step 5. Microsoft’s warning, an Important rather than a Warning, is that you must keep the browser tab open, because if you close it the certificate you downloaded is invalidated and you must start over. On the Apple mobile article the warning adds that the Create button on the review tab will not be available if you close the tab. There is a third version in the tutorial which says only not to close the Intune tab because you will return to it, and drops the invalidation entirely, so a reader following the tutorial is never told the certificate dies. Before you go anywhere near Apple Business, confirm three things: that the .pem file is on disk and is not zero bytes, that you have renamed it per the convention so it cannot be confused with anything else, and that the Intune tab is open in a window you are not about to close by habit. Open Apple Business in a new tab, not by navigating this one away.
File provenance. The .pem is your Intune tenant’s public key. It is not secret, and it is not disposable either, because the private half is held by Intune and this file is the only thing that binds Apple’s token to it. It is about to be uploaded to another vendor’s portal. Handle it on a managed device, keep it out of shared drives and chat messages, name it for the service it belongs to, and delete it deliberately when the build is closed rather than leaving it in a downloads folder for two years. The same goes double for the .p7m you collect in step 6, which is the credential itself.
Step 5. Create the device management service in Apple Business
In the new tab, sign in to Apple Business as the account you designated in step 1. Go to Devices, then Management Services. If this is the first service of any kind in the organization, select Get Started. If one already exists, select Connect external device management, then Continue.
Then work through the screen in this order.
| Setting | Value | Why |
|---|---|---|
| Service name | The name from the convention | Apple describes the action and never labels the field. It must be unique, need not be a domain name, and cannot be Unassigned or Reassigned. It appears on device records and assignment activities forever. |
| Release Devices checkbox | Clear it, unless you have decided otherwise and written down why | See the gate below. This grants the service the ability to permanently release devices from your organization without anybody signing in to Apple Business. |
| Public key certificate file | The .pem from step 4 | Apple accepts .pem or .der and states no size, naming, key length or algorithm constraint. It also caps the organization at 250 uploaded certificate files across its whole life, with no counter in the interface. |
Then select Next. Apple names no control for the upload itself, only the button that follows it, which is one of three controls in this flow Apple leaves unlabelled. The others are the service name field and the edit control on the service afterwards, which Apple renders as an icon with an empty alt attribute, identifiable only from the image filename in the page source. Since this series does not use screenshots, I am telling you they are unlabelled rather than inventing labels for them.
Verification gate on the Release Devices checkbox, and read it before you click anything. Apple contradicts itself about the default state of this box. Its release devices page says the ability is enabled by default when you add a device management service. Its page for linking an external service tells you not to select the checkbox unless you want the service to have that ability, which only makes sense if the box starts clear. Both pages carry the same published date and neither resolves the other. Microsoft does not mention the checkbox anywhere. So: read the box on screen, set it deliberately, and record what state you found it in as well as what state you left it in. Then verify it again on the edit screen after the service exists, because that is the only way to know what actually got saved. [AB 7] argues about why this is worth the ceremony, and [AB 6] covers what release actually costs, which is Activation Lock management, an erase and restore, and any replacement device if the release happened before a repair.
Expected result: the service exists and Apple offers you a token. Nothing is connected yet.
Step 6. Take the token
Select Download Service Token, then Done. Rename the resulting .p7m per the convention immediately, before you do anything else, because you are one browser download away from having two files called something Apple chose.
This is the only point in the build where taking a token is safe and unremarkable. On every subsequent occasion, downloading a token from a service that is already live invalidates the token Intune is currently using. Two independent community reports quote Apple’s confirmation dialog as saying that downloading a new server token will reset your existing one, and one of them notes that the warning is scoped to the service entry you are standing on, so a download against a newly created service does not disturb a different live one. That is community-sourced and it matches the mechanism, and it is the reason a second MDM evaluation should always get its own service rather than a second token from an existing one.
Apple’s step numbering on this page tells you to repeat steps two through eight for additional services, which stops one step short of the step that transfers the token. Do not follow that literally.
Step 7. Finish in the tab you kept open
Switch back to the Intune tab. In the Apple ID field, enter the account from step 1, exactly as it signs in. In the Apple token field, browse to the .p7m, select it, then create the token.
That Apple ID field is doing more work than it appears to. Microsoft’s own instruction is that this is the identity you will need to renew the token each year, and that future administrators must know which one was used. The field is a note to your successor as much as it is a configuration value, and it is the only place in either product where the token owner is recorded. Put the same value in the token owner record, because a field in a portal is not documentation.
Expected result: Intune connects to Apple Business and begins syncing device information. Microsoft’s tutorial notes that devices can take up to twelve hours to appear in the admin center, which matches the twelve hour automatic sync on the Apple mobile side. The macOS side syncs every twenty-four hours, so quote the figure for the platform you are actually connecting rather than the one you read first.
One thing to settle on screen rather than from documentation. Microsoft documents token creation separately for the Apple mobile family, which its article scopes to iOS, iPadOS, tvOS and visionOS, and for macOS, on a different tab with different button labels. It does not state whether a single enrollment program token serves both tabs in one tenant or whether two are required. Look at your own tenant after this step and see whether the token you just created appears under both. That answer determines whether you run steps 4 through 7 a second time, and whether the reserved service name from the naming convention gets used.
Step 8. Record the expiry before you do anything else
The Intune admin center displays the token’s expiration date. Read it now, while you are here and the build is fresh, because this is the only moment when somebody who understands the connection is looking at that field.
Apple states that external service tokens expire after one year and that, depending on the device management service, you may or may not get a warning. Apple itself sends nothing, and the only health signal Apple exposes on the service is the last connected IP address. There is no expiry date, no last sync time and no status indicator on the Apple side at all.
So put three entries in a calendar that belongs to a team rather than a person: one at eleven months to schedule the renewal, one at eleven months and three weeks as a reminder, and one on the expiry date itself as a backstop. Name the token owner and the deputy on each. This is unglamorous and it is the single highest-value paragraph in this article, because the failure mode it prevents is a fleet of new hardware that will not enrol during whatever week you are busiest.
Step 9. Assign devices and sync
A connected token with no devices assigned to it does nothing. Assignment happens on the Apple side, and there are two routes: set the default device assignment per device type so future arrivals are handled automatically, which is step 8 of [AB 6.1] and which you can now complete; and assign the devices that arrived before the service existed, which the default will never reach because Apple applies it only to devices added afterwards.
For the back catalogue, in Apple Business go to Devices, then Inventory, select the devices, then Assign Device Management, which is the label Apple’s assignment page gives for both a single device and a multiple selection. Choose the service, select Continue, read the dialog and select Confirm, then wait for the activity and select Done. You can filter by source, by order number, by device type, by storage size, or paste up to 1024 serial numbers.
Then sync in Intune. The constraints are worth knowing before you sit there pressing the button: a manual sync no more than once every fifteen minutes, all sync requests have fifteen minutes to finish, an automatic delta sync every twelve hours on the Apple mobile side and an automatic sync every twenty-four hours on the macOS side, a full sync no more than once every seven days, and throughput of roughly three thousand devices per minute.
The rule that catches everybody, stated once so you never have to learn it the hard way. Deleting a device in Intune while it is still assigned to the token in Apple Business does not delete it. It reappears on the next full sync, which may be seven days away. Unassign in Apple first, then delete in Intune. Apple Business is the record and Intune is downstream of it.
Step 10. The end-to-end test
Nothing so far proves the connection does its job. It proves two portals exchanged files. The test is one device, all the way through.
| Stage | Expected output | What it proves |
|---|---|---|
| Open the token in Intune | An expiration date roughly a year out, the Apple ID you entered, and a device count above zero after a sync | The token decrypted and the trust relationship is live. |
| Open the service in Apple Business and read the last connected IP address | A populated value, recent | Apple has seen Intune connect. This is Apple’s only health signal, so learn where it is now rather than during an incident. |
| Find one known serial in the token’s device list in Intune | The device from [AB 6.2], or a supplier-delivered device, present by serial number | Assignment crossed the connection in the right direction. |
| Create an enrolment policy and assign it to that device | The policy saves and the device shows it as assigned | Intune can upload policy to Apple, which is the second of the three capabilities the token grants. |
| Power the device on and walk Setup Assistant | The remote management pane appears and names your organisation | The provisioning plane works. This is the outcome the whole of Wave 1 exists to produce. |
Two known failures at that last stage, both with causes outside this build sheet. If the device shows an invalid profile, check that the default All Users device type restriction is not blocking the platform, which is [3.1.1]. If enrolment simply does not start, Microsoft’s documented cause is an enrolment profile created before the token was uploaded, and the documented fix has two steps: edit the profile and change anything at all, because the purpose is to update its modification timestamp, then synchronise the ADE-managed devices. Note that Microsoft still says profile there, on a page that predates the rename of the blade to enrolment policies.
What this test does not prove is that the device is registered in Entra ID or evaluated for compliance. It is not, yet, and the gap between MDM enrolment and Entra registration is the subject of Wave 2 rather than a fault in this build.
Step 11. Recovery, when you closed the tab
Somebody will close the tab. The symptom is that Apple accepts the public key and the resulting token fails on upload with an error naming the enrolment program token and an AjaxError request ID, or that sync fails later with a certificate mismatch between the two systems. Microsoft scopes its published route to that first, specific error rather than to a closed tab, so do not tell a colleague that Microsoft published a tab-recovery procedure. The mechanism is the same; the framing is mine.
The obvious recovery is to start over from step 4, and if you have not yet created the Apple-side service, that is the right answer and it costs ten minutes. The route below is for the case where the service already exists in Apple Business and you need Intune’s current public key without being able to re-download it from a wizard you have lost.
Microsoft documents this in its troubleshooting article and it uses the Graph beta endpoint, which means it is unsupported for production use by Microsoft’s own beta policy. Sign in to Graph Explorer as an Intune administrator and run two calls.
GET https://graph.microsoft.com/beta/deviceManagement/depOnboardingSettings
GET https://graph.microsoft.com/beta/deviceManagement/depOnboardingSettings/<TokenGuid>/getEncryptionPublicKeyThe token identifier in the second call is read from the first. Never print it in a runbook. The response is a JSON object whose value is a single string containing the certificate, and you rebuild a file from it in exactly this shape.
-----BEGIN CERTIFICATE-----
SOMEBASE64STRING==
-----END CERTIFICATE-----Microsoft flags that file with an Important, and the text reads, verbatim including its typo, that the file contains three lines and there are no link breaks in the base64 string. It means line breaks. Three lines total, and the base64 body must be one unbroken line however long it is. Save it with a .pem extension, named per the convention in this article rather than whatever the example calls it.
One practitioner account of this route, published in August 2025 and describing the pre-rename interface, reports it working, and adds a technique worth stealing: download a throwaway public key from Intune purely to obtain a correctly shaped file, then replace its body with the base64 returned by Graph. That gets the envelope right without hand-typing it. It is one source, it predates the rename, and nobody has confirmed it since, so treat it as a promising route rather than a supported one.
Upload the file to the existing service in Apple Business through the edit screen, which lists viewing or uploading a new public key certificate among its available actions. Microsoft’s own next instruction sends you to an MDM Server Settings section that Apple Business no longer has, which is a good illustration of why the earlier warning about reading the screen is not pedantry.
Verification gate that Microsoft’s own procedure omits, and this is the most dangerous paragraph in this article. The next instruction in Microsoft’s troubleshooting flow is to select Download Token, and that flow does not repeat the warning that doing so invalidates the token currently in use by Intune. If the service you are repairing is live and carrying enrolments, you are about to break the working connection in order to fix a different problem. That may well be correct, because a mismatched key means the connection is already degraded, and it should be a decision rather than a step you followed. Confirm before you click: that this is the service whose key is mismatched rather than a healthy neighbour, that you have the Intune tab ready to complete the renewal immediately, and that you have told whoever is watching enrolments that there will be a gap. Then finish the renewal in one sitting.
Graph exposes other actions against the same object, including generating a fresh encryption public key, uploading a token and triggering a sync, none of which Microsoft documents in prose. I am naming them rather than printing request bodies I have not run, because a build sheet that invents an API call is worse than one that says where to look.
Step 12. Write the renewal down, with the date you validated it
Do not put a link to Microsoft in your runbook for this. Microsoft currently publishes three live renewal procedures that disagree with each other, most sharply on the button you press at the end, which is Renew token on the Apple mobile page, Create on the macOS page and Save in Intune for Education. Its search index additionally serves variants of these pages containing steps that are not on the live pages at all, including a warning about a button called Download Server Token that does not exist. A colleague following a search result may be following a document that has been superseded.
The shape all three agree on is this, and it is what to write down in your own words.
| Order | Action | Note |
|---|---|---|
| 1 | Sign in to Apple Business as the recorded token owner | If that account has gone, this is a handover rather than a renewal and it needs its own change record. |
| 2 | Open the device management service under Devices, then Management Services | Confirm you are on the right service by its name and its last connected IP address before you touch anything. |
| 3 | Open the overflow menu on the service and select Download Token | This is the irreversible step. Microsoft describes the control as the actions menu at the top right of the page; the administrator who lost four hours to it in April 2026 found it behind a small ellipsis inside the service panel. Read the screen. |
| 4 | In Intune, open the token and start the renewal | Enter the same Apple ID as the original. |
| 5 | Upload the new token, assign scope tags if you use them, and complete | The terminal button is one of three labels depending on which page you read. Read the screen. |
| 6 | Verify the new expiry date and update the calendar entries | A renewal that does not move the calendar is a renewal you will do twice. |
Put the date you validated that procedure at the top of it. In an area where the interface moved once already this year and neither vendor announced it, a procedure without a validation date is a guess with formatting.
Completion checklist
A named token owner and a named deputy are recorded, and the owner’s password lifecycle is a decision rather than an inheritance. The push certificate is active in both systems, with its expiry date and its owning account written down, and the runbook says renew rather than replace. The device management service exists in Apple Business under a name that follows the convention. The Release Devices checkbox state was read on screen at creation, set deliberately, and verified again on the edit screen, with both observations recorded. The token is live in Intune, its expiry date is in a shared calendar with three entries and two names against it, and the Apple ID field matches the token owner record. Devices are assigned, the default device assignment is set for future arrivals, and somebody understands that it is not retroactive. One device has reached the remote management pane. The public key and token files have been renamed, moved off the downloads folder, and scheduled for deletion. And the renewal procedure exists in your own words, with a validation date on it.
That completes Wave 1. A reader who has followed it from [AB 1] now has a verified, federated Apple Business organization, devices arriving into it from the channels they actually buy through, and a live connection to Intune. Nothing is enrolled yet, and that is deliberate: enrolment is a set of choices rather than a step, and the next wave is about which door each device should come through and what each one costs you.
Apple Business
‹ Previous: [AB 7] The Token That Is Not the One You Think
Next: [AB 8] Four Ways In, and What Each One Costs You ›
