Forum Discussion
problematic re-enrollment following smartphone reset under Android 15
Hey Everyone,
Since a couple of weeks, we are encountering a problem with the re-enrollment of devices that have moved to Android 15.
our employees arrive on the next screen :
Motorola G54 5G - Zero TouchSamsung Galaxy A35 Android 15 - KMEI reproduced the incident under the following conditions :
Step 1 , the device is enrolled on Omnissa WSP1 in COBO with personnal Google Account
Step 2 , for some reasons, the device is erased (example : 10 errors code)
Step 3 , the profil in KME or Zero Touch is Microsoft Intune & no more Omnissa
Step 4 , It seems that the KME or ZERO Touch verification did not happen at the right time.
Step 5 , our employees have to proove the use of the device like a personal device !
We didn't encounter this problem for devices in Android 13 or 14.
The devices i used :
Motorola g54 5G
Android 15
V1TDS35H.83-20-5-5
security patch : 1 july 2025
Samsung A35 - SM-A356B
Android 15
AP3A.240905.015.A2.A356BXXS5BYF3
security patch : 1 july 2025
We have several thousand devices left to migrate to Microsoft Intune, this new enrollment behavior is unacceptable for 100% company devices.
Our fleet is fully managed in KME or Zero Touch.
Can you investigate this incident?
Chris
16 Replies
Hey Kris,
I hope you are doing well and having a good summer. Sorry to hear this is causing a bit of a headache.
First thought here was whether you might have Factory Reset Protection enabled, but that shouldn't be the case I don't think - so something isn't quite right.
Have you spoken with your EMM about this? If so do you have a open ticket(s) you might be able to share privately?
Also, if anyone else has any suggestions on this, before a deeper dive please do share. Thank you.
Hey Lizzie
I hope you are doing well too and having a wonderfull summer like me.
I confirme we dont have Factory Reset Protection enabled.
It is really a before and after the devices take Android 15. I look with my EMM if i can open tickets.
Thank you so much for the speed of your response.
Kris
Hey Chris,
I'm not a Google rep, just sharing based on experience, but it looks like you're hitting an issue related to how Android 15 handles factory reset and re-enrollment timing for fully managed devices.
From what you've described, it seems that after the reset, the Zero Touch or KME profile isn't kicking in before setup finishes, causing the device to default to personal setup instead of enforcing corporate enrollment via Intune.
A few thoughts:
- This issue may be tied to Android 15's tightened factory reset protection or setup flow changes, especially around managed provisioning.
- Double-check if the Zero Touch or KME profiles are still correctly assigned to the device IMEIs after reset. Sometimes they get unassigned if a factory reset is triggered unexpectedly.
- You might try reapplying the Intune profile in KME/Zero Touch before re-enrollment and make sure the device is connected to a network with unrestricted internet access at the very beginning of the setup.
- Also, check with Omnissa (formerly Workspace ONE) to confirm if Android 15 introduced a change that affects the COBO to Intune transition path.
You're right, this shouldn't be happening on a fully managed fleet. I’d recommend reporting this to both Google and the EMM providers (Intune and Omnissa) to escalate further. Android 15 is still new in some environments, and this might be a regression or provisioning timing issue.
Hope this helps point you in the right direction. Good luck with the migration.
Just to be sure I understand correctly:
You are trying to move devices from WS1 to Intune, part of that process is a reset and after that reset, you are prompted with the pincode?
If so, i'm pretty sure this is not done by Intune or your ZTE profile and portal. My first guess would indeed be factory reset protection enabled. I can think of two options to check first:
- Check your WS1 profiles to see if FPS is enabled, or not specifically disabled (not sure which WS1 supports).
- Are you sure it's cobo/fully managed? Not byod? If you are sure, than FPS is disabled by default when enrolling with ZTE and an MDM. So it would have to be enabled via a profile setting.
Hi Michel
I confirm, with Android in my company, Enrollment is done exclusively with KME or ZERO Touch.
Until Android 14, the risk of losing devices due to accidental wipe (10 bad codes) was zero.
With Android 15 and Android 16, FRP is activate with accidental reset from the device ! So if employees are unable to remember the code or their Google account (yes it's possible...), the device is a nice brick.
It is the device boot process that has completely changed (following an accidental reset) :
-> until Android 14, the device asks to connect to wifi then it immediately checks ZTE or KME, and it goes to enrollment.
-> since Android 15, the device asks to connect wifi then it asks the personal code and after it goes to enrollment.
Lizzie CoreyC i can try to open tickets with Microsoft or Omnissa, but i really dont believe it is done by the EMM.
Hey Kris,
Thanks for this.
I know it sounds a bit long-winded to go to your partner when it is likely directly on the Google side - unless we see a lot of people in the community experiencing the same issue. We would generally always recommend that you open a ticket with your EMM or reseller first because they have the ability to take a deep dive into your setup. They then have the processes in place to escalate it to a Google engineer on our end for further investigation.
Please feel free to share the ticket with us (privately) and we can highlight this to our internal team who work with our partner engineering teams directly.
Hopefully we can get to the bottom of what is happening here pretty quickly.
Thanks so much and speak soon.
Lizzie
I'm a little late to the party on this one.
Android 15 introduced changes to Factory Reset Protection. With Android 15, FRP has been integrated “deeper into the system.” In the past, the setup wizard took care of FRP, but it could be circumvented by third parties with a few tricks.
The FRP can be seen in the photos in the post. It can be recognized by the lock icon in the upper left corner.
Up to and including Android 14, KME was able to remove the FRP. The KME client removed the FRP flag from the device before enrollment when resetting the device. This no longer works as of Android 15.
Before Android 15, it was ideal that a tool for automatic business enrollment could remove these tags. Now, FRP protection must be enforced with admin accounts via MDM policy, otherwise you need the device passwords that users had assigned.
Although the FRP only intervenes when devices are reset to factory settings via unusual methods, unfortunately, devices are often returned in a switched-off state, still enrolled, and unable to be reset via normal methods.
Thanks Alex_Muc!
Good find I forgot about those changes in 15.
Kris just to clarify, Zero Touch is not meant to "manage FRP". The recommended method for managing FRP is to use the enterprise FRP controls.
To all customers with Omnissa WorkspaceONE:
Factory Reset Protection can be disabled for devices. The configuration does not help with devices that are already locked. But it does help prevent devices from ending up in FRP.
Requirements:
- Android 11 or higher
- WS1 Hub 24.09+
- CustomDPC (not AMAPI)
Currently, a profile with custom settings must be created for this purpose.
Custom settings:
<characteristic type="com.airwatch.android.androidwork.app:com.google.android.gms" uuid="352d91a3-c4de-4821-b01d-f450ca474ba5"> <parm name="disableFactoryResetProtectionAdmin" type="boolean" value="true"/> </characteristic>Source:
