# 57 Air-gapped recovery identity

> DRAFT · v0.1.0 · 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)

Before this control: [№19 Break-glass admin + offline backup codes](breakglass-admin.md)

A sealed kit, kept wholly outside the tenant, that recovers the domain when every in-tenant admin — the break-glass account ([19 Break-glass admin + offline backup codes](breakglass-admin.md)) included — belongs to the attacker. Google's documented way back in is domain verification: support restores super-admin access to whoever proves ownership of the primary domain by setting a DNS record, which makes the registrar login the tenant's real root key. The kit's job is keeping that login exercisable and non-circular when the tenant is hostile: registrar/DNS-host credentials with their second factor, the facts support asks for (customer ID, support PIN, billing account or purchase records), a recovery email on infrastructure unrelated to the tenant, and the printed runbook for the recovery request itself.

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.
- A registrar login whose password reset or second factor lands in the tenant it recovers is circular — the registrar account must stand entirely on infrastructure the tenant cannot touch, or the attacker holds the root key too.
- 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: registrar/DNS credentials and their second factor, customer ID and support PIN, recovery email credentials, printed runbooks — then re-seal with fresh serials.

2. Rehearse the entry point from a clean machine: sign in to the registrar with the kit's credentials and confirm the recovery email receives mail — touching nothing inside the tenant.