Skip to main content
Kris
Kris
Level 1.6: Donut
August 1, 2025
Question

problematic re-enrollment following smartphone reset under Android 15

  • August 1, 2025
  • 6 replies
  • 6 views

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 - KME

I 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

 

 

    6 replies

    Lizzie
    Lizzie
    Community Manager
    August 1, 2025

    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. 

    Welcome to the Community everyone!Have a question or want to start a conversation, click here.
      CoreyC
      CoreyC
      Community Manager
      August 1, 2025

      Hey @Kris,

       

      To add to what @Lizzie mentioned, here is an article about disabling FRP or enabling Enterprise FRP so your corp devices don't get locked out when erased with a personal Google account present.

        Kris
        KrisAuthor
        Level 1.6: Donut
        August 4, 2025

        Hey @CoreyC 

         

        Thank you, i read it right away.

        R
        rhj09
        Level 1.5: Cupcake
        August 1, 2025

        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.

          M
          Michel
          Level 4.0: Ice cream sandwich
          August 4, 2025

          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:

          1. Check your WS1 profiles to see if FPS is enabled, or not specifically disabled (not sure which WS1 supports). 
          2. 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. 

           

           

            M
            Michel
            Level 4.0: Ice cream sandwich
            August 5, 2025

            I just got a message from a customer with a similiar issue. Device is managed I believe with work profile, but after a reset from the device itself it activates FRP. But when wiping from Intune, this message does not appear. 

             

            Does that sounds like expected behaviour @CoreyC ?

              Kris
              KrisAuthor
              Level 1.6: Donut
              August 7, 2025

              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.

               

               

               

                Lizzie
                Lizzie
                Community Manager
                August 8, 2025

                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

                Welcome to the Community everyone!Have a question or want to start a conversation, click here.
                  Alex_Muc
                  Alex_Muc
                  Level 3.0: Honeycomb
                  August 12, 2025

                  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. 

                  Enhanced Factory Reset Protection in Android 15 | Android Enterprise and ChromeOS Customer Communities - 9493

                   

                  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.

                    Kris
                    KrisAuthor
                    Level 1.6: Donut
                    August 12, 2025

                    Hey @Alex_Muc 

                     

                    Thank you for your answer and the article. 

                     

                    I really hope to find a quick solution with Microsoft Intune and Google, because this new way of managing FRP for Android Enterprise (KME and ZeroTouch) is currently counterproductive, we had to block updates on all our devices.

                     

                    CoreyC
                    CoreyC
                    Community Manager
                    August 12, 2025

                    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.

                      Alex_Muc
                      Alex_Muc
                      Level 3.0: Honeycomb
                      August 20, 2025

                      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:

                      https://docs.omnissa.com/bundle/android-device-managementVSaaS/page/AndroidProfilesCustomDPC.html#disable_factory_reset_protection

                      Terms & ConditionsCookie settingsAccessibility statement