# Postura de seguridad

> Entiende la postura de seguridad en Android con Applivery. Aprende qué significan Seguro, En riesgo y Potencialmente comprometido y cómo actuar ante un dispositivo comprometido.

Source: https://docs.applivery.com/es/device-management/android/security-posture/  •  Last updated: 2026-08-08

**Answers:** ¿Qué es la postura de seguridad de un dispositivo Android? · ¿Dónde veo la postura de seguridad en Applivery? · ¿Qué significa "Potencialmente comprometido"? · ¿Detecta Applivery los dispositivos Android rooteados? · ¿Por qué mis dispositivos AOSP no tienen postura de seguridad? · ¿Puedo aplicar automáticamente una política restrictiva a un dispositivo comprometido? · ¿Cuál es la diferencia entre postura de seguridad y estado de conformidad? · ¿Una postura de seguridad mala bloquea el dispositivo automáticamente?

**Key topics:** Postura de seguridad en Android, Play Integrity API, Detección de dispositivos comprometidos, Conformidad del dispositivo, Applivery, Android, Google Play Services

---

**TL;DR:** Applivery informa de si el sistema operativo de un dispositivo Android ha sido manipulado, mediante un escudo en el listado de dispositivos y una comprobación de conformidad dentro del dispositivo. Necesita Google Mobile Services, así que AOSP no está cubierto.

No todos los riesgos de un dispositivo vienen de un ajuste que puedas configurar. Un dispositivo puede cumplir todas las políticas que le has asignado y aun así no ser de fiar, sencillamente porque alguien ha modificado su sistema operativo. La **postura de seguridad** es la señal que te avisa de que eso ha ocurrido.

Responde a una pregunta distinta de la del resto de tus políticas: no _"¿está este dispositivo configurado como pedí?"_ sino _"¿puedo seguir confiando datos corporativos a este dispositivo?"_.

## Qué te dice la postura de seguridad

Android Enterprise evalúa cada dispositivo y reporta uno de estos tres valores:

<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>Valor</p></th><th colspan="1" rowspan="1"><p>Qué significa</p></th></tr><tr><td colspan="1" rowspan="1"><p><strong>Seguro</strong> (<code>SECURE</code>)</p></td><td colspan="1" rowspan="1"><p>El dispositivo es seguro.</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>En riesgo</strong> (<code>AT_RISK</code>)</p></td><td colspan="1" rowspan="1"><p>El dispositivo puede ser más vulnerable ante actores maliciosos de lo recomendable para usarse con datos corporativos.</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Potencialmente comprometido</strong> (<code>POTENTIALLY_COMPROMISED</code>)</p></td><td colspan="1" rowspan="1"><p>El dispositivo puede estar comprometido y los datos corporativos que contiene podrían ser accesibles para terceros no autorizados.</p></td></tr></tbody></table>

**Potencialmente comprometido** es el valor que obtienes ante un dispositivo rooteado. Conviene tratarlo como un incidente y no como un aviso: a partir de ahí ya no puedes dar por hecho que las restricciones de tu política se estén aplicando de verdad, porque el sistema operativo que las aplica es justo la parte que se ha modificado.

## Dónde consultarla en el panel

Applivery muestra la postura de seguridad en dos sitios, con dos niveles de detalle distintos.

### En el listado de dispositivos

Cada dispositivo del listado muestra un **escudo** junto al campo de la política. Es un resumen de las [comprobaciones de conformidad](https://docs.applivery.com/es/device-management/general-settings/compliance-checks/) del dispositivo:

<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>Escudo</p></th><th colspan="1" rowspan="1"><p>Qué significa</p></th></tr><tr><td colspan="1" rowspan="1"><p>🟢 <strong>Verde</strong></p></td><td colspan="1" rowspan="1"><p>El dispositivo es conforme y su postura es Segura.</p></td></tr><tr><td colspan="1" rowspan="1"><p>⚪ <strong>Gris</strong></p></td><td colspan="1" rowspan="1"><p>Algo en el dispositivo requiere atención, pero no es la postura de seguridad.</p></td></tr><tr><td colspan="1" rowspan="1"><p>🔴 <strong>Rojo</strong></p></td><td colspan="1" rowspan="1"><p>La postura de seguridad es <strong>En riesgo</strong> o <strong>Potencialmente comprometido</strong>.</p></td></tr></tbody></table>

![security posture devices list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/27c6cb31-c0b5-4e8b-8dca-66b11e9e8f87.png)

De aquí se derivan dos cosas, y las dos importan cuando estás triando un parque:

-   **El rojo siempre es un problema de seguridad**, nunca una configuración pendiente. Gris y rojo son categorías de incidencia distintas y piden respuestas distintas: el gris es operativo, el rojo es una cuestión de si se puede seguir confiando en el dispositivo.
    
-   **Los dos valores de riesgo levantan el mismo escudo rojo.** Para distinguir _En riesgo_ de _Potencialmente comprometido_, abre el dispositivo.
    

### En las comprobaciones de conformidad del dispositivo

Abre el dispositivo y ve a la sección **Overview**, donde encontrarás los **Compliance checks**. Un dispositivo cuya postura esté en riesgo o comprometida tiene una comprobación propia, en rojo, titulada con el valor de la postura: **En riesgo** o **Potencialmente comprometido**.

![security posture device overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3a32e80c-2687-47ff-abfd-7bb7c8a39b41.png)

Dentro, por cada riesgo detectado, obtienes:

-   **El nombre del riesgo** — _SO desconocido_, _SO comprometido_ o _Evaluación de hardware fallida_ — con un tooltip que explica qué ha detectado Play Integrity.
    
-   **El consejo de Google** para mitigarlo, dirigido a ti como administrador. Por ejemplo: _"El usuario debería bloquear el bootloader de su dispositivo"_.
    

Un dispositivo cuya postura sea **Segura** no muestra ninguna comprobación de seguridad. Aquí la ausencia es la buena noticia: no hay una entrada en verde que lo confirme, así que no interpretes "no hay comprobación de seguridad" como "no se ha evaluado".

## Por qué se marca un dispositivo

Cuando la postura no es **Segura**, el riesgo concreto que hay detrás es uno de estos tres:

<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>Riesgo</p></th><th colspan="1" rowspan="1"><p>Qué ha detectado Google</p></th></tr><tr><td colspan="1" rowspan="1"><p><strong>SO desconocido</strong> (<code>UNKNOWN_OS</code>)</p></td><td colspan="1" rowspan="1"><p>El dispositivo ejecuta un sistema operativo desconocido: la comprobación <code>basicIntegrity</code> se supera, pero <code>ctsProfileMatch</code> falla.</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>SO comprometido</strong> (<code>COMPROMISED_OS</code>)</p></td><td colspan="1" rowspan="1"><p>El dispositivo ejecuta un sistema operativo comprometido: la comprobación <code>basicIntegrity</code> falla.</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Evaluación de hardware fallida</strong> (<code>HARDWARE_BACKED_EVALUATION_FAILED</code>)</p></td><td colspan="1" rowspan="1"><p>El dispositivo no ofrece una garantía sólida de integridad del sistema: falta la etiqueta <code>MEETS_STRONG_INTEGRITY</code> en su veredicto de integridad.</p></td></tr></tbody></table>

Existe un cuarto valor, **Riesgo de seguridad no especificado** (`SECURITY_RISK_UNSPECIFIED`), que aparece cuando Google no concreta el motivo. No es accionable por sí mismo.

Los tres proceden de la **Play Integrity API** de Google, que es el componente que realmente inspecciona el dispositivo. Applivery reporta el veredicto; no lo genera.

:::info
Como la evaluación ocurre del lado de Google, la postura es un _informe_, no un _ajuste_. No hay nada que activar en una política para habilitarla, ni ningún valor que puedas configurar para hacerla más estricta.
:::

## Los dispositivos AOSP no tienen postura de seguridad

La Play Integrity API forma parte de **Google Play Services**. Los dispositivos AOSP — las builds sin GMS, habituales en terminales rugerizados e industriales — no tienen Google Play Services, así que no hay ninguna señal de integridad que Android pueda reportar ni postura que Applivery pueda mostrar.

No es una limitación de Applivery, y ningún MDM puede sortearla: el componente que realiza la comprobación sencillamente no está presente en el dispositivo. Si necesitas detección de integridad o de root en un parque AOSP, tiene que venir de una solución **Mobile Threat Defense (MTD)** de terceros.

## Actuar ante un dispositivo comprometido

La postura de seguridad informa de un riesgo, pero no actúa sobre él. Bloquear o borrar es una decisión aparte, y tienes tres vías:

-   [**Comandos remotos**](https://docs.applivery.com/es/device-management/android/commands/remote-commands/), aplicados manualmente desde el panel: bloquear el dispositivo, restablecer la contraseña o borrarlo. Es la respuesta directa ante un dispositivo que acabas de ver marcado.
    
-   [**Policy Enforcement Rules**](https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/), para acciones automáticas de bloqueo y borrado pasados unos días. Fíjate en a qué reaccionan: a un ajuste de la política que _no se puede aplicar_ en el dispositivo, no a la postura de seguridad. Son un complemento útil, no un consumidor de esta señal.
    
-   [**Reglas de automatización**](https://docs.applivery.com/es/device-management/general-settings/automation-rules/), para aplicar automáticamente una política restrictiva de cuarentena. Actúan sobre [audiencias de dispositivos](https://docs.applivery.com/es/device-management/general-settings/device-audiences/), que se construyen a partir de etiquetas, así que necesitas algo que etiquete antes el dispositivo. Eso es lo que aporta una integración de Mobile Threat Defense como [Check Point Harmony Mobile](https://docs.applivery.com/es/device-management/integrations/security/checkpoint-harmony-mobile-integration/): sus grupos de riesgo se corresponden con las etiquetas de Applivery, las etiquetas alimentan una audiencia de dispositivos y la regla de automatización aplica la política de cuarentena.
    

:::warning
**Una regla de automatización no puede borrar un dispositivo.** Sus únicas acciones son aplicar una política y añadir un Smart Attribute: configura dispositivos, no envía comandos. Si hay que borrar un dispositivo comprometido, hazlo manualmente con un comando remoto o haz que la política de cuarentena lleve sus propias Policy Enforcement Rules para bloquear y después borrar. No prometas un flujo de un solo paso del tipo "el MTD lo detecta y Applivery lo borra", porque no es lo que ocurre.
:::
    

## Postura de seguridad y estado de conformidad no son lo mismo

Es fácil confundirlas, y la diferencia importa cuando tienes que explicar un dispositivo marcado:

<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></p></th><th colspan="1" rowspan="1"><p>Postura de seguridad</p></th><th colspan="1" rowspan="1"><p>Estado de conformidad</p></th></tr><tr><td colspan="1" rowspan="1"><p>Pregunta que responde</p></td><td colspan="1" rowspan="1"><p>¿Se puede confiar en el sistema operativo?</p></td><td colspan="1" rowspan="1"><p>¿Cumple el dispositivo las políticas que le asigné?</p></td></tr><tr><td colspan="1" rowspan="1"><p>Quién decide</p></td><td colspan="1" rowspan="1"><p>Google, mediante la Play Integrity API</p></td><td colspan="1" rowspan="1"><p>La configuración de tu política</p></td></tr><tr><td colspan="1" rowspan="1"><p>Causa típica de un problema</p></td><td colspan="1" rowspan="1"><p>El dispositivo está rooteado o ejecuta un SO modificado</p></td><td colspan="1" rowspan="1"><p>Un ajuste obligatorio no se aplica, o el usuario ha cambiado algo</p></td></tr><tr><td colspan="1" rowspan="1"><p>¿Se puede configurar?</p></td><td colspan="1" rowspan="1"><p>No — se reporta, no se establece</p></td><td colspan="1" rowspan="1"><p>Sí — depende de las políticas que definas</p></td></tr></tbody></table>

Un dispositivo puede ser perfectamente conforme y estar a la vez **Potencialmente comprometido**, y esa combinación es precisamente la que conviene vigilar: todo parece correcto, pero la capa que lo garantiza ya no es de fiar.