# Encryption Policy > Configure Android device encryption in Applivery — understand encryptionPolicy values, how they affect device boot behavior, and which setting to choose for your deployment. Source: https://docs.applivery.com/en/device-management/android/policies/encryption-policy/ • Last updated: 2026-06-03 **Key topics:** Android Encryption Policy, File-Based Encryption (FBE), Before First Unlock (BFU), Android Device Policy, Applivery MDM Configuration, Android, Applivery, Android Management API, File-Based Encryption --- **TL;DR:** encryptionPolicy controls device encryption and boot behavior on managed Android devices. ENABLED_WITHOUT_PASSWORD is recommended for most deployments as it enforces encryption while keeping the device remotely manageable. All Android devices enrolled in Applivery MDM have their storage encrypted by default, thanks to Android's [File-Based Encryption (FBE)](https://source.android.com/docs/security/features/encryption/file-based). The `encryptionPolicy` setting lets you define exactly how that encryption interacts with the device boot process — which has a direct impact on remote manageability. ## How Android encryption works Android uses **File-Based Encryption (FBE)**, which encrypts files individually and divides storage into two areas:

Storage type	When it's accessible	What it contains
Device Encrypted (DE)	Immediately after boot, before user authentication	System processes, Direct Boot–aware apps, Android Device Policy
Credential Encrypted (CE)	Only after the user unlocks with PIN, password, or biometrics	User data, most apps, personal files

This separation is what makes **Direct Boot** possible: the device can boot, connect to Wi-Fi, and run essential services (including MDM communication) before the user has entered their PIN. ## encryptionPolicy values The `encryptionPolicy` field in your Android policy controls whether encryption is enforced and how the device handles the boot process. ### ENCRYPTION\_POLICY\_UNSPECIFIED The value is ignored by the Android Management API — no explicit encryption requirement is set. Encryption behavior depends entirely on the device's own defaults. **This value is not recommended** for managed enterprise deployments. ### ENABLED\_WITHOUT\_PASSWORD (Recommended) Encryption is enforced, but the device **does not require the PIN at boot** to start. Under the hood, Android derives the encryption key from the device hardware at startup, making DE storage available immediately. CE storage (and user data) remains encrypted until the user authenticates. This is the standard behavior for modern Android devices and the recommended value for enterprise deployments because: - Android Device Policy starts normally after every reboot. - Remote commands (including Reset password) reach the device immediately. - Encryption is still enforced — data is fully protected against offline attacks. ### ENABLED\_WITH\_PASSWORD Encryption is enforced, **and** the device requires the user's PIN or password at boot, before the encrypted storage is decrypted. This maps to the **Secure Startup** feature on Android devices. :::warning When `ENABLED_WITH_PASSWORD` is active and a device restarts, the device enters a **Before First Unlock (BFU)** state until the user enters their PIN. In BFU state, Android Device Policy cannot start — the device appears online in Applivery but is completely unreachable for remote commands. See [Remote Commands — Reset password troubleshooting](/en/device-management/android/commands/remote-commands/#troubleshooting-reset-password-fails-instantly) for details on resolving this situation. ::: Use this value only if your security policy explicitly requires pre-boot authentication — for example, in regulated environments where unattended device boot is not permitted. ## Where to configure it Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Security**, and locate the **Encryption Policy** 2 setting. ![encryption policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/59315ba5-3fcb-42bc-a8df-5b441bad3371.png) ## Choosing the right value

Scenario	Recommended value
Standard enterprise deployment	`ENABLED_WITHOUT_PASSWORD`
Kiosk or unattended devices	`ENABLED_WITHOUT_PASSWORD`
Regulated environment requiring pre-boot PIN	`ENABLED_WITH_PASSWORD` (ensure physical access is always available)
Device was already in BFU and is unreachable	Recover physically, then consider switching to `ENABLED_WITHOUT_PASSWORD`

## Security considerations A common concern is whether `ENABLED_WITHOUT_PASSWORD` is less secure than `ENABLED_WITH_PASSWORD`. The answer depends on the threat model: - **Against offline attacks** (extracting the storage chip and reading it externally): both values provide equivalent protection through Android FBE. The DE key is derived from a hardware-bound key that cannot be extracted without the device. - **Against an attacker with physical access to a running device**: `ENABLED_WITH_PASSWORD` adds a layer by preventing the device from booting unattended, but this must be weighed against the operational risk of devices becoming permanently unmanageable if the user forgets their PIN. For most enterprise deployments, `ENABLED_WITHOUT_PASSWORD` strikes the right balance between security and operational control.