Rolling Out eSIM Across a Corporate Fleet: An MDM Guide

Every vendor pitch for enterprise eSIM sounds the same. Push a profile from your MDM, the device activates itself, nobody touches a SIM tray again. That part is true, and it genuinely works well on day one.

The part that doesn’t make the pitch deck is what happens on day two hundred, when a device gets lost, an employee leaves, or someone’s phone dies under warranty and needs replacing. That’s where most of the real planning for a fleet rollout actually needs to go, and it’s the part this guide focuses on.

The short version eSIM profiles are typically bound to one device’s EID and downloadable only once. You can’t just reassign a profile to a replacement device — a fresh carrier-issued profile is required. Wiping a device through your MDM doesn’t automatically cancel its eSIM subscription. Device-side and carrier-side deprovisioning are two separate steps, and skipping the second is how fleets end up paying for phantom lines. Android 16 changed BYOD behaviour: managed eSIM profiles are now always wiped when a work profile is removed from a personally-owned device, with no policy override. Apple’s mechanism runs on a single MDM command, Refresh Cellular Plans. Android’s depends on whether the device is fully managed or running a work profile.

What an eSIM fleet rollout actually involves

Underneath the zero-touch marketing, an MDM eSIM deployment has three moving parts. A carrier or eSIM management platform holds your organisation’s data plans and a directory of device identities. Your MDM — Jamf, Intune, or an Android Enterprise-compatible platform — holds your device inventory and pushes configuration commands. And a per-device identifier called the EID (eUICC ID) is what links the two together, telling the carrier which physical chip is allowed to download which profile.

Zero-touch provisioning is what happens when those three pieces are already connected before a device reaches an employee’s hands. The carrier has the EID on file, the MDM has a command queued, and the device downloads and activates its profile the moment it’s turned on.

The step everyone underestimates: EID registration lead time

Getting to that zero-touch moment requires collecting every device’s EID and registering it with your carrier’s eSIM platform before rollout, not during it. For a handful of devices, that’s trivial. For a five-hundred-device rollout across a hardware refresh cycle; it’s a procurement-stage task that needs its own timeline, coordinated with whoever is purchasing and provisioning the devices.

On Apple hardware, this is handled through Automated Device Enrollment and Apple Business Manager, which can supply EIDs to your MDM as part of standard device enrolment. On Android, EID retrieval is handled through the Android Management API. Google extended specifically for eSIM workflows starting with Android 16. Administrators can pull EID values for enrolled devices without physically touching them. This is what makes an at-scale rollout realistic in the first place.

Apple fleet mechanics: one command, a few real constraints

Apple’s process is genuinely simple at the mechanical level. Your MDM sends a single command — Refresh Cellular Plans — along with the address of the carrier’s SM-DP+ server. The device contacts that server, downloads its profile, and activates, typically within about three minutes.

Two constraints matter more than the simplicity suggests. First, Apple’s own deployment documentation is explicit that an eSIM profile assigned to a device is effectively single-use. Once it’s been downloaded once, it’s consumed and won’t retry, even if the download partially failed.

A lost, stolen, or hardware-replaced device needs a fresh profile issued from the carrier side, not a repeat of the same MDM command. Second, an allowESIMModifications restriction lets admins block end users from installing, transferring, or deleting eSIMs themselves. It’s worth setting deliberately, since the default behaviour otherwise leaves that door open.

Android fleet mechanics: it depends on the enrolment mode

Android’s eSIM management differs meaningfully depending on how a device is enrolled. On a fully managed, corporate-owned device, your MDM has broad control over the eSIM lifecycle, including whether a profile survives a remote wipe. On a device running a work profile — the common BYOD or COPE setup, where a personal device carries a separate managed container — the rules are stricter and, as of Android 16, non-negotiable.

Specifically, Android 16 introduced platform-enforced behaviour where a managed eSIM profile is always removed the moment a work profile is deleted from a personally-owned device, regardless of what your MDM policy says. That’s a meaningful design choice. Google is treating a corporate-provisioned data plan on someone’s personal phone as something that must not outlive the management relationship, full stop.

Android 13 also introduced Multiple Enabled Profiles (MEP), letting a single eUICC chip run more than one active profile at once. In practice, that means a single Android device can carry a personal profile and a corporate profile simultaneously, without dual-SIM juggling or a physical card. A genuinely useful option for BYOD policies that want a clean split between personal and work connectivity on one chip.

The gap nobody prices into the rollout: offboarding versus deprovisioning

This is the part worth building a checklist around specifically. Remote-wiping a departing employee’s device through your MDM removes the data and the management profile. It does not, by itself, cancel the underlying carrier subscription that the eSIM was drawing on.

Apple’s own guidance notes that eSIMs can be configured to persist through an Erase All Contents and Settings action, precisely so a device can be handed to a new user without a fresh install. That’s a genuine convenience for reissuing hardware and a genuine cost risk if the same behaviour applies to a device that’s leaving the fleet entirely rather than being reissued.

The subscription only actually stops when someone deprovisions it on the carrier or eSIM management platform side. On a large fleet, that’s a second checklist item, owned by whoever manages the carrier relationship, not just IT support.

A practical rollout checklist

1. Confirm your carrier or eSIM management platform supports MDM-based provisioning (SM-DP+ access, EID-based activation) for every country your fleet actually travels to or operates in.
2. Build EID collection into your device procurement or refresh process, not as an afterthought once devices are already with users.
3. Set eSIM-specific restrictions deliberately — allowESIMModifications on Apple, equivalent Android Enterprise policies — rather than relying on defaults.
4. Document, separately from your MDM offboarding runbook, who owns carrier-side deprovisioning and on what trigger it happens.
5. Plan for device replacement as a routine event, not an exception: confirm with your carrier how quickly a fresh profile can be issued for a lost, stolen, or RMA’d device.
6. For BYOD/COPE Android fleets, decide deliberately between a work-profile split (simpler policy, Android 16’s forced-wipe behaviour on removal) and Multiple Enabled Profiles (more flexible, more setup).
7. Pilot with a small device group across both platforms before committing to a full rollout timeline — the mechanics above tend to surface fastest in a pilot, not a spec sheet.

Where a lighter-weight option fits

Everything above assumes a genuine fleet relationship: a carrier account, EID registration, and an MDM policy built around it. That’s the right setup for a large, stable fleet. But it’s a heavy lift for a smaller team, a pilot program, or a group of employees who travel internationally more often than the rest of the company.

For that lighter-weight layer — business travellers who need working data the moment they land, without a carrier contract or MDM integration behind it. A self-serve travel eSIM is often the more practical starting point, installed directly by the traveller rather than pushed by IT. BazTel’s business and travel eSIM plans work this way: no carrier account or MDM integration required. It makes them a reasonable fit for a pilot or for travellers outside the scope of a full fleet deployment. Though not a replacement for the MDM-integrated setup described above once a fleet reaches real scale.

Frequently asked questions

What is eSIM MDM deployment?

It’s the practice of provisioning and managing eSIM profiles on a device fleet through a mobile device management platform. It uses each device’s EID to link it to a carrier’s eSIM system. Hence profiles can be pushed, restricted, or removed remotely rather than configured by hand.

Can an eSIM profile be reassigned to a replacement device?

Not directly. Most eSIM profiles are single-download and tied to the device’s EID. A replacement device needs a fresh profile issued from the carrier or eSIM management platform. Not a repeat of the original activation.

Does wiping a device remove its eSIM?

Not automatically. A remote wipe through your MDM can be configured to retain the eSIM profile, and often is, by design, so a device can be handed to a new user. Fully cancelling the subscription requires a separate deprovisioning step on the carrier side.

How does eSIM provisioning work with Apple Business Manager?

Apple Business Manager supplies device EIDs to your MDM as part of enrolment. The MDM then sends a Refresh Cellular Plans command with the carrier’s SM-DP+ server address, and the device downloads and activates its profile, typically within a few minutes.

Does Android support eSIM management through an MDM?

Yes. Android Enterprise supports eSIM management through the Android Management API, extended for eSIM workflows from Android 16 onward, though the exact controls available depend on whether the device is fully managed or running a work profile.

What happens to a managed eSIM when a BYOD device is unenrolled?

On Android 16 and later, a managed eSIM profile is always removed the moment a work profile is deleted from a personally-owned device. This is enforced by the platform and isn’t controlled by MDM policy.