net-kingdom/workplans/NK-WP-0053-identity-restore-drill-cadence.md

---
id: NK-WP-0053
type: workplan
title: "Quarterly isolated identity restore drill"
domain: infotech
repo: net-kingdom
status: finished
flavor: implementation
owner: claude
topic_slug: netkingdom
created: "2026-10-23"
updated: "2026-10-30"
related:
  - NK-WP-0049
  - disaster-control/BackupPolicy.md
state_hub_workstream_id: "7c80ba09-8bd5-540e-8dd3-feb85e201ef3"
---

# NK-WP-0053 — Quarterly isolated identity restore drill

> **Finished 2026-10-30.** Drill passed 2026-10-29 (next due 2027-01-29, held in disaster-control's
> restore-proof register); G1 decided (`e8935fa6`, Scaleway intake under NK-WP-0055-T07).
>
> **2026-10-31:** second drill passed on generation `20261031T034845Z-a13dc92e2c61` (post bind split, all five
> stages as `admin`; [evidence](../docs/evidence/2026-10-31-identity-restore-drill/drill.json)). Next due **2027-01-31**.
>
> **2026-10-28** (founder triage): T02, T04 and T03 are finished now, not at the 2027-01-31
> deadline. One attended `admin` run covers T02 and T04; T03 follows from its results. The
> workplan then closes. The quarterly repeat lives in disaster-control's restore-proof register
> (next due date recorded there), not in an active workplan.

Intake for gap G3 of `NK-WP-0049-T24`. On 2026-10-23 the founder resolved decision
`e4c288d9` with the recommended split: G1 (a single off-host provider) is an
accepted residual risk until 2027-01-31; G2 (off-host host-loss detection) is
linked to the outside-node watchdog that `RAPP-TELEMETRY-WP-0001-T04` already
owes; G3 (no recurring drill) is this workplan.

So far each identity restore has been proved once: LLDAP (NK49-T16), privacyIDEA
token material (T31) and audit (T20), and the archive recovery. This workplan
turns the existing isolated tooling into a recurring, evidenced drill. It adds no
grant, scheduler or production effect; each live drill is an attended owner run.

## Define the drill and register it with disaster-control

```task
id: NK-WP-0053-T01
status: done
priority: medium
state_hub_task_id: "6bdfac30-75a8-5a1a-8d66-2fbb0c093958"
```

Write `docs/identity-restore-drill.md`: a quarterly cadence aligned with
disaster-control `BackupPolicy.md`, the fixed scope (archive retrieval and
verification, isolated LLDAP stage, privacyIDEA token-material check), reuse of
`tools/bootstrap-recovery/run-isolated-*.sh` without changes, the evidence
location `docs/evidence/<date>-identity-restore-drill/`, and pass/fail criteria.
Ask disaster-control to add the identity lane to its restore-proof register.

**Done when:** the drill document is reviewed and disaster-control records the
identity lane with a quarterly restore-proof schedule.

2026-10-23: done. The drill procedure is `docs/identity-restore-drill.md`.
disaster-control adopted the lane as DISCTL-WP-0004 (commits 9ca7419 and
a54ff81). Changes there: AssetRegister `backup-netkingdom-identity`, three
DataRegister classes, BackupPolicy checks M-7 (25-hour freshness) and M-8
(quarterly drill), G1/G2 in its open-gaps table until 2027-01-31, and an
RTO/RPO matrix row. RTO stays TBD until the first drill. When the first drill
evidence lands, tell disaster-control (its DISCTL-WP-0004-T03 is waiting on it).

## Run the first scheduled drill

```task
id: NK-WP-0053-T02
status: done
priority: medium
depends_on: [NK-WP-0053-T01]
state_hub_task_id: "8b2cdf5a-69e1-59c6-8e4e-e478f44f77fb"
```

Run the drill in an attended session and retain the value-safe receipts. Any
failure becomes a finding in NK-WP-0049 or its successor; it is never repaired
silently.

**Done when:** a dated, verified evidence set exists and the next due date is
recorded.

**Done 2026-10-29** ([evidence](../docs/evidence/2026-10-29-identity-restore-drill/drill.json)), operated by `admin`
(founder): stages 1 to 4 passed on generation `20261019T034919Z`, stages 1 and 5 on `20261029T230600Z`. The drill
exposed that no generation existed from 2026-10-20 to 2026-10-29 (finding in NK-WP-0055-T07); the fresh
generation was captured after the founder freed Storage Share space. Two Authelia attempts (mistyped password),
one interrupted privacyIDEA start and one MFA attempt with a mistyped login name are kept under `attempts/` with
their causes, as are two MFA runs on the pre-enrolment generation. Next due: **2027-01-29**.

## Extend the drill to Authelia and by-user MFA, operated by admin

```task
id: NK-WP-0053-T04
status: done
priority: medium
assignee: claude-code
depends_on: [NK-WP-0053-T01]
state_hub_task_id: "20264166-3c88-52d0-a7b4-dd3831c7a685"
```

The drill document was written before the Authelia stage (`run-isolated-authelia.sh`) and
the by-user MFA stage (`run-isolated-privacyidea-mfa.sh`) existed, and it lists retained-factor
MFA as out of scope. Add both stages to `docs/identity-restore-drill.md`, and name `admin`
as the operator of record and the MFA test subject (founder intent, 2026-10-24: backup
validation is platform operations, with `platform-root` kept for break-glass). Add the check
of `docs/crisis-custody-list.md` to the drill's preparation, and record in the evidence which
identity ran each stage.

`admin@coulomb` received an OTP on 2026-10-24, so it is first present in the backup captured
after 2026-10-25 03:45 UTC. The first `admin`-operated MFA run must use a generation from
after that capture; an older generation holds no token for `admin` and proves nothing.

**Done when:** the drill document lists all five stages with `admin` as operator, the first
`admin`-operated MFA run has passed on a post-enrolment generation, and its evidence names
the identity used.

**Done 2026-10-29:** the first `admin`-operated by-user MFA run passed on generation `20261029T230600Z` (after the
2026-10-25 enrolment); `drill.json` names the identity per stage.

**2026-10-28:** the drill document now lists all five stages (Authelia and by-user MFA added,
retained-factor MFA no longer out of scope) with `admin` as operator, and the evidence records
the identity and login per stage. Remaining: the first `admin`-operated MFA run on a
post-2026-10-25 generation.

## Review the G1 residual-risk acceptance

```task
id: NK-WP-0053-T03
status: done
priority: low
decision_id: "e8935fa6-ada8-4d15-bef2-4deb9671502a"
state_hub_task_id: "0fa4add7-3d53-51af-a2a2-ea9c63a2d628"
```

Use the drill results to put the single-provider question back to the founder.

**Done 2026-10-30, founder decision `e8935fa6`:** open a second-provider intake. railiance-platform adds the
backup profile's planned Scaleway secondary for the full identity bundle (`application-archives/net-kingdom/`,
own scoped credential, readback proof). The G1 acceptance continues until 2027-01-31 or until the second copy
is proven, whichever is first. Basis: the drill passed, but the single 10 GiB Storage Share account filled and
no generation was written 2026-10-20..29 without alert (NK-WP-0055-T07). Quota, CNPG remote retention and the
G2 alert remain required. The intake is tracked in NK-WP-0055-T07.