Disaster recovery

Backup and recovery options across all DFNS deployment models, including signer failover, Layer 4 independent recovery, and manual key backup via key export.

Backup and disaster recovery responsibilities depend on your deployment model. With fully-managed DFNS Cloud (SaaS), DFNS operates the signers and handles all backup and disaster recovery for you. With hybrid or on-premise deployments, you operate one or more signers yourself and are responsible for backing up and recovering the components in your environment. This page covers what to protect and how to recover in each case.

For MPC signers, recovery is layered: standard database backups (Layers 1 and 2), an encrypted key-share backup you can rebuild a signer from (Layer 3), and a fully independent backup encrypted with your own key (Layer 4). You can also export a wallet’s key on demand as a manual backup. Each is covered below, alongside HSM backups.

MPC signer backups

When hosting MPC signers, the following assets must be backed up:

Asset	Impact of loss	Backup approach
Core Keys Pack	Encrypts every key share at rest. If lost, all key shares become permanently unusable, meaning loss of all wallets and assets.	Store in a secrets manager with backup/replication enabled.
Key share databases	Loss of a database means losing that signer’s key shares created since the last backup.	Standard database backup procedures (pg_dump, continuous archiving, replicas).
mTLS certificates and private keys	Required for signer authentication to DFNS APIs and delivery server.	Store in a vault or secrets manager.
Signer configuration	Needed to redeploy signers.	Store in version control or a configuration management system.

Key shares backup layers

MPC key shares are protected at four layers. Recover in order: start with Layer 1, then each following layer is the fallback when the previous one is unavailable.

Layer	What it is	When you use it
Layer 1	Database replication and point-in-time recovery (PITR)	First-line recovery of a signer’s key-share database, to any point in time.
Layer 2	Database snapshots	Restore the database from a periodic snapshot when PITR is unavailable.
Layer 3	An encrypted copy of every key share in an S3 bucket, written at key creation	Rebuild a signer when its database and Layers 1 and 2 are gone.
Layer 4	Key shares re-encrypted with your own key, in a bucket you own	Recover independently of DFNS.

Layers 1 and 2 are standard database backups you configure. Layers 3 and 4 are key-share backups the signer writes automatically.

Recovery scenarios

Scenario	Recovery
Core Keys Pack loss	Unrecoverable without Layer 4. Layers 1 to 3 all depend on the Core Keys Pack. With Layer 4, you can recover independently.
Database loss	Restore from a database backup (Layer 1 or 2). If the database and its backups are gone, rebuild the signer from the Layer 3 key-share backup. Layer 4 additionally lets you recover independently of DFNS.
Single signer failure	Deploy a replacement signer, restore its configuration, certificates, and database access. If the threshold is still met by remaining signers, signing continues uninterrupted during recovery.
Too many signers lost to meet the threshold	If you lose more signers than your scheme tolerates (for example, more than 2 in a 3-of-5 setup), signing is unavailable until enough signers are restored to meet the threshold again.

Losing the Core Keys Pack without Layer 4 backup set up means losing access to all wallets and the assets they hold.

Layer 3 disaster recovery

Every time a signer creates a key share, it writes the same encrypted bytes to a write-only S3 bucket, in addition to its database. Layer 3 is that copy: identical ciphertext to the database, encrypted with the signer’s own key.

Use it to rebuild a signer’s key-share database when the database and its standard backups (Layers 1 and 2) are gone. Recovery needs the signer’s Core Keys Pack to be intact, so Layer 3 is not independent of DFNS. If the Core Keys Pack itself is lost, use Layer 4.

For the recovery procedure, contact our .

Layer 4 disaster recovery

Layer 4 works like Layer 3 — each signer writes its encrypted share to a write-only S3 bucket you own, at key creation — except the share is encrypted with your own Ed25519 public key, not the signer’s. DFNS never has your private key, so only you can decrypt these backups.

That makes Layer 4 a fully independent recovery path: you can reconstruct your keys from only your private key and the backup files, even if DFNS is unavailable or the signer’s Core Keys Pack is lost. It requires a dedicated MPC cluster and works with any MPC deployment option; without one, use manual key backup instead.

To enable Layer 4, or for the setup or recovery procedure, contact our .

Manual key backup (key export)

You can export a copy of any MPC wallet’s key on demand, giving you a backup you hold outside DFNS. It is the fallback available to most customers, whatever their deployment model. As with Layer 4, DFNS never handles a plaintext key (how export works).

A reconstituted key is a full, standalone private key — a single point of failure. Anyone who obtains it controls the wallet and its assets, and DFNS cannot guarantee the security of transactions signed with it. Once it leaves DFNS, its security is entirely your responsibility: storage, encryption at rest and in transit, access controls, usage restrictions, and protection against theft or misuse.

Manual export is a point-in-time backup: you can only recover keys you exported before a loss. To have every key covered automatically, use Layer 4. Treat the exported key as break-glass: store it offline with tightly restricted access.

For the step-by-step export and recovery procedure, including an offline signing test, see the export keys guide.

HSM backups

When using an HSM integration, the following assets must be backed up:

Asset	Impact of loss	Backup approach
HSM master key	All wrapped keys become permanently unusable. Loss means loss of all wallets and assets.	Use your HSM vendor’s key backup mechanism (e.g. Thales Luna Backup HSM, cloning domain). Store backups in a physically separate, secure location.
Wrapped-key database	Loss means losing all wallets and assets created since the last backup.	Standard database backup procedures (pg_dump, continuous archiving, replicas). Data is encrypted at rest but should still be treated as sensitive.
mTLS certificates and private keys	Required for HSM Driver authentication to DFNS APIs.	Store in a vault or secrets manager. The intermediate certificate private key is especially critical.
HSM Driver configuration	Needed to redeploy the Driver.	Store in version control or a configuration management system.

Recovery scenarios

Scenario	Recovery
HSM Driver host failure	Deploy a new host, install the HSM client library and HSM Driver, restore configuration and mTLS certificates. The Driver resumes signing automatically.
HSM failure	Provision a replacement HSM with the same master key (restored from backup). The HSM Driver resumes without further changes.
Database loss	Restore from backup. Wallets created after the last backup, and the assets they hold, are lost.
Master key loss	Unrecoverable. All wallet keys encrypted with that master key are permanently inaccessible.

Losing the HSM master key means losing access to all wallets and the assets they hold. Back it up immediately after generation.

Proving you can recover

You can demonstrate — to yourself, an auditor, or a regulator — that your backups actually reconstitute working keys, without moving any real assets. Run this as a periodic recovery drill. The proof comes at two levels:

1. Cryptographic verification (always performed). When you reconstruct keys during Layer 4 recovery or manual key export, the recovery tool reassembles each private key from its shares and checks it against the known public key. A match proves the backup reconstitutes the exact key that controls your wallet’s address.
2. End-to-end signing test (optional, strongest). For proof that a recovered key can authorize a transaction, sign a zero-value transaction on a testnet with the recovered key and broadcast it. A recovered key controls the same address on every chain, so a successful testnet signature demonstrates control of the real address without touching mainnet funds. Signing stays on your offline computer; only the signed transaction goes online. See Verify a recovered key (Layer 4) or the offline signing test in the export keys guide.

Run the drill on a schedule (for example quarterly) and whenever your recovery setup changes — a new recovery key, a new bucket, or a deployment migration — and keep a record of each run (date, keys tested, outcome) as audit evidence.

Because the drill runs on a testnet and the private key never goes online, you can prove that the recovery process is functional at any time without exposing key material or moving assets.