Recovery and Continuity

Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.

UbID treats recovery as a security protocol, not a customer-support shortcut. The objective is to restore legitimate control after device loss, authenticator failure, or account disruption without giving one administrator, server, custodian, or recovery code unrestricted power over the identity.

A recovery design must be at least as carefully governed as ordinary access because attackers frequently target the recovery path rather than the primary authenticator.

Recovery principles

No universal recovery secret

A complete recovery capability should not be stored unprotected in one place. Distributed or threshold approaches can ensure that no single participant possesses sufficient material to take control alone.

Distribution is not enough by itself. Each recovery component requires independent encryption, authentication, custody, policy, availability, and lifecycle governance.

Staged authorization

Recovery should separate distinct stages such as:

1. Request — create a bounded recovery transaction.
2. Verify — evaluate identity, device, and contextual evidence.
3. Authorize — record the approved recovery scope.
4. Prepare — assemble protected inputs without releasing the complete secret.
5. Release — allow only the authorized components to participate.
6. Restore — perform the narrowly approved recovery action.
7. Rotate — replace affected keys, authenticators, or recovery material.
8. Evidence — retain a minimised, reviewable record of the outcome.

An identity check should not automatically become a secret release. Each transition requires explicit policy and authorization.

Evidence for recovery

Depending on the risk and deployment, recovery may consider:

• approved identity evidence;
• possession of an existing trusted device;
• authenticated communications;
• device registration history;
• biometric verification where lawfully and appropriately used;
• freshness challenges and replay protection;
• custodian approval;
• institutional policy and human review;
• protected execution evidence for sensitive reconstruction.

No single signal should be treated as universally sufficient.

Distributed responsibility

Recovery participants should know only what they need for their role. A custodian may authorize or release one protected component without learning the complete recovery secret or the contents of the holder's vault.

The final reconstruction or re-key operation should occur only in an approved destination under a bounded transaction. Complete secrets should not appear in ordinary application logs, support tools, analytics, or diagnostics.

Multi-device continuity

Recovery is one part of continuity. A controlled multi-device model allows a person to:

• approve an additional device;
• suspend or revoke a lost device;
• replace an authenticator;
• restore access without reissuing every credential unnecessarily;
• preserve identity relationships while rotating compromised keys.

New devices should not be treated as trusted merely because they know an account password or can access an email address.

Post-recovery controls

A successful recovery should trigger review and, where appropriate:

• key or authenticator rotation;
• invalidation of temporary recovery authority;
• review of device and session state;
• notification through approved channels;
• verification that protected custody is restored;
• monitoring for suspicious follow-on activity;
• retention of the policy version and authorizations used.

Recovery should leave the identity in a stronger, known state rather than preserving compromised material indefinitely.

Availability and exclusion risk

A recovery design must balance security with the risk of permanent exclusion. Overly weak recovery enables takeover; overly rigid recovery can deny legitimate users access after ordinary device loss or life events.

Institutions should test accessibility, custodian availability, succession, dispute handling, and emergency procedures without centralizing all recovery power.

What recovery does not mean

Identity recovery does not imply authority to recover, transfer, or control financial assets associated with a blockchain account. Identity continuity and asset custody are separate legal and technical responsibilities.

Public documentation boundary

The public portal does not disclose the number or placement of recovery components, custodian identities, release thresholds, key-wrapping details, transaction routes, approval rules, emergency ceremonies, or operational runbooks.

See UbID Recover, Authentication and Device Security, and Cryptographic Protection.