Return to Service with App Preservation - Missing "Get Bootstrap Token" Request

Question

aravindraj OP

Created 3w

Replies 1

Boosts 2

Participants 1

Hello Apple Developer Community,

I am implementing the "Return to Service" feature with app preservation in our MDM solution (iOS 26+).

My goal is to use the EraseDeviceCommand to securely erase user data while preserving managed apps, and then have the device automatically re-enroll without user interaction.

What I am doing:

The device is supervised and successfully enrolled in Automated Device Enrollment (ADE).
The device has generated and escrowed a bootstrap token to our MDM server (SetBootstrapToken received).
I am sending the EraseDeviceCommand to the device via MDM with the necessary parameters for Return to Service with app preservation.

The command payload includes:

Enabled: true
The previously escrowed BootstrapToken (as Base64 data).
WiFiProfileData (as Base64 data) to ensure connectivity post-erase.

Example Payload Structure (Simplified):

<key>ReturnToService</key>
<dict>
    <key>Enabled</key>
    <true/>
    <key>BootstrapToken</key>
    <data>YOUR_BASE64_TOKEN</data>
    <key>WiFiProfileData</key>
    <data>YOUR_BASE64_WIFI_PROFILE</data>
</dict>

The observed behavior:

The erase command is successful.
The device performs the secure user data erase.
Crucially, the managed applications are preserved and automatically installed again after the reboot (confirming app preservation is working).
The device connects to the Wi-Fi network successfully.

The issue: I am not seeing the GetBootstrapToken request from the device hit our MDM server's check-in URL during the post-erase setup assistant phase. The re-enrollment seems to complete, but this specific request is missing from our server logs.

My questions:

Is the GetBootstrapToken request an explicit check-in message type, or is it an implicit part of the general CheckIn process during ADE re-enrollment when the token is used?
If the device successfully re-enrolls and preserves apps, is the explicit GetBootstrapToken request still expected? Or does the token included in the EraseDeviceCommand payload satisfy all authentication needs for this workflow?
What specific conditions or capabilities on the MDM server side might prevent the device from sending this specific request, even if the overall process succeeds?

Any insights from Apple engineers or other developers who have successfully implemented this flow would be greatly appreciated.

Thank you!

Boost

Answer 1

aravindraj OP

1w

Hello everyone,

I am implementing ReturnToService (RTS) with app preservation on iOS 26+ via MDM. I have successfully achieved the functional workflow: the device erases, the WiFiProfileData works, and managed apps are preserved and re-installable post-boot.

However, I have noticed a distinct difference in the log flow between a standard ADE enrollment and an RTS re-enrollment, specifically regarding the Bootstrap Token.

The Observation: In our standard ADE flow, we typically observe a sequence involving token escrow. In the RTS flow:

We send EraseDevice with the <key>ReturnToService</key> dictionary.

We include the current valid BootstrapToken in that payload to authorize the reset.

The device wipes, reboots, and reconnects.

Anomaly: The device does not issue a GetBootstrapToken request to the MDM server during the Setup Assistant/Re-enrollment phase.

The device eventually generates a new token and sends SetBootstrapToken later in the lifecycle.

My Hypothesis: Since the EraseDevice command payload already contained the valid BootstrapToken (passed as Base64 data) to authorize the RTS, does the device implicitly trust the MDM for the subsequent re-enrollment, thereby suppressing the need to fetch (Get) the token again during the initial check-in?

The Question: Has anyone verified if GetBootstrapToken is deprecated or intentionally skipped in the RTS + App Preservation flow? I want to ensure that the absence of this request doesn't indicate a failure in the "Chain of Trust" or Volume Ownership establishment, even though the device appears to be functioning correctly.

Any confirmation on the expected log sequence for RTS would be helpful.

Thanks!

1