# 55 Air-gapped recovery identity

> v0.0.2 · role: Recover · [policy: #11 · #13, #16 (gap G4)](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

A recovery identity, and the materials it needs, kept wholly outside the tenant and offline — so a total domain compromise still leaves a way back in. It is the assumption of failure made concrete: every other recovery path in this catalog runs through something the attacker now controls.

Documentation: [Security best practices for administrator accounts](https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts) · [Recovering administrator access to your account](https://knowledge.workspace.google.com/admin/users/recovering-administrator-access-to-your-account)

## Caveats

- The recovery identity must be provable-offline — if its factor or its documentation lives in the tenant it is recovering, it is not a recovery path.
- An untested kit is a belief, not a capability — rehearse the restore, because the day you need it is the day you cannot ask a colleague how it works.

_Process control — carried out offline; no Admin Console walkthrough._

## Ongoing maintenance

- **[requires a human]** Semi-annually: refresh contents that age (codes, printed docs, contact lists) and re-seal.

## How to verify

1. Open the kit under custody rules and inventory it against the manifest: recovery identity credentials, DNS registrar access, printed runbooks — then re-seal with fresh serials.
