Protect recovery credentials

Recovery credentials must survive the same disaster as the data. That sounds obvious, and people violate it constantly. The usual way is a circular dependency. The restic password lives in the password manager. The password manager’s vault is backed up in the restic repository. Now each one requires the other. The circle looks fine every day, until the day both ends are gone.

There’s a second, opposite pressure. Credentials also need narrower access than routine backup writing. The server that creates backups every night should hold a credential that can write snapshots but not delete them. Otherwise anyone who compromises the server can destroy the history too. That’s the exact ransomware scenario backups exist for.

Map every credential

Create a credential map with locations only, no values. It must be safe to print and pass around:

restic password: password manager emergency record
storage write credential: server secret store
storage delete credential: separate administrator account
recovery instructions: offline runbook copy

Each line answers one recovery question. Where is the repository password when the laptop is dead? Where is the storage credential when the server is gone? Who can delete old data, and is that account separate from the machines doing daily writes?

Then apply the survival test to each row. Does this location share a fate with the data it opens? A password manager emergency kit printed and stored at a relative’s house survives your house fire. A password.txt on the backed-up laptop doesn’t.

The offline runbook copy matters for the same reason. Instructions stored only in the wiki are unavailable exactly when the wiki’s server is what died.

Drill it

The map is a claim. A drill is proof. Have a second authorized person locate every credential in a drill, using only the map, without revealing the values in notes or logs. A partner, a colleague, or you in six months should be able to go from the map to an opened repository.

If they get stuck, the map is wrong. Fix it now, not during the incident.

The rule that anchors all of this: never store the only decryption key beside the only backup copy, or only on the protected machine. Any single place that holds the only copy of a recovery credential is a single point of failure, no matter how secure it is.