# Política de encriptación

> Configura la encriptación de dispositivos Android en Applivery — comprende los valores de encryptionPolicy, cómo afectan al arranque del dispositivo y qué configuración elegir para tu despliegue.

Source: https://docs.applivery.com/es/device-management/android/policies/encryption-policy/  •  Last updated: 2026-06-03

**Answers:** ¿Qué es encryptionPolicy en el MDM de Android? · ¿Cuál es la diferencia entre ENABLED_WITH_PASSWORD y ENABLED_WITHOUT_PASSWORD? · ¿Qué valor de encryptionPolicy debo usar? · ¿Por qué falla el comando Restablecer contraseña con ENABLED_WITH_PASSWORD? · ¿Qué es el estado Before First Unlock (BFU)? · ¿ENABLED_WITHOUT_PASSWORD es menos seguro? · ¿Dónde configuro encryptionPolicy en Applivery? · ¿Qué ocurre si encryptionPolicy es ENCRYPTION_POLICY_UNSPECIFIED?

**Key topics:** Política de encriptación Android, Encriptación basado en archivos (FBE), Before First Unlock (BFU), Android Device Policy, Configuración del MDM de Applivery, Android, Applivery, Android Management API, encriptación basado en archivos

---

**TL;DR:** `encryptionPolicy` controla la encriptación y el comportamiento de arranque en dispositivos Android gestionados. `ENABLED_WITHOUT_PASSWORD` es el valor recomendado para la mayoría de los despliegues porque aplica la encriptación manteniendo el dispositivo gestionable de forma remota.

Todos los dispositivos Android inscritos en Applivery MDM tienen su almacenamiento de encriptación por defecto gracias a la [encriptación basada en archivos (FBE)](https://source.android.com/docs/security/features/encryption/file-based) de Android. La configuración `encryptionPolicy` te permite definir exactamente cómo esa encriptación interactúa con el proceso de arranque del dispositivo — lo que tiene un impacto directo en la gestionabilidad remota.

## Cómo funciona la encriptación de Android

Android utiliza la **encriptación basada en archivos (FBE)**, que cifra los archivos de forma individual y divide el almacenamiento en dos áreas:

<table style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Tipo de almacenamiento</p></th><th colspan="1" rowspan="1"><p>Cuándo está accesible</p></th><th colspan="1" rowspan="1"><p>Qué contiene</p></th></tr><tr><td colspan="1" rowspan="1"><p><strong>Encriptación del Dispositivo (DE)</strong></p></td><td colspan="1" rowspan="1"><p>Inmediatamente tras el arranque, antes de la autenticación del usuario</p></td><td colspan="1" rowspan="1"><p>Procesos del sistema, apps con soporte para Direct Boot, Android Device Policy</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Encriptación con Credenciales (CE)</strong></p></td><td colspan="1" rowspan="1"><p>Solo después de que el usuario desbloquee con PIN, contraseña o biometría</p></td><td colspan="1" rowspan="1"><p>Datos del usuario, la mayoría de las apps, archivos personales</p></td></tr></tbody></table>

Esta separación es lo que hace posible el **Direct Boot**: el dispositivo puede arrancar, conectarse a Wi-Fi y ejecutar servicios esenciales (incluida la comunicación con el MDM) antes de que el usuario haya introducido su PIN.

## Valores de encryptionPolicy

El campo `encryptionPolicy` en tu política de Android, controla si la encriptación es obligatoria y cómo gestiona el dispositivo el proceso de arranque.

### ENCRYPTION\_POLICY\_UNSPECIFIED

La Android Management API ignora este valor — no se establece ningún requisito de encriptación explícito. El comportamiento de la encriptación depende completamente de los valores predeterminados del propio dispositivo. **Este valor no se recomienda** para despliegues empresariales gestionados.

### ENABLED\_WITHOUT\_PASSWORD (Recomendado)

La encriptación es obligatoria, pero el dispositivo **no requiere el PIN al arrancar**. Android deriva la clave de encriptación del hardware del dispositivo al iniciarse, lo que hace que el almacenamiento DE esté disponible de inmediato. El almacenamiento CE (y los datos del usuario) permanece encriptado hasta que el usuario se autentica.

Este es el comportamiento estándar de los dispositivos Android modernos y el valor recomendado para los despliegues empresariales porque:

-   Android Device Policy se inicia con normalidad tras cada reinicio.
    
-   Los comandos remotos (incluido Restablecer contraseña) llegan al dispositivo de inmediato.
    
-   El encriptación sigue siendo obligatoria — los datos están totalmente protegidos contra ataques fuera del dispositivo.
    

### ENABLED\_WITH\_PASSWORD

La encriptación es obligatoria **y** el dispositivo exige el PIN o la contraseña del usuario al arrancar, antes de descifrar el almacenamiento encriptado. Esto corresponde a la función **Inicio seguro** en los dispositivos Android.

:::warning
Cuando `ENABLED_WITH_PASSWORD` está activo y un dispositivo se reinicia, entra en estado **Before First Unlock (BFU)** hasta que el usuario introduce su PIN. En estado BFU, Android Device Policy no puede iniciarse — el dispositivo aparece conectado en Applivery pero es completamente inaccesible para los comandos remotos. Consulta [Comandos remotos — Solución de problemas para Restablecer contraseña](/es/device-management/android/commands/remote-commands/#solucion-de-problemas-el-comando-restablecer-contrasena-falla-al-instante) para más información sobre cómo resolver esta situación.
:::

Usa este valor solo si tu política de seguridad exige explícitamente la autenticación antes del arranque — por ejemplo, en entornos regulados donde no se permite el arranque desatendido del dispositivo.

## Dónde configurarlo

Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, dirígete a **Restricciones** 2, selecciona la sección **Sistema** y localiza el ajuste **Política de encriptación** 3.

![encryption policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d3b94cb2-95d1-43da-8d4d-38d2cfcd45eb.png)

## Cómo elegir el valor correcto

<table style="min-width: 50px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1"><p>Escenario</p></th><th colspan="1" rowspan="1"><p>Valor recomendado</p></th></tr><tr><td colspan="1" rowspan="1"><p>Despliegue empresarial estándar</p></td><td colspan="1" rowspan="1"><p><code>ENABLED_WITHOUT_PASSWORD</code></p></td></tr><tr><td colspan="1" rowspan="1"><p>Dispositivos en modo quiosco o desatendidos</p></td><td colspan="1" rowspan="1"><p><code>ENABLED_WITHOUT_PASSWORD</code></p></td></tr><tr><td colspan="1" rowspan="1"><p>Entorno regulado que exige PIN antes del arranque</p></td><td colspan="1" rowspan="1"><p><code>ENABLED_WITH_PASSWORD</code> (asegura que el acceso físico siempre esté disponible)</p></td></tr><tr><td colspan="1" rowspan="1"><p>Dispositivo bloqueado en BFU y no accesible</p></td><td colspan="1" rowspan="1"><p>Recupéralo físicamente y considera cambiar a <code>ENABLED_WITHOUT_PASSWORD</code></p></td></tr></tbody></table>

## Consideraciones de seguridad

Una preocupación habitual es si `ENABLED_WITHOUT_PASSWORD` es menos seguro que `ENABLED_WITH_PASSWORD`. La respuesta depende del modelo de amenaza:

-   **Contra ataques fuera del dispositivo** (extraer el chip de almacenamiento y leerlo externamente): ambos valores ofrecen una protección equivalente mediante el FBE de Android. La clave DE se deriva de una clave ligada al hardware que no puede extraerse sin el dispositivo.
    
-   **Contra un atacante con acceso físico a un dispositivo en funcionamiento**: `ENABLED_WITH_PASSWORD` añade una capa adicional impidiendo que el dispositivo arranque de forma desatendida, pero esto debe sopesarse frente al riesgo operativo de que los dispositivos queden permanentemente inaccesibles si el usuario olvida su PIN.
    

Para la mayoría de los despliegues empresariales, `ENABLED_WITHOUT_PASSWORD` ofrece el equilibrio adecuado entre seguridad y control operativo.