Blog

Why this matters

Moving Apple devices from an established MDM platform (Jamf and similar) to Microsoft Intune is not a simple “change the server” exercise. Apple’s management model is built on a chain of trust—certificates and tokens—each tied to an Apple administrator identity and each expiring on a schedule. If you don’t manage those expirations proactively, you can take a stable Apple deployment and turn it into an outage.

This post covers a practical cutover approach, then zooms in on the operational “must‑have”: tracking Apple certificate and token expirations with predictable alerts and repeatable renewal runbooks.

The Apple–Intune trust model in plain English

Intune can manage Apple devices only when Apple and Microsoft Intune are connected through a small set of Apple-issued objects. In most organizations, there are up to three that matter:

• Apple MDM Push Certificate — Enables the core MDM communication channel between Intune and Apple devices.
• Apple Automated Device Enrollment (ADE) Token — Syncs device serials from Apple Business Manager and enables out‑of‑box supervised enrollment.
• Apple Volume Purchase Program (VPP) Token — Syncs app licenses and enables managed app deployment at scale.

Each object expires annually, and each is associated with the Apple ID used to create it. Operationally, that means two rules:

• Use an organization-controlled Apple admin account (not a personal Apple ID).
• Renew with the same Apple ID used when the object was created.

Pre-migration checklist (before touching devices)

Successful migrations are won in the planning phase. Before you schedule a cutover date:

• Confirm Intune is your active MDM authority and your tenant is ready for Apple enrollment.
• Verify Apple Business Manager (ABM) has the correct administrator access and your device inventory is present.
• Decide your enrollment motion (ADE vs. manual enrollment) and create your enrollment profiles accordingly.
• Prepare configuration profiles and compliance baselines (Wi‑Fi, VPN, password policies, FileVault/activation lock posture, etc.).
• Plan your application model (VPP vs. other app distribution) and understand how licensing impacts cutover.
• Back up user data using an approved corporate method (for example, OneDrive-based workflows) so reset/re-enrollment does not become a data-loss incident.

Cutover realities: why “big bang” often happens

Apple app licensing through VPP is one of the most common reasons migrations require a coordinated cutover event. In many environments, you can’t have VPP-purchased applications effectively managed across two MDM servers at the same time. That forces a deliberate switch: the new MDM becomes authoritative for licensing and app assignment, and the old environment loses that capability.

Practically: plan communications, schedule a cutover window, and expect device resets/re-enrollments as part of supervised migration.

Recommended migration sequence (high-level)

1. Configure Intune for Apple: push certificate, ADE token, VPP token, and enrollment profiles.
2. Confirm devices exist in ABM and are assigned to the Intune MDM server.
3. Sync ADE tokens so serial numbers appear in Intune’s ADE device list.
4. Transition VPP (when applicable) and validate app inventory sync into Intune.
5. Move device assignments from the old MDM server to Intune inside ABM.
6. Factory reset devices and complete Setup Assistant enrollment into Intune.
7. Validate: supervision, compliance evaluation, config profiles, app installs, Defender (if used), and sign-in experience.

The overlooked critical control: expiration tracking

Once your Apple fleet is stable in Intune, the biggest long-term risk is not “policy design” or “app deployment.” It’s operational drift—especially when an annual certificate or token renewal sneaks up during vacations, staffing changes, or tool transitions.

What expires (and what happens if you miss it)

1) Apple MDM Push Certificate

• Expires: yearly
• Impact if missed: MDM communication is disrupted; if it expires beyond Apple’s grace period, you may be forced into a rebuild with device re-enrollment at scale.
• Key rule: renew (do not replace) using the same Apple ID.

2) Apple Automated Device Enrollment (ADE) Token

• Expires: yearly
• Impact if missed: new devices stop enrolling automatically; resets may fail to re-enroll; serial sync halts until renewed.
• Key rule: renew and then re-sync so Intune regains current device serial coverage.

3) Apple VPP Token

• Expires: yearly
• Impact if missed: app license sync and assignment can break; new installs and updates may fail; operational friction increases immediately.
• Key rule: renew by downloading a fresh token from ABM and updating it in Intune (keeping the same Apple ID ownership chain).

How to operationalize renewals (without relying on “tribal knowledge”)

The goal is simple: you should never discover an expiring Apple object by accident. Build an operating model that works even when the primary admin is out of office.

Minimum recommended controls

• Central documentation for each object: name, expiration date, Apple ID owner, renewal steps, and storage location of exported token files.
• Automated alerting at 30/60/90 days (choose thresholds based on your change control process).
• Named ownership + backup owner for renewal actions (primary + secondary).
• A runbook that includes screenshots/paths and a post-renewal validation checklist.
• Change control notes so renewals are treated as planned maintenance, not emergencies.

What to capture for each Apple object

• Expiration date and renewal window
• Associated Apple ID and where credentials are stored/escrowed (per company policy)
• Intune tenant / environment (production vs. test)
• Where the latest exported token files are stored (secure location)
• Date of last renewal + who performed it
• Links to the renewal runbook and validation steps

Renewal validation checklist (quick)

• Push certificate: Intune shows updated expiration date; Apple device check-in works.
• ADE token: token renewed; device serial list sync completes; new serials appear after sync.
• VPP token: token updated; apps/licenses sync; app deployments succeed; updates proceed as expected.

Common pitfalls I see in the field

• Using a personal Apple ID to create the push certificate or tokens, then losing access when roles change.
• Renewing with the wrong Apple ID, breaking the ownership chain and forcing rework.
• No proactive alerts—only noticing expirations after enrollment or app delivery fails.
• No secondary owner during PTO, leading to rushed, risky renewals.
• Not documenting file storage for the downloaded token artifacts needed for renewal.

Closing thoughts

Apple migrations to Intune are very doable when you plan sequencing, communicate the reset requirements, and align licensing with the cutover strategy. But the long-term success factor is operational: treat Apple certificates and tokens like production infrastructure.

If you build a simple but disciplined renewal process—documentation, alerting, ownership, and validation—you can prevent the most disruptive “surprise outages” Apple management teams encounter.