top of page
Search

eSIM-Only at Fleet Scale: Test This Before the iPhone Duo Lands

Writer: MacSmithAI
MacSmithAI
12 hours ago
6 min read

The iPhone Duo arrives in stores on Friday 23 October, and it is eSIM-only worldwide. Apple's own release is blunt about it: "iPhone Duo features an eSIM-only design worldwide that saves internal space to maximise battery capacity," supported by more than 500 carriers. No tray, no region exception, no fallback.


That sounds like a Duo problem. It isn't. Apple's SIM-type support page already lists every iPhone 16 model and the iPhone 17 line purchased in the United States as eSIM-only, and the same is true of the current Wi-Fi + Cellular iPads. If you are a US-based fleet, you crossed this bridge a while ago whether or not anyone wrote it down. The Duo is simply the first device that makes the gap impossible to paper over with a spare SIM from the drawer, because the drawer is now irrelevant on every model you buy.


So the useful question is not "how do we handle the Duo." It is "does our eSIM provisioning actually work at volume, and can we prove it before October." Here is what to test, what the platform gives you, and where the tooling is thinner than you'd like.


What Apple's deployment guide actually hands you

Apple documents a real MDM path for this, and it is better than most admins assume. Your management service sends a RefreshCellularPlansCommand carrying the address of the carrier's eSIM server — the SM-DP+ server — and the device downloads and activates the plan on its own. Apple's guidance says installation and activation "may take up to three minutes," and that no user interaction is required for the download and activation to complete.


Two things follow from that, and both are easy to miss.


First, the device has to be able to reach the carrier's SM-DP+ server. Apple says it plainly: ensure access to the carrier's eSIM server is available through firewalls. If your provisioning bench sits on a locked-down staging VLAN — and most staging benches do — that is the single most likely reason a pilot works on the guest network and fails in the build room.


Second, this is a network operation on a device that does not yet have cellular service. It happens over Wi-Fi, at whatever moment you choose to fire it. Which means the provisioning step is yours to schedule, and it is also yours to get wrong at scale.


The three restrictions, and what each one actually breaks

Apple's deployment documentation names three separate controls, and they do genuinely different jobs. Admins tend to reach for the first one and assume it covers the other two. It does not.


Restriction (as Apple names it)

What it stops

What it still allows

Where it bites

AllowESIMModification

Users adding or removing an eSIM themselves

Management-triggered installs - your MDM can still push a plan

The user who lands abroad and wants a local travel eSIM cannot add one

forcePreserveESIMOnErase

The eSIM disappearing when someone runs Erase All Content and Settings on the device

A user resetting their own phone and keeping service

Apple notes an MDM erase command can still clear the eSIM regardless of this setting

allowESIMOutgoingTransfers (iOS 18 / iPadOS 18 and later)

eSIM Quick Transfer moving the plan off the device

Transfers in, and normal MDM provisioning

Upgrade day - users can no longer self-serve moving their number to a new iPhone


The middle row is the one that catches people. Apple's iOS 18 enterprise notes describe the new restriction as preventing an eSIM from being removed "when a device is erased locally" — and add that an MDM erase command can still clear the eSIM regardless of the setting. So a user wiping their own phone in Settings keeps the plan; your own remote wipe does not necessarily. If your offboarding runbook ends with a remote erase, you are consuming a carrier profile every time, and somebody downstream is re-provisioning it.


Where Intune is today

Intune has a remote device action called Update cellular data plan, and on iOS and iPadOS it is generally available rather than preview. You select a device under Devices → All devices, choose the action, and supply the carrier's activation server URL. Microsoft's documentation is explicit that the device must be supervised, and lists the roles that can fire it — Help Desk Operator and School Administrator, or a custom role holding the Remote tasks/Update cellular data plan permission.


It is also explicit about the shape of the thing: this is a per-device action, not a bulk or group operation. A Mac admin walkthrough from April of this year, written while the feature was still in preview, called the workflow "fairly primitive, but functional," and that remains a fair description. You are entering a URL against one device at a time.


Do the arithmetic for your own fleet before October. Thirty pilot devices is an afternoon. Three hundred is a staffing conversation. If your refresh plans assume you can select a device group and push plans to it the way you push a compliance policy, that assumption is wrong today and you want to discover it now rather than in a stockroom.


One trap worth naming, because the search results will lead you straight into it: Intune does have a settings-catalog profile for configuring an eSIM download server, with an SM-DP+ server name field and an automatic-activation toggle. It is Windows only. It looks exactly like what you want for iPhones and it is not for iPhones. Check the platform selector before you build a profile you cannot assign.


The carrier conversation you should be having this month

Apple's deployment guide includes a list of questions to put to your carrier, and they are unusually practical for vendor documentation. The ones that matter most for a fleet:


  • After an agreement is signed, what is the time period to create and make available the eSIMs?

  • Do you support eSIM Carrier Activation, which automates eSIM installation?

  • Do you allow users to transfer eSIMs between iPhone and iPad devices?

  • What is the URL for your eSIM (SM-DP+) server?


And then the sentence that should shape your rollout plan more than any of them: Apple notes that carriers may be sensitive to the number of devices simultaneously queuing for eSIM provisioning, and asks that you notify the carrier of automated provisioning events. Read that as what it is — a warning that a 500-device imaging day can look like abuse from the carrier's side of the connection. Tell them the date. Ask what rate they can absorb. Get the answer in writing from a named person, because the helpdesk will not know.


There is a second-order question hiding in the transfer item, too. eSIM Quick Transfer is how a user moves a plan from an old iPhone to a new one in a couple of taps, and it is genuinely the smoothest part of an upgrade — right up until you restrict outgoing transfers for security reasons and nobody tells the deployment team. Decide which of those two you want before the Duo pilot units arrive, not during.


What nobody has published yet

As of 11 September 2026, Apple's eSIM deployment guide has not been updated to include the iPhone Duo. Its supported-device tables stop at iPhone Air and the iPhone 17 line. That is almost certainly just documentation lag ahead of a device that ships in October, and the Duo is an iPhone running iOS 27.1 — there is no reason to expect the MDM command or the restrictions to behave differently on it. But "almost certainly" is not the same as documented, and if you are writing a runbook this month, say which parts are Apple-confirmed and which are your reasonable inference. I have written before about what the Duo's hardware changes about provisioning and why your line-of-business apps are the bigger risk; the honest summary across all three is that the hardware is documented, the app compatibility is testable, and the enterprise management guidance is still thin.


The practical takeaway

Book a half-day this month and run one end-to-end test: a supervised device on your actual staging network, a real activation URL from your real carrier, the Intune action fired by the person who would fire it in production, timed with a stopwatch. Then wipe it and do it again. That one exercise will surface the firewall gap, the supervision gap, and the per-device throughput ceiling in a single afternoon, and all three are cheap to fix in September.


Then pick your restrictions deliberately rather than inheriting them: block user modification of eSIM settings on corporate devices, preserve the eSIM through a local erase, and make an explicit decision on outgoing transfers instead of leaving it at the default. Write down which one your offboarding process depends on.


None of this is Duo-specific work, which is the point. It is the eSIM work you already owed your fleet, with a date attached to it for the first time.



Comments

bottom of page