# Factory Reset Protection (FRP) > Control which accounts can reactivate an Android Device after a factory reset, protecting corporate Devices against theft or loss — configured through the frpAdminEmails policy field in Applivery. Source: https://docs.applivery.com/en/device-management/android/policies/factory-reset-protection/ • Last updated: 2026-07-30 **Key topics:** Factory Reset Protection, frpAdminEmails, preserveFrp, Compliance wipes, Android Management API, Applivery, Google accounts --- **TL;DR:** FRP stops a stolen or lost Android Device from being reactivated after a factory reset without an authorized admin account. On AMAPI-managed Devices it is not automatic — you must set the frpAdminEmails field in the Policy's Security section. Factory Reset Protection (FRP) stops a stolen or lost Android Device from being reactivated after a factory reset unless someone signs in with an authorized administrator account. On Devices managed through the Android Management API (AMAPI) — like the ones Applivery administers — this protection **is not enabled automatically**: you have to set the **Frp Admin Emails** field in the Policy explicitly. ## What is Factory Reset Protection? Factory Reset Protection is an Android security feature that blocks a Device after a factory reset until someone signs in with an authorized Google account. Its goal is to discourage theft: a Device with FRP active that is reset "the hard way" — for example, from the recovery menu — becomes unusable to anyone who doesn't know the credentials of the linked account. In the consumer world, FRP turns on as soon as there's a Google account on the Device. **On Devices managed through AMAPI, this behavior is different and must be configured explicitly.** ## How FRP behaves on AMAPI-managed Devices This is the most important nuance, and the one that most often causes operational confusion. :::warning On AMAPI-managed Devices, FRP **only activates if the Policy defines** **Frp Admin Emails**. If this field is absent or empty, the Device offers no factory reset protection — even if a Google account is present. ::: Android's behavior also distinguishes **how** the reset was started: - **Reset from the Device's Settings** (the user is already signed in as owner): on many Fully Managed Devices, a reset started from Settings by the signed-in user doesn't trigger FRP the same way a "forced" reset does. Even so, protection still depends on **Frp Admin Emails** being configured correctly. - **Reset by other means** (recovery menu, remote wipe command, theft with physical extraction): if the Policy has **Frp Admin Emails** set, the Device requires the email and password of one of those accounts to finish provisioning. ## The **Frp Admin Emails** field **Frp Admin Emails** is a top-level field in the AMAPI `Policy` resource. Applivery exposes it through its Android Policies — the same mechanism other AMAPI settings not covered by a native Dashboard control (such as Network Escape Hatch Enabled or Advanced Security Overrides) use to be applied directly.

Field	Type	Description
Frp Admin Emails	array of strings	Email addresses of the Google accounts authorized to unlock the Device after a factory reset. If empty or absent, the Device does not enforce FRP.

Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies**. From the left side menu, go to **Security**, locate **FRP Admin Emails**, and click **\+ Add element** to add each authorized account. ![frp admin emails](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5e48d20a-c8f8-401d-8148-c01028ed79fd.png) :::tip Include **at least two** accounts in **FRP Admin Emails** — for example, a team account and a direct manager's account. This prevents a Device from becoming permanently locked if a single administrative account is no longer available. ::: ### Should I enable FRP on all my Devices? It depends on the balance between security and day-to-day operations in your organization:

Scenario	Recommendation
High-value corporate Devices at risk of theft (couriers, field sales, Devices that leave the premises)	Enable FRP with FRP Admin Emails pointing to an IT-managed team account
Devices frequently reassigned between employees or returned to IT for re-provisioning	Weigh whether FRP adds operational friction; if your offboarding process isn't well oiled, a Device can end up locked to someone no longer in the organization
Dedicated / kiosk Devices with no personal user account	Usually adds no value, since there's no end-user Google account to protect

## Preserve Frp: FRP and compliance rules (automatic wipe) When a Device is wiped automatically for policy non-compliance (through **Policy Enforcement Rules**), the **Preserve Frp** field inside the **Wipe action** configuration decides whether FRP data survives that wipe. You configure it in the **Compliance** section of your Policy, under **Policy Enforcement Rules**.

Field	Location	Type	Behavior
Preserve Frp	Policy Enforcement Rules > Wipe Action > Preserve Frp	boolean	If `true`, FRP data is kept after a non-compliance wipe. If omitted, the default behavior does not preserve FRP data.

:::warning **Preserve Frp** only has an effect if the Device already had **FRP Admin Emails** configured. It does not enable FRP on its own. ::: ![preserve frp](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9293c931-64ac-48f6-9799-56418f986a09.png) For the full compliance-wipe configuration, see [Enforcement Rules](https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/). ## Known limitations - **Doesn't apply to work profiles (Work Profile / COPE).** **FRP Admin Emails** operates at the full-device level ("Fully Managed" mode). - **Requires the Device to have FRP Google accounts registered before the reset.** If the Device never had an account associated through the Policy, there are no credentials to ask for. ## Troubleshooting ### A Device is locked by FRP and can't be re-provisioned **Check the authorized accounts** Confirm which accounts were in **FRP Admin Emails** on the Policy the Device had assigned before the reset. **Sign in with an authorized account** Ask a holder of one of those accounts to enter their credentials on the FRP lock screen during Device setup. **If no authorized account is available** If none of the **FRP Admin Emails** accounts are available (for example, an employee who took their access with them), you'll need to handle Device recovery directly with Google or the manufacturer. Applivery has no remote mechanism to bypass FRP once it's active. ### I need a batch of new Devices to never be protected by FRP Make sure the provisioning Policy **doesn't include** **FRP Admin Emails**, or that the array is explicitly empty.