Apple Return to Service: remotely reset and re-enroll iOS and iPadOS devices
Return to Service is an Apple feature that lets a Mobile Device Management (MDM) platform remotely erase an iOS or iPadOS device and automatically re-enroll it, with no cable, no setup wizard, and no one touching the device. Introduced with iPadOS 17 and iOS 17, it turns a manual job — wiping a device, then walking it through Setup Assistant — into a single remote command. It has since gained two significant upgrades: managed-app preservation in the iOS 26 line, and software-update enforcement plus user-initiated resets in the iOS 27 line. This guide covers what it does today, how the workflow runs, the requirements and limits, and where it fits.
It is written for IT and device-management teams running Apple fleets, especially shared and dedicated devices. One clarification first: Return to Service is about bringing a device back into service in your management, wiped and re-enrolled, typically for reuse or reassignment. It is related to, but different from, MDM migration, which moves devices between MDM platforms. This guide covers Return to Service; migration is covered separately, and the differences are outlined below.
What Return to Service is
Return to Service is an MDM erase action for iOS and iPadOS devices. In Apple’s description, MDM sends an erase command that includes Wi-Fi details and an optional MDM enrollment profile, so the device erases its data and automatically returns to the Home Screen, ready for use. Instead of wiping to a setup screen that waits for a person, the device wipes and brings itself back into service on its own (Apple Support, Use Return to Service for Apple devices)
The practical effect is that a device can be reset and re-enrolled fully remotely. It reconnects to Wi-Fi using the supplied profile, skips the setup screens, and re-enrolls in management, arriving at the Home Screen configured and managed with no hands-on steps. Industry commentary on the 2026 and 2027 releases underlines how much Apple has invested in this workflow for managed fleets.
A supervised iPhone can be forced to install a pending update when it receives a Return to Service erase command, the same command used to wipe and reprovision a device for a new user.
Ionut Soare, Senior Product Manager
How it differs from a normal erase
Every iOS device already has the Erase All Content and Settings option, and MDM has always been able to trigger it remotely. The difference is what happens after the wipe. A standard remote wipe returns the device to its out-of-the-box state and leaves it at the Setup Assistant, where it waits for someone to choose a language, connect to Wi-Fi, and complete enrollment. On a shared or unattended device, a person must physically pick it up to complete the setup.
Return to Service adds automation on top of the erase: it preserves language and region, reconnects to Wi-Fi using the assigned profile, skips the setup screens, and automatically re-enrolls in MDM, arriving at the Home Screen, managed and ready. A normal erase is half the job; Return to Service is the whole job. The diagram makes the difference concrete: the normal path needs a person at three steps; the Return to Service path needs none.
How Return to Service works
The workflow runs through the MDM and Apple’s activation infrastructure. At a practical level, it proceeds in four steps.
1. MDM sends the Return to Service erase command. From the MDM console, IT issues the erase with Return to Service enabled, attaching the Wi-Fi configuration profile and, where required, the MDM enrollment profile.
2. The device erases and reboots. The device securely erases the previous user’s data and restarts. On iOS 26 and later, when app preservation is configured, managed app binaries can be retained (see below), which speeds up redeployment.
3. It reconnects and checks its assignment. On reboot, the device connects to the internet using the supplied Wi-Fi profile and contacts Apple’s activation servers to check which MDM it is assigned to.
4. It re-enrolls automatically. Based on its Apple Business Manager (or Apple School Manager) assignment, the device re-enrolls in the MDM, applies its configuration, and arrives at the Home Screen, managed and ready, with language, region, and Wi-Fi already configured.
New in iOS 26: Return to Service can preserve managed apps
The most important recent change is that Return to Service no longer requires a full wipe. On devices with iOS 26, iPadOS 26, and visionOS 26, Return to Service can preserve managed apps: it securely erases the previous user’s data, but the managed app binaries remain, so the device does not have to re-download every app after the reset. Apple’s stated purpose is to make the process even faster (Apple Support, What’s new for enterprise in iOS 26)
For shift-based and high-turnover environments, this is a meaningful improvement. A shared iPad reset between users keeps its managed apps in place and clears only personal data, reducing both the time and network bandwidth needed to get the device ready for the next user. App preservation requires the device to be enrolled through Automated Device Enrollment. Note that while app preservation is active, software and app updates are applied only during a reset, so plan a usage pattern that includes regular resets.
New in iOS 27: enforced updates and user-initiated resets
The iOS 27 line corrects a limitation that used to be worth calling out: that Return to Service did not update the OS. It now can. On supervised devices with iOS 27, iPadOS 27, and visionOS 27, IT teams can enforce a software update as part of the Return to Service erase command; the device performs the update and then continues with re-enrollment. This means a device can be reset, updated to a required OS version, and re-enrolled in a single workflow (Apple Support, What’s new for enterprise in iOS 27)
The iOS 27 line also adds two ways to start the process without an admin having to send a command. A user can initiate Return to Service from Control Center, and IT can configure the device to launch Return to Service automatically after a set period of inactivity using a session-timeout setting, which is suitable for shared devices that should reset themselves between sessions. A new enrollment-retry option also lets the device retry, with an increasing delay, if the first re-enrollment attempt fails on a transient network or service error (Apple Support, WWDC26 device management updates)
One related change worth knowing during planning: with the 27.0 releases, Apple removed the legacy software-update management commands entirely, so declarative software update management is now the only way to configure and enforce updates outside the Return to Service path. If your update workflows still rely on the old commands, that migration is now mandatory.
Normal erase vs Return to Service vs Return to Service with app preservation
The table compares the three ways to reset a managed Apple device, so the right one is clear for a given scenario.
| Factor | Normal erase (EACS) | Return to Service | Return to Service with app preservation |
|---|---|---|---|
| After the wipe | Stops at Setup Assistant, waits for a person | Auto-reconnects and re-enrolls, no setup screens | Auto-reconnects and re-enrolls, no setup screens |
| User data | Erased | Erased | Securely erased |
| Managed app binaries | Removed, re-downloaded after enrollment | Removed, re-downloaded after enrollment | Preserved, not re-downloaded |
| Re-download time and bandwidth | Full re-download | Full re-download | Reduced, apps already present |
| OS version | Unchanged | Unchanged (iOS 26 line) | Can be enforced during reset (iOS 27 line) |
| Requires | MDM erase command | iOS/iPadOS 17+, Wi-Fi profile, Activation Lock off | iOS/iPadOS/visionOS 26+, Automated Device Enrollment |
| Best for | One-off wipe where re-setup is acceptable | Recycling shared or dedicated devices | High-turnover shared fleets needing fast turnaround |
Requirements and limits
Return to Service is powerful but conditional; the conditions determine whether it runs cleanly or falls back to manual steps.
iOS or iPadOS 17 or later, with the newer features on 26 and 27. Return to Service requires iOS or iPadOS 17 or later; tvOS 18 or later. Managed-app preservation requires the iOS 26 line and Automated Device Enrollment; enforced software updates and Control Center initiation require the iOS 27 line on supervised devices.
Activation Lock must be disabled. A device with Activation Lock still enabled will not complete the automatic re-enrollment, which is one of the most common reasons the workflow stalls. Managing Activation Lock across the fleet, so it can be cleared when a device is reset, is a practical prerequisite (Apple Support, Use Return to Service for Apple devices)
A Wi-Fi profile must be assigned. Automatic re-enrollment depends on the device reconnecting to Wi-Fi on its own, so a Wi-Fi configuration profile must be assigned and the network reachable. Without one, the device stops at the network-selection screen and requires manual input, breaking the hands-free flow.
Automated Device Enrollment and supervision give the cleanest result. Return to Service works best on supervised devices enrolled through Apple Automated Device Enrollment via Apple Business Manager, and app preservation requires it. For unsupervised or non-ADE devices, the MDM enrollment profile must be included in the command.
It erases user data. Return to Service erases the previous user’s data. With app preservation, it keeps managed app binaries while still clearing personal data, making it suitable for shared and dedicated devices but unsuitable for an individual-use device unless that data is backed up. It is a reset feature, not a preserve-user-data feature.
Return to Service vs MDM migration
These two Apple capabilities are easy to confuse because both involve re-enrolling managed devices. They solve different problems. Return to Service resets a device and brings it back into managed service, primarily to recycle shared and dedicated devices between users, and it is designed to erase user data. MDM migration moves devices between MDM platforms. On iOS 26, iPadOS 26, and macOS 26, Apple added a native migration that reassigns eligible devices to a new MDM via Apple Business Manager without erasing them, preserving user data and apps.
The simple rule: use Return to Service to recycle a shared or dedicated device back into service (erasing user data, optionally keeping managed apps), and use non-wipe migration to move company-owned devices between MDM platforms without erasing them. Different jobs, different tools.
Putting Return to Service to work in a shared-device fleet
Return to Service is an Apple feature, and what an MDM adds is the ability to drive it at fleet scale: issuing the erase with the right Wi-Fi and enrollment profiles, deciding per device group whether to preserve managed apps, and, on the iOS 27 line, attaching an enforced software update so devices come back both reset and current. The value shows up most in shared-device operations, retail iPads reset between shifts, ward tablets handed between clinicians, kiosks returned to their locked role, where the difference between a manual re-setup and a hands-free reset is multiplied across every device, every day.
For a mixed fleet, that Apple workflow sits alongside the equivalent lifecycle actions on other platforms, and the practical question when choosing an MDM is whether it exposes Return to Service cleanly: app-preservation control, Wi-Fi and enrollment profile handling, Activation Lock management, and the iOS 27 update-enforcement option. Bento MDM manages Apple, Android, and Windows devices from a single console; for a fleet with shared or dedicated Apple devices, confirming how the MDM handles Return to Service and the iOS 26 and 27 enhancements is a reasonable part of that evaluation.
Frequently Asked Questions
It depends on the OS line, and this changed recently. On the iOS 26 line, Return to Service re-enrolls on the existing OS version. On supervised devices on the iOS 27 line, IT can enforce a software update as part of the Return to Service erase command, so the device resets, updates to the required version, and re-enrolls in a single workflow. If you need devices on a common version, the iOS 27 behavior lets Return to Service handle it; on earlier versions, the update is separate.
Not necessarily, as of iOS 26. With app preservation configured on iOS 26, iPadOS 26, or visionOS 26 (and Automated Device Enrollment), Return to Service securely erases the user’s data while retaining the managed app binaries, so the apps do not need to be re-downloaded, which speeds up the reset and saves bandwidth. Without app preservation, or on earlier OS versions, the apps are removed and re-downloaded after re-enrollment.
On the iOS 27 line, yes. A user can initiate Return to Service from Control Center, and IT can configure a device to launch it automatically after a set period of inactivity, which is suitable for shared devices that should reset themselves between sessions. On earlier OS versions, Return to Service is initiated only by an MDM erase command from IT.
Activation Lock ties a device to a personal Apple Account and blocks reactivation without those credentials, so a device with it still enabled cannot complete the automatic re-enrollment that Return to Service depends on, which is a frequent cause of the workflow stalling. Managing Activation Lock through your MDM, so it can be cleared when a device is reset, is what keeps Return to Service reliable across a fleet.
Related Articles
