Force reset protection for Android

expand collapsive

Can anyone halp me out with my questions –

  1. If our device does not have any Google account, can the FRP be enabled on the device?
  2. If our user has configured his/her personal email ID and wipes the device, can we force the device to use either the Gsuite cred or a pre-configured Google Account ID (not same as the personal account saved on the device)?

All Replies

  • Hi @Yeboi, Factory Reset Protection (FRP) is a security feature supported from Android 5.1 that is designed to prevent the use of devices if it gets reset to factory settings without permission. This feature will be automatically activated when –

    1. The user is signed in to Google on the device.
    2. A device wipe is initiated from Find my Device, Recovery mode, or even Hexnode (like the Wipe device action).

    However, FRP will not be activated if the device user initiates the device wipe since it will ask for authentication before executing the action on the end device.

    Now back to your question,

    1. If the device does not have any Google account active on the device, FRP will not be imposed.
    2. You need to have a different Google account ID instead of the default user’s account ID for FRP authorization. This can be achieved with Hexnode UEM.

    With Bypass Factory Reset Protection, you can control the user’s device wipe experience. You can find this option on Hexnode’s policy under Android > Advanced Restrictions > Factory Reset Protection. Here, you can choose three options –

    • Default – This will configure the device to stick to the default workflow, i.e., if the user is signed on to Google, they need to use their Google account credentials to unlock FRP.
    • Bypass Factory Reset Protection – This enforces the Google account verification step. You can provide the Google Account ID or G Suite account username to use instead of the user’s default account credentials.
    • Disable Factory Reset Protection – This lets you skip the Google account ID verification step.

     

    Note: Bypass Factory Reset Protection is supported on devices enrolled in Hexnode as Android Enterprise Device Owner. You may authorize multiple G Suite Accounts or Google Account IDs to be used to bypass FRP.

    Also, if only the work account is active on the device and no other Google account is signed in, you need to choose Disable Factory Reset Protection to get over FRP. 

    Cheers!
    Zach Goodman
    Hexnode UEM

    • This reply was modified 2 years, 8 months ago by  Zach Goodman.
    • This reply was modified 2 years, 8 months ago by  Zach Goodman.
    • This reply was modified 2 years, 8 months ago by  Zach Goodman.
  • Participant

    Deema

    Participant

    In FRP policy, under Bypass Factory Reset we have the option to enter Google Account ID. Can we simply enter the email id of our Google account or is it something else? The tooltip on the label talks about ‘Google Account ID’ which I’ve never heard or seen –

    “Google Account ID refers to the 21-digit ID of your Google account.
    Here’s how you find it.
    1. Click on this link. Enter “people/me” under resourceName and “metadata” under personFields.
    2. Click on Execute.
    3. Enter your Google Account details if prompted.
    4. The 21-digit number corresponding to “id” is your account ID to be entered below.”

  • Participant

    Deema

    Participant

    @layla, maybe you are right but I tried the instructions with the Google API Explorer link (https://developers.google.com/people/api/rest/v1/people/get?apix=true&apix_params=%7B%22resourceName%22%3A%22people%2Fme%22%2C%22personFields%22%3A%22metadata%22%7D) and did get some value.

    I guess our account ID here is the id key (21 keys). I did some research and Google Account IDs seem predominantly used by Google+, Picasa, ads and other services. Google says –

    “User-ID lets you associate a persistent ID for a single user with that user’s engagement data from one or more sessions initiated from one or more devices.”

    Seems like something to identify user across their services but still would be much convenient for us to use email id directly instead.

    • This reply was modified 2 years, 8 months ago by  Zach Goodman.
    • This reply was modified 2 years, 8 months ago by  Zach Goodman.