HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Wallets & recovery

What happens if an employee leaves or loses a signing device?

3 min read

Your authority and recovery design should define how the business handles unavailable participants and departing staff. Planning this before an incident helps avoid depending on one person’s continued availability.

Identify which responsibility is affected

A departing employee may have account access, approval responsibility, a device used for authorization, or another operational role. These are not necessarily the same as holding a cryptographic signing share. Start by identifying the exact access that must change. Record the affected wallet and environment, and involve the people responsible for the supported offboarding or recovery process. Avoid solving a staffing problem by informally sharing a replacement person’s credentials.

Remove old access as well as adding new access

Continuity is only half the job. The organization also needs to know that a former employee or lost device no longer has inappropriate authority. Ask which supported changes revoke access, which records demonstrate the change, and whether outstanding approvals need review. Do not assume that changing a contact name or an application password changes every wallet-related permission. Each affected role should be checked at the boundary where it actually grants access.

Prepare the procedure before it is urgent

Build an offboarding checklist around your real deployment and assign an owner to each action. Include a case where the employee cannot participate, such as a lost device or unexpected absence. Test only through an agreed safe workflow, retaining the results without recording secrets in the checklist. If the necessary replacement or recovery operation is not enabled, escalate that dependency rather than improvising a signing process. The goal is continued legitimate control without preserving unwanted access.

Illustrative example

A pilot rehearses an unavailable approver and records who may authorize the next permitted recovery step.

In plain language

Recovery is an authority decision, not just a backup

A backup helps preserve information; a recovery process determines how access or authority can be restored when something is lost or unavailable. Those are related but different jobs. For a business wallet, the plan should say who can start recovery, what evidence they must provide, who approves it, and what old access is removed afterward. It should also explain what happens if the usual person, device, or service cannot participate. A process that quietly lets one provider replace the customer’s authority may change the practical custody model, even if everyday signing uses several participants. Do not assume a support team can override the rules or retrieve lost signing material. Ask for the supported procedure for your exact deployment and rehearse it in an agreed safe environment. Record responsibilities and escalation contacts without storing secret recovery material in the same document as ordinary operating instructions.

In plain language

A policy needs a person responsible for it

A policy is a set of rules about what should be allowed, refused, or reviewed. Software can help apply and record those rules, but someone still needs to decide what they mean for the business. Name the owner of the policy, the people permitted to change it, and the person responsible when an exception occurs. An approval should apply to a clearly identified version or request; otherwise a later change can make an old approval misleading. Keep the technical decision separate from the business decision when they are not the same. For example, a proposal may satisfy a configured limit while still needing a budget owner’s agreement. This is not unnecessary bureaucracy: it lets different teams understand the same result without assuming that another team has completed work that is still outstanding. Start with a small, explicit responsibility map and test the handoffs.

Conditions & limitations

Do not assume an automatic replacement, unchanged wallet address, or provider-assisted recovery. Those outcomes depend on the actual deployment and enabled procedure.

What to do next

Document offboarding and recovery responsibilities, then rehearse through an authorized route without exposing secrets.

Authority and recovery guide ↗