Set up recovery

This guide is the how-to; see Customer-controlled recovery for how it works and why it stays zero-knowledge. Recovery is org-scoped and admin-managed. All of the crypto runs in your browser or CLI — seekrit only ever stores the recovery public key and shares it cannot open.

1. Enable recovery

Choose custodians (org members who have finished key setup) and a threshold M — how many of them are required to recover.

In the web dashboard: Organization → Settings → Customer-controlled recovery → toggle each custodian on, set the threshold, then Enable recovery. The dashboard generates and splits the recovery key locally and immediately protects every environment you can decrypt.

With the CLI:

# 3-of-5 recovery: any three of these five custodians can recover.
seekrit recovery setup --threshold 3 \
  --custodian alice@example.com \
  --custodian bob@example.com \
  --custodian carol@example.com \
  --custodian dan@example.com \
  --custodian erin@example.com
# A single --custodian with --threshold 1 is the "designated recovery admin" case.

2. Cover every environment

Recovery can only protect an environment whose DEK someone wraps to the recovery key, and only a principal that can already decrypt an environment can do that. New environments are covered automatically at creation; to backfill the rest, each admin who holds grants runs:

seekrit recovery sync        # wraps every environment you can decrypt but that isn't yet covered
seekrit recovery status      # shows M-of-N, custodians, and coverage (e.g. "7/8 protected")

Repeat from other admins until coverage is complete. In the dashboard, the recovery card shows a coverage bar and a Sync coverage button.

3. Recover access

When someone loses their passphrase or leaves, an admin runs a recovery ceremony. Start it as the person who will end up with access (recovering for yourself is the default):

seekrit recovery request                 # prints a request id: rrq_…
# recover access for someone else instead:
seekrit recovery request --target-user newadmin@example.com

Each custodian then approves — unwrapping their share locally and re-wrapping it to the target:

seekrit recovery approve rrq_XXXXXXXX     # run by each custodian until the quorum is met

Once a quorum has approved, the target completes the ceremony — reconstructing the recovery key in their own client and re-granting themselves access:

seekrit recovery complete rrq_XXXXXXXX    # restores access to every covered environment

The dashboard exposes the same flow: Recover access → Start recovery, an Approve button for custodians, and Complete once the quorum is reached.

Rotating and disabling

seekrit recovery rotate --threshold 2 --custodian alice@example.com --custodian bob@example.com
seekrit recovery disable      # removes the recovery key and every recovery grant

Rotation generates a fresh recovery key, re-splits it to the custodian set you pass, and re-wraps the environments you can decrypt — run seekrit recovery sync from other admins afterward to restore full coverage. Every recovery action is written to the audit log.

Recovering without seekrit

The ceremony above runs through the API, which assumes seekrit is reachable. It doesn't have to be. A break-glass archive carries the same inputs — each environment's data key wrapped to the recovery key, plus every custodian's wrapped share — so a quorum can reconstruct the recovery key and open every environment entirely offline:

seekrit archive share   acme.json --out share-ana.json    # each custodian, on their own machine
seekrit archive decrypt acme.json --share share-ana.json --share share-bo.json --out ./recovered

Keep an archive (and a copy of seekrit archive decryptor) wherever you keep your disaster-recovery runbook. It is the version of this ceremony that still works if the network, your account, or seekrit itself is unavailable.