Return to Service: wipe and auto re-enrol iPhones with zero touches

Since iOS 17, an MDM erase command can carry a Wi-Fi profile through the wipe, skip every Setup Assistant screen and re-enrol the device automatically. If you are still hand-configuring recycled iPhones between users, this is the feature nobody told you about.

The problem

You run a pool of shared or high-turnover iPhones or iPads — frontline workers, wards, classrooms, retail counters, loaner stock. Every time a device changes hands, someone on the helpdesk does the same ritual: erase it, wait, pick a language, join Wi-Fi by hand, click through Setup Assistant screen by screen, wait for MDM re-enrolment, then check the apps came back. Minutes of hands-on human attention per device, multiplied by every handover, forever.

The frustrating part: since iOS 17 (September 2023), Apple's MDM protocol has been able to do the whole cycle unattended. A single command wipes the device, carries a Wi-Fi profile through the erase, skips Setup Assistant entirely and re-enrols the device into MDM with nobody touching the screen. It is called Return to Service, and a surprising number of admins — particularly in Intune-centred shops — have never heard of it.

Why it happens

Historically, an erase was a point of no return for automation. Wiping a device destroyed everything, including its Wi-Fi credentials — so a freshly erased iPhone could not talk to anything until a human joined it to a network in Setup Assistant. Automated Device Enrollment (ADE) automated the enrolment step, but activation still needed connectivity, and connectivity needed fingers.

iOS 17 changed the protocol. The MDM EraseDevice command gained a ReturnToService dictionary that can carry payloads which survive the erase:

• WiFiProfileData — a Wi-Fi profile that persists through the wipe, so the device reconnects and activates on its own. Apple's deployment guide is explicit: "The Wi-Fi profile is required to activate the device, unless it has other means of connecting to the internet."
• MDMProfileData — enrolment details for profile-based deployments. Devices registered in Apple Business Manager or Apple School Manager can omit this; their enrolment comes back automatically via ADE.

After the erase, the device restores its previous language and region, reconnects using the persisted Wi-Fi payload, and — in ManageEngine's words — "bypasses all setup assistant screens", re-enrols into MDM and lands on the Home Screen.

So why do so few Intune shops know it exists? Because Return to Service is a protocol-level capability: you only see it if your MDM builds an interface for it. Third-party Apple MDMs (SimpleMDM, Miradore, ManageEngine MDM Plus, and others) expose it as a wipe option. Microsoft Intune's documented Wipe action for iOS/iPadOS, at the time of writing, exposes only the eSIM data-plan choice — no Return to Service toggle — so admins who live in the Intune console simply never encounter it.

The fix

1. Check the prerequisites

• iOS/iPadOS 17 or later on the device.
• Managed, supervised fleet — in practice this is an ADE feature: devices enrolled through Apple Business Manager / Apple School Manager get it with the least friction, and supervision is re-applied on re-enrolment. Profile-based deployments can work, but the erase command must then supply the enrolment details via MDMProfileData.
• Activation Lock disabled. An Activation-Locked device stops at activation and the automation dies there.
• A Wi-Fi profile to persist, and the device physically in range of that network — or another route to the internet (a supported wired-ethernet adapter, or an active cellular plan).

2. Issue the wipe with Return to Service

In an MDM that supports it, Return to Service appears as an option on the wipe/erase action: you select the Wi-Fi profile to carry through the erase (and, for non-ADE devices, the enrolment profile). That is the entire admin-side workflow — one action instead of a hands-on rebuild.

3. Know what to expect

• The device erases, reconnects using the persisted Wi-Fi payload, skips Setup Assistant, re-enrols and arrives at the Home Screen. ManageEngine's documentation cites roughly 15–20 minutes from reset initiation to an operational device.
• If the process is interrupted — say the device powers off — it resumes automatically on restart.
• Language and region are preserved from before the wipe.
• Whether an eSIM survives is governed by the PreserveDataPlan key on the erase command.

4. Mind the gotchas

• Apple ID is not restored. Apps distributed outside VPP/Apps and Books that need a personal Apple ID will require a manual sign-in afterwards.
• Supervision is re-applied. Do not use Return to Service on a device you are trying to release from management — it will come straight back enrolled.
• App preservation is newer than the base feature. On iOS/iPadOS/visionOS 26 or later, ADE-enrolled devices can preserve managed apps through the erase: the device snapshots the system volume after managed apps install, and subsequent wipes restore the snapshot instead of re-downloading everything. Per Apple, only the app executables are preserved — "the device… always erases all locally stored user-generated data for the app." On iOS 17–18, expect managed apps to re-download after each cycle.

5. If you are on Intune

• At the time of writing, Intune's documented Wipe action for iOS/iPadOS does not expose Return to Service. The nearest low-touch equivalent today: ADE enrolment with every skippable Setup Assistant pane disabled, plus wired ethernet (via adapter) or cellular so activation proceeds without a human joining Wi-Fi.
• Microsoft publishes its Apple-platform plans after each WWDC — watch the Intune What's new and In development pages for Return to Service support before assuming you need a second MDM.

How Decolla handles it

Straight answer: it doesn't. Decolla provisions Windows devices over your own Intune and Autopilot tenant — it does not send Apple MDM commands and will not wipe or re-enrol an iPhone. Return to Service lives entirely in your Apple MDM stack, and the steps above are everything you need.

The reason this article sits in our knowledge base is that the underlying lesson is exactly the one Decolla is built on: the most valuable capabilities are often protocol- or platform-level features that nobody surfaces, so fleets keep paying a per-device human tax that stopped being necessary years ago. On the Windows side of your estate, Decolla's approach to reprovisioning mirrors what Return to Service does for iOS: you define a build once through a wizard against a curated catalogue of 260+ items across 21 sections; Decolla produces a written, itemised plan — delivery method and reversibility class stated per item, with anything irreversible flagged — which you approve before anything runs; deployment then executes unattended in your own tenant, and Decolla can roll back its own changes item by item.

That catalogue is backed by the Library: pre-built, industry-tested policies, scripts and fixes — including the recurring helpdesk fixes and built-in hardening that, like Return to Service, most teams never discover on their own. Decolla is pre-launch; if the Windows half of this problem sounds familiar, the waitlist is open at decolla.app.

Sources

• SimpleMDM — Return to Service
• Miradore — Return to Service for iOS and iPadOS
• ManageEngine MDM Plus — iOS Return to Service
• Apple Platform Deployment — Use Return to Service for Apple devices
• Apple Developer — Returning a managed device to service
• Microsoft Learn — Intune Device Action: Wipe