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

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:

1. Enabled: true
2. The previously escrowed BootstrapToken (as Base64 data).
3. 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:

1. 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?

2. 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?

3. 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!