The COPE use case that you are referring to is an interesting one and somewhat of a moving target with each version of Android. I have not deployed a COPE environment myself but it definitely sounds like the personal account in the Work Profile is still triggering the FRP. SOTI should likely do a better job of handling a cleaner unenrollment procedure automatically. How are you wiping the devices? Are you unenrolling them from SOTI first while the devices are connected or are you wiping them through some other procedure? Does MobiControl offer the controls to delete or remove the Work Profile prior to the unenrollment?

Hi Matt, 

Thanks for your answer, we did a few tests, we normally wipe the devices (being connected) from Mobicontrol Webconsole and we check the option ''Bypass Factory reset protection''. There's an option in the Devices overview (webconsole) to disable or enable the work profile

Hi Daniel,

I did my tests with corporate personal mode on Samsung A51 running Androd 10 with a MobiControl v15.3.0 server, and everything related to wipe with or without bypassing factory reset protections seems to be behaving as expected.

Frankly speaking, based on your description in earlier posts,  I am not 100% sure how you did your tests and your test results.  So I can't say if there was really problem in your case, or whether you misinterpreted your own test results.  Perhaps some clarifications from your side can give a better picture.

What was the Android firmware version running on your Samsung S9?

Before you initiated wipe action in your tests, had your checked the active MDM API's reported in your device agent for the string "Corporate Personal"  to confirm that it was actually enrolled in "corporate mode"?

If so,  did you add a personal google account in your perosnal space? Or any personal account in your work space? Or both?

Had you deployed any Enterprise Factory-Reset Protection profile payload to your test device before you initiated the wipe operation?

Hi Raymond,

As a test, I logged in playstore in the personal container of the device with a test gmail account. Then I wiped the device from the mobicontrol webconsole (device actions). After it rebooted, in the initial steps it warns me that there's been an attempt of factory reset in the mobile and asked me to use the account that synced with this device. I used the test account and it let me continue the steps. It should instead ask me the corporate account that's in our binding.

The MDM API is showing Corporate Personal, the firmware is G960WVLS9FUA1.

It's not possible to add personal account in the work container as we restricted it in the feature controls.

When a device is enrolled, a security profile is pushed and enables a factory reset protection as shown in the image below. The account allowed to unlock the device is the same as our Managed Google Play account.

Hi Daniel,

The screenshots in your last post does confirm that your test device was in AE Corporate Personal mode and your use of Enterprise-FRP. 

Firstly, I would not recommend using the  MGP account as the account for Enterprise-FRP profile payload for security reason.  If a remote end-user device got wiped for whatever reason and ask for the account and password to pass the Enterprise-FRP prompt, giving him/her the credential will have the risk that the corresponding managed-google play app-store being accessed and tampered with by unauthorized personnel.

Secondly, I believe Enterprise-FRP was introduced as a coporate-level device-theft deterrence mechanism originally for AE device in managed-device/device-owner mode without any personal Google account.  The situation gets a bit confused if personal google account is allowed for devices in DO or in the new AE Corporate Personal mode.  From my recent tests, there seems to be more than one loopholes that defeat the device-theft deterrence purpose which should require a factory-reset corporate device to be re-configured ONLY for corporate use with an MDM/EMM solution.  Whether or not a personal Google-account and password can be used is just one such possible loophole.   I just found more in the user-interface on some of my test devices.

Hence, I personally would wait and see if Google will refine in their firmware template codes the expected behaviour/mechanism in such cases.  If not, maybe the best approach for device-theft deterence and automated-enrollment remains to be using zero-touch-enrollment, which is supported for a much narrower range of devices at the moment.