You are here: Home > Device Management > Android > Troubleshooting > My Device Is Not Enrolled Anymore but Still Has Restrictions

Recover an Android Device That Still Has Restrictions After Unenrollment

Why an Android Device can get stuck in an in-between state after you unenroll or wipe it from Applivery, and how to factory reset and recover it.

9 min read

TL;DR

The Device never received, or couldn't run, the removal command: it was offline, the command expired or it was in BFU. If you can reach it, resend the command; if not, factory reset it locally. If FRP appears, you need one of the accounts authorized in the Policy.

A Device gets stuck in an in-between state when the console no longer manages it, but the Device never received (or couldn't run) the removal command, so it keeps the Policy, restrictions or locks. The most common cause is that the command never arrived: the Device was off or offline, the command expired, or the Device was locked in BFU state.

If you can still reach the Device, resend the command. If not, the way out is usually a local factory reset, from Settings or from recovery mode. If the FRP screen appears afterwards, you need one of the accounts authorized in the Policy.

How to recognize a Device in an in-between state

A Device is in an in-between state when two things happen at once:

  1. In the Applivery Dashboard, the Device has been unenrolled, wiped or no longer responds to commands.

  2. On the Device, the Policy restrictions are still active: blocked Apps, inaccessible settings, kiosk, factory reset blocked, and so on.

Before looking for the cause, gather this information. You'll need it if you escalate the case to support:

  • The Device's management mode: fully managed, dedicated (kiosk), COPE, personal work profile or AOSP.

  • The last command sent, with its date and Duration, and the status shown in the Commands tab.

  • Whether the Device is on, has battery and has a connection.

  • Whether the Device rebooted recently and is asking for the PIN at boot.

  • Whether the Policy had Frp Admin Emails configured.

Possible causes

# Cause How to identify it Affected modes
1 The command never reached the Device: off, out of battery, offline or out of coverage. The Device hasn't reported in a while and the command is still unconfirmed. All
2 The command expired. Remote commands have a Duration parameter (in seconds) and expire if the Device doesn't run them within that time. The command shows as expired or not run, and the Device came back online afterwards. All
3 Device in BFU (Before First Unlock) state. With encryptionPolicy set to ENABLED_WITH_PASSWORD, after a reboot the Device asks for the PIN before decrypting storage. Until then, Android's user space is frozen, including Android Device Policy, the component that talks to Applivery. The command fails almost instantly even though the Dashboard shows the Device connected to Wi-Fi. Fully managed and dedicated
4 Device locked with an unknown password. The Reset password command can't work on a Device that's already locked unless a reset token is activated. You need the PIN or pattern and nobody knows it. Fully managed
5 Dedicated (kiosk) Device with no network at boot. Without a connection, the Device can't download the Policy or receive commands. The Device boots into the kiosk and can't connect. Dedicated
6 AOSP Device not receiving the command. On AOSP, commands are sent through Pushy (not AMAPI) and run by the Applivery DPC, which confirms receipt and completion. The command never gets past "sent" and there's no receipt confirmation. AOSP
7 Factory reset blocked by the Policy. The Policy prevents the user from resetting the Device from Settings. The reset option isn't available or has no effect. Fully managed, dedicated and AOSP
8 Factory Reset Protection (FRP). If the Policy defined Frp Admin Emails, after a forced reset the Device requires one of those Google accounts to finish setup. The account verification screen appears after the reset. Fully managed
9 Wipe from enforcement rules with Preserve Frp turned on. If the Wipe Action has Preserve Frp set to true, FRP data is kept after the automatic wipe. The Device was wiped for non-compliance and now asks for an FRP account. Fully managed
Note

A factory reset can't always be blocked. On COPE Devices, no EMM solution, Applivery included, can disable factory reset, so the user always keeps that option. You'll find more details in COPE Permission Limits.

Fixes

Start with the first one that applies to your case. They go from least to most destructive: only the last ones mean losing the Device's data.

1. Restore connectivity and resend the command

Applies to causes 1, 2, 5 and 6.

  1. Check that the Device is on, has battery and has a connection (Wi-Fi or mobile data).

  2. If the Device is in a kiosk with no network, use the Network Escape Hatch if it's enabled in the Policy. It offers temporary network recovery access to refresh the Policy; once the Policy is applied, the temporary network is forgotten and boot continues normally. You'll find more details in Kiosk Mode.

  3. When the Device comes back online, resend the command from the Device's Action button, from its Commands tab or from Settings → Danger zone. See Remote Commands.

  4. Set Duration to a value long enough to cover the time the Device may take to come back online. There's no maximum.

Note

On AOSP Devices, if you need to remove management without wiping the Device, use the Disenroll command: it removes the Applivery DPC as Device Owner and clears the Device's stored state.

2. COPE Devices: relinquish ownership or reset from the Device

Applies to COPE (Company-Owned, Personally Enabled) Devices.

  • From the Dashboard, send the Relinquish ownership command from the Commands tab. It removes the work profile and corporate management policies and keeps the content of the personal profiles; the Device then behaves like a standard unmanaged Android Device.

  • If the command doesn't arrive, the user can factory reset the Device from their own Settings. On COPE, that option can't be blocked.

3. Device in BFU state

Applies to cause 3. There's no remote fix, because in BFU there's no process able to receive commands. You need physical access:

  1. Enter the PIN on the Device. If the user remembers it, this is the simplest option. Once unlocked, the Device receives commands again and you can resend the removal or wipe command.

  2. Factory reset from recovery mode. The Device loses all local data, but becomes manageable again.

To keep it from happening again, use ENABLED_WITHOUT_PASSWORD in encryptionPolicy: it keeps encryption but doesn't ask for the PIN at boot.

4. Device locked with an unknown password

Applies to cause 4. The Reset password command can't work on a Device that's already locked with an unknown password. It's an Android platform limitation that affects every MDM.

  1. Check whether the lock comes from Google's Find My Device, which lets you set a new PIN remotely.

  2. If not, factory reset the Device from recovery mode.

5. Factory reset from recovery mode

This is the fallback when the Device can't receive commands and nobody can unlock it.

  1. Turn off the Device.

  2. Hold the model's physical button combination to boot into recovery mode.

  3. Select the factory reset option and confirm.

Warning

The button combination and the look of the recovery menu depend on the manufacturer and model; check the manufacturer's documentation. This method wipes all local data and, if the Policy had Frp Admin Emails, the Device will ask for one of those accounts when it finishes.

6. The Device asks for a Google account after the reset (FRP)

Applies to causes 8 and 9.

  1. Check which accounts were in Frp Admin Emails in the Policy assigned to the Device before the reset (the Policy's Security menu).

  2. Ask someone who owns one of those accounts to enter their credentials on the FRP screen during initial setup.

  3. If none of those accounts is available, recovery has to go directly through Google or the manufacturer. Applivery has no remote mechanism to bypass FRP once it's active.

Warning

FRP is only active on AMAPI-managed Devices if the Policy defines Frp Admin Emails. If the field was empty or missing, the Device has no factory reset protection. It doesn't apply to work profiles or COPE. You'll find more details in Factory Reset Protection (FRP).

Which fix to use by management mode

Management mode First option If the command doesn't arrive
Fully managed Resend the command with a longer Duration Physical PIN or reset from recovery mode; then FRP account if needed
Dedicated (kiosk) Recover the network (Network Escape Hatch) and resend the command Reset from recovery mode; then FRP account if needed
COPE Relinquish ownership Reset from the Device's Settings (can't be blocked)
AOSP Disenroll command Reset from recovery mode

Prevention

  • Use ENABLED_WITHOUT_PASSWORD in encryptionPolicy. It keeps full encryption but doesn't require the PIN at boot, so Android Device Policy starts normally after a reboot and remote commands keep working. See Encryption Policy.

  • Define at least two accounts in Frp Admin Emails, for example a team account and a direct manager's, so a Device doesn't get locked if one account becomes unavailable.

  • Review your employee offboarding process before turning on FRP on Devices that get reassigned often: without it, a Device can end up locked to someone who's no longer in the organization.

  • Use a generous Duration on removal or wipe commands when the Device may be offline.

  • Before blocking manual changes or factory reset, test the Policy on a pilot group and validate the full removal flow, including what happens if the command doesn't arrive.

  • For non-compliance wipes, check the Preserve Frp value in the Wipe Action before deploying the rule. See Enforcement Rules.

If the issue persists

If none of the fixes above work, open a case with support and include:

  • The Device's management mode and Android version.

  • The Device identifier in Applivery and the date of its last report.

  • The last command sent, with its date, its Duration and the status shown in the Commands tab.

  • Whether the Device rebooted and which screen it shows (PIN, FRP, kiosk, Settings).

  • The accounts configured in Frp Admin Emails, if any.

Key Takeaways

  • The most common cause is that the removal command never reached the Device.
  • Commands expire based on their Duration; use a generous value.
  • In BFU state there's no remote fix; you need physical access.
  • On COPE, the user can always factory reset.
  • After a reset, FRP requires one of the accounts defined in the Policy.
  • ENABLED_WITHOUT_PASSWORD in encryptionPolicy prevents the BFU lockout.

Because the Device never received, or couldn't run, the removal command. Applivery no longer manages it, but the Policy is still applied on the Device.

Make sure the Device is on and connected, then resend the command with a Duration long enough to cover the time it may take to come back online.

The Device is probably in BFU state: after a reboot it asks for the PIN before decrypting storage, and Android Device Policy can't receive commands until someone enters it.

Reset password doesn't work on a Device that's already locked. Check whether the lock comes from Google's Find My Device and, if not, factory reset it from recovery mode.

Yes. On COPE, no EMM solution, Applivery included, can block factory reset, so the user can always do it from Settings.

That's FRP. Enter one of the accounts listed in Frp Admin Emails in the Policy. If none is available, recovery has to go through Google or the manufacturer.

Use the Disenroll command. It removes the Applivery DPC as Device Owner and clears the Device's stored state.

Use ENABLED_WITHOUT_PASSWORD in encryptionPolicy. It keeps full encryption but doesn't ask for the PIN at boot, so remote commands keep working after a reboot.

Was this page helpful?

Last updated: October 16, 2026