Factory Reset Protection bricks returned Android devices — and behaves differently depending on who pressed reset

A leaver hands back their Android, you factory-reset it, and the setup wizard demands the previous user's Google account. Whether FRP fires at all depends on which reset path was used — the same Intune policy produces opposite outcomes. Here is why that happens, and how to guarantee IT can always recover its own hardware.

The problem

An employee leaves and returns their corporate Android. The helpdesk factory-resets it, and the setup wizard stops dead: "This device was reset. To continue, sign in with a Google Account that was previously synced on this device." The account it wants belongs to the ex-employee — who is gone, unreachable, or unwilling. The device is now a paperweight, even though your organisation owns it and it is enrolled in your own Intune tenant.

Three related symptoms send admins to Google:

• The Factory Reset Protection (FRP) wall on returned hardware. The device demands a previously synced Google account — on corporate-owned-with-work-profile (COPE) devices, that is often the leaver's personal account from the personal profile.
• Inconsistent enforcement. With an identical Factory reset protection emails policy applied fleet-wide, some resets prompt for a Google account and some sail straight through to setup. Microsoft maintains a dedicated troubleshooting page for exactly this, because the outcome depends on the reset path, not just the policy.
• Captive-portal Wi-Fi breaks the unlock flow. Even when you have valid credentials, attempting the FRP unlock on guest Wi-Fi with a sign-in splash page can fail with "Unable to sign in to Wi-Fi AP. An unauthorised factory reset has been performed on this device. The sign-in screen cannot be accessed" (as reported in the Android Enterprise community).

If you run Android Enterprise corporate-owned devices — COPE, fully managed (COBO) or dedicated (COSU) — through Intune and you process leavers' hardware, you will hit this eventually.

Why it happens

FRP is Android's anti-theft mechanism. Identifiers for the Google accounts on a device are written to a persistent data block that survives a factory reset. After a reset that Android considers unauthorised, the setup wizard refuses to proceed until someone signs in with a previously synced Google account — or, if enterprise FRP is configured, one of the designated admin accounts. After a reset Android considers authorised, the FRP data is cleared and the device comes up clean.

The catch: which resets count as authorised depends on the enrolment type and on who initiated the reset. Microsoft documents the expected behaviour when Factory reset protection emails is configured:

Two design decisions explain the matrix:

• An Intune-initiated wipe does not preserve FRP data by default. Microsoft states this explicitly: for the Intune wipe path, "FRP isn't enforced because Intune doesn't preserve FRP data in this flow." The management plane issued the wipe, so Android treats it as the owner's deliberate act and clears the protection.
• An on-device reset may be the thief's act, so it is treated as untrusted. A recovery-mode reset always enforces FRP; on COPE, a Settings-initiated reset does too, because the end user (not the device owner app) performed it.

So the same policy genuinely produces opposite outcomes: helpdesk wipes from the Intune console — no FRP wall; helpdesk (or the departing user) resets on the device — full FRP wall. On COPE devices with no FRP admin emails configured, the account behind that wall is whatever Google account was synced in the personal profile: the leaver's.

Two further wrinkles:

• Android 15 hardened FRP. Some OEMs previously skipped FRP enforcement on certain paths; from Android 15, enforcement aligns with Google's intended design. Behaviour you learned from an older fleet may no longer hold.
• Captive portals conflict with the FRP flow. While a device is FRP-flagged, it blocks the captive-portal sign-in page it would need to get online, producing the "unauthorised factory reset" Wi-Fi error. In the Samsung case reported in the Android Enterprise community, the issue was only resolved by platform updates (Android 14 with Knox Mobile Enrollment 23.12) — there was no configuration workaround.

The fix

1. Configure FRP admin emails now — before you need them

This is the under-used gem: Google's enterprise FRP lets you pin post-reset recovery to Google accounts you specify, fleet-wide, instead of whatever account the last user had synced. In Intune: Devices > Configuration > Create > New policy > Android Enterprise > Device restrictions > General > Factory reset protection emails. Choose "Google account email addresses" and enter one or more accounts separated by semicolons. With this in place, an FRP-locked device accepts any of the specified accounts to complete setup — regardless of whose device it was.

Note the timing: the policy only protects resets that happen after it reached the device. A device reset before the policy applied is still locked to the previously synced account.

2. Use dedicated corporate Google accounts as the FRP identities

Create one or two purpose-made Google accounts (for example frp-recovery@yourdomain.com), not an individual admin's personal Gmail. Store the credentials in your break-glass password process — these accounts can unlock every FRP-locked device in the fleet, so treat them accordingly.

3. Block user-initiated factory reset where you can

On fully managed and dedicated devices, set Factory reset to Block in the same device restrictions profile. Microsoft recommends this: it removes the Settings reset path entirely, leaving recovery mode (FRP enforced) and Intune wipe (no FRP) as the only routes.

4. Choose the reset path deliberately in your leaver process

• Device physically returned and destined for reuse: wipe it from the Intune console. FRP data is not preserved, so the device boots straight into setup, ready to re-provision. Do this before anyone helpfully resets it by hand.
• Device lost, stolen, or not coming back: the on-device/recovery reset paths enforcing FRP is exactly what you want — the device is useless without your FRP admin account.

5. Already staring at a leaver's FRP wall?

1. Try your FRP admin accounts, if the policy was in place before the reset.
2. Ask the ex-employee to remove the device from their Google account (Google account > Security > Your devices, or the Find My Device page). Removing the account should lift FRP on the next reset — this commonly works, but the exact behaviour varies by OEM and Android version, so treat it as a likely remedy rather than a guarantee.
3. On Samsung devices registered in Knox Mobile Enrollment, KME's FRP handling has historically offered a recovery route — but Samsung has withdrawn FRP bypass support on Android 15 and later (consistent with the hardened FRP noted above), so this only applies to devices running earlier Android versions. Check the current Knox documentation for your device's Android version before relying on it.
4. Last resort: the OEM or Google support route with proof of corporate purchase.

6. Never do the FRP unlock on captive-portal Wi-Fi

Use a phone hotspot or a plain WPA2/WPA3-PSK network for the unlock. Guest networks with splash-page sign-in can hard-fail the flow. Keeping devices on current firmware matters here too — the reported Samsung captive-portal failure was fixed at platform level, not by configuration.

7. Write it down

Add two lines to your leaver runbook: which reset path will be used for this device, and which account will unlock it if FRP triggers anyway. The whole failure mode exists because that decision is usually made implicitly, by whoever presses reset first.

How Decolla handles it

Straight answer: it doesn't. Decolla provisions Windows devices over your own Intune and Autopilot tenant — it does not manage Android, and FRP configuration remains a job for your Android Enterprise policies, as described above.

What Decolla does address is the same underlying failure class on Windows: an action whose consequences depend on hidden state and on who triggered it. Before Decolla runs anything, it produces a written, itemised plan in which every item carries its delivery method and a reversibility class — automatic, reversible, or explicitly flagged irreversible — and that plan is approved before a single change lands. Anything Decolla itself changes can be rolled back per item. The principle this article argues for on Android — make the recovery identity and the reset path explicit before any wipe — is the same one Decolla enforces mechanically on Windows: no irreversible step should ever come as a surprise.

Decolla is pre-launch; if that approach to provisioning appeals, the waitlist is open at decolla.app.

Sources

• Microsoft Learn — Factory Reset Protection emails not enforced in Intune for Android
• Anoop C Nair — Factory Reset Protection on Android with Intune
• Android Enterprise community — Factory Reset Protection and captive portals
• Intune IRL — Factory Reset Protection
• Samsung Knox — Knox Mobile Enrollment 25.11 release notes (FRP bypass no longer supported on Android 15+)