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 ReturnToService 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!

I have experience a similar issue and the reason was due to incorrect or mismatch in the BootstrapToken. I think using the base64 encoded token would probably solve this.