Feature spotlight: Factory Reset Protection

Comment thread for the following:

Feature spotlight: Factory Reset Protection | Jason Bayton

Hey, I’ve tested this out on the latest versions of AirWatch/Workspace ONE UEM and it worked quite well. It actually prompts to clear the lock when you are remotely wiping the end device. So naturally this would be used along side the allowing of personal Google accounts on a work managed device.
I feel this is potentially a good alternative for COPE enrolment in the VMware side of things.

Allowing personal accounts on a work-managed device without leveraging a separate work profile (COPE) will put you in a situation where data-leakage is highly likely. With additional Google accounts added, users can download any apps they see fit via Play which will sit alongside corporate apps, a practice which is absolutely not recommended as there’s not a considerable amount you can do to mitigate data being shared between apps within a user profile on the device.

We took a look at how to deploy this and tested this in COPE mode. What we found (which matches the description at Security  |  Android Developers if you know how to interpret it) is that deploying a profile with a list of admin accounts actually prevents the user to unlock their own (corporate) device with the Google account configured in the personal profile. Instead, it is required that an admin then unlocks the device with the MDM-configured account. Effectively, this would increase the effort for our service desks for each accidentally reset device, instead of decreasing it.
It’s also not well-thought out that the same setting applies to devices set up with Zero Touch. The flow here is quite hilarious, first forcing an admin to enter the MDM-configured account to unlock the device to then get the ZTE configuration in the next step - which of course locks the device to the MDM anyway.

Yes, absolutely. As a fully managed device you override the capability for users to lock the managed device to FRP, however for a COPE situation where you accept that risk, you don’t have to apply FRP whitelisting via policy if that’s what you desire.

When utilising zero-touch this FRP whitelist feature is not required and I’m not sure why you’d utilise it; FRP can be disabled all together, but outside of zero-touch, it’s necessary if you don’t wish for users to simply reset the device and set it up outside of management.

Thanks for great article. Working link to People:Get Google API (that one in article is not working any more).

1 Like

Fixed it :slightly_smiling_face:

is it wise/ok to use the Factory reset protection email address same as the one setup for Managed Google Play??

There’s nothing inherently wrong with doing so, just be aware users may be inputting that password over the phone with IT should the device reset, and that can expose the password to your enterprise bind.

Personally I’d lean on a couple of dedicated accounts for this.

let’s say if i have an android phone that is lock with user personal gmail when factory reset and he is uncontactable.

if i find a reseller to add the phone to zero touch portal and reset again, will it be unlocked by overriding the user personal gmail?

thanks.

Hi there, no. The only fix to FRP short of a community workaround is to send the unit to the OEM for “repair” (clear the FRP bit)