> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/product-guide/configuracoes/rmm/kill-switch.md).

# Kill Switch (device roubado)

Quando um dispositivo é declarado roubado, o RMM aciona uma cascata de camadas defensivas que juntas tornam o hardware **antieconômico para reutilizar** — sem prometer o que a plataforma Android não entrega.

Aberta em `/stolen-devices` (ledger) + botão **Mark stolen** no painel de detalhe de qualquer dispositivo em `/sysadmin`.

## O que o Kill Switch faz

Ao marcar um device como roubado, em uma única ação:

1. **Lock imediato** — o device trava a tela via comando AMAPI `LOCK`
2. **Lost Mode** com **mensagem de retorno** + **telefone de contato** exibidos em tela cheia (via `START_LOST_MODE`)
3. **Swap de policy** — o device passa a rodar sob a policy `stolen` do tenant (kiosk restritivo, sem apps, sem câmera, sem USB debug, sem unknown sources)
4. **Snapshot da policy anterior** — se o device for recuperado, a policy original volta com um clique em "Recovered"
5. **Log de auditoria** — cada passo fica no `-logs` do tenant
6. **SIM swap e location** — continuam alertando (features já existentes)

## O que o Kill Switch **não** faz — sendo honesto

* ❌ **Não impede o device de ligar** — nenhum MDM (Intune, Workspace ONE, Knox, DataDike) consegue "brickar" hardware Android
* ❌ **Não impede factory reset local** por recovery se o bootloader estiver destravado (raro em enterprise, mas possível)
* ❌ **Não impede troca de placa-mãe** — nesse ponto vira outro device

O objetivo é **empilhar barreiras** para que o custo de recuperar (tempo do ladrão + risco de FRP + peças) supere o valor de revenda.

## Camadas empilhadas

O Kill Switch é a **camada 5** da nossa estratégia anti-roubo. As outras 4 dependem de configuração prévia da organização — o RMM não pode ativá-las sozinho.

| Camada                                     | O que faz                                                                                                                           | Configuração                                                                                                                                  |
| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **1. FRP (Factory Reset Protection)**      | Após reset, device exige o email admin da organização. Sem ele, para na tela de boot.                                               | Setar `frpAdminEmails: ["ti@suaempresa.com"]` na policy stolen. O RMM aplica junto com o wipe usando a flag `PRESERVE_RESET_PROTECTION_DATA`. |
| **2. Zero-Touch Enrollment (KME)**         | Devices comprados via KME re-baixam a policy da mesma conta pós-reset. Mesmo restaurado, o device volta para a policy stolen.       | Comprar hardware via Google KME (canal Zero-Touch autorizado). Configurar em `zero-touch.google.com`.                                         |
| **3. Bootloader locked + Verified Boot**   | Impede reflash com firmware customizado.                                                                                            | Configuração de fábrica. Enterprise Android devices (Samsung, Zebra, Honeywell) vêm com bootloader travado.                                   |
| **4. Samsung Knox Guard / OEM APIs**       | Marca o IMEI como banido no servidor Samsung. Device conecta na rede pós-reset → lock permanente que nem wipe nem recovery removem. | Contrato Samsung Knox Guard + envio do IMEI para a API Samsung. **Só devices Samsung enterprise.**                                            |
| **5. Kill Switch DataDike (esta feature)** | Cascade comportamental via AMAPI padrão — funciona em qualquer device Android gerenciado.                                           | Um clique em "Mark stolen". A policy `stolen` deve existir uma vez.                                                                           |

## Preparação — policy "stolen"

O admin cria **uma vez** uma policy AMAPI chamada `stolen` (ou o nome que preferir) em `/policies` com:

* **Kiosk mode** — app único (pode ser um app corporativo que só mostre "STOLEN — RETURN TO ACME")
* **Câmera / microfone / USB debug / unknown sources** = disabled
* **`maximumFailedPasswordsForWipe = 3`** — 3 senhas erradas → wipe automático
* **`frpAdminEmails`** = email da equipe de TI da organização
* **`passwordRequirements.passwordQuality = COMPLEX`** — dificulta força bruta

## Recuperação

Se o device for recuperado (funcionário achou, foi entregue):

1. Vá em **Compliance & Governance → Stolen devices**
2. Clique **Recovered** na linha do device
3. O RMM enfileira:
   * `STOP_LOST_MODE` — remove a tela vermelha
   * Restaura a policy que estava antes do roubo
4. Log de auditoria registra a recuperação com o nome do admin

## Fluxo de operação recomendado

Quando o funcionário reporta roubo/perda:

1. **T+0**: Admin marca stolen no RMM (login → Sysadmin → device → Mark stolen)
2. **T+segundos**: Device recebe lock + lost mode + policy stolen
3. **T+horas**: Se o ladrão trocar SIM, alerta imediato (SIM swap detection)
4. **T+dias**: Localização continua sendo capturada em qualquer network
5. **Recuperado**: Admin marca "Recovered" → policy anterior restaurada
6. **Não recuperado**: Se após N dias o device sumiu de vez, admin pode fazer `WIPE` com `PRESERVE_RESET_PROTECTION_DATA` — pós-reset, o device só passa da tela de boot com o email admin FRP

## Auditoria

Cada ação de mark/unmark fica registrada em:

* **Audit log** do tenant (`-logs`) — busca por `DEVICE_MARKED_STOLEN` ou `DEVICE_UNMARKED_STOLEN`
* **History collection** dedicada (`-killSwitchHistory`) — GET `/api/v1/kill-switch/history/:deviceId` retorna a série completa
* Toda mudança de policy vai no policy version history existente

## Permissão

A ação de marcar/desmarcar exige a permissão **`devices.wipe`** (mesma classe de ação destrutiva). Grupos `HELP_DESK` e `AUDITOR` não conseguem por padrão — só `ADMIN` e `OPERATOR`.