Disaster recovery

Backup strategies and recovery options for MPC and HSM deployments, including signer failover procedures and Layer 4 independent recovery.

When you run signing infrastructure on your own premises (hybrid or on-premise), you are responsible for backup and disaster recovery of the components in your environment. This page covers what to protect, recovery scenarios, and the Layer 4 independent recovery option.

For the fully-managed DFNS Cloud deployment, DFNS handles all backup and disaster recovery.

MPC signer backups

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

Asset	Impact of loss	Backup approach
Encryption keys	All encrypted key shares become permanently unusable. Loss means 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.

Recovery scenarios

Scenario	Recovery
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.
Database loss	Restore from backup. Key shares created after the last backup are lost. With Layer 4, you can recover independently using your backup private key.
Encryption key loss	Unrecoverable without Layer 4. All key shares encrypted with those keys are permanently inaccessible. With Layer 4, you can recover independently.
Multiple signer failures (below threshold)	Signing is unavailable until enough signers are restored to meet the threshold.

Losing your encryption keys without Layer 4 means losing access to all wallets and the assets they hold.

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 polling 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.

Layer 4 disaster recovery

Layer 4 is an add-on for dedicated MPC clusters that gives you a fully independent recovery path. It automatically encrypts each key share with your Ed25519 public key during wallet creation and stores the encrypted backup in an S3 bucket you own.

Layer 4 is available for any MPC deployment option: fully managed by DFNS, hybrid, or on-premise.

How it works

When Layer 4 is enabled, each signer encrypts its key share with your public key every time a key is generated, imported, or copied. The encrypted share is then written to your S3 bucket. DFNS never has access to your private key, so only you can decrypt and recover the backups.

Each signer writes to its own prefix in the bucket (e.g. signer-0/, signer-1/). The backup happens automatically for every wallet created after Layer 4 is enabled.

What Layer 4 protects against

• Encryption key loss: Without Layer 4, losing signer encryption keys is unrecoverable. With Layer 4, you can decrypt key shares from your own storage.
• Database loss beyond last backup: Standard database backups have a recovery point. Layer 4 backups are written at key generation time, so no gap exists.
• DFNS unavailability: Recovery is entirely independent of DFNS. You only need your private key and the backup files.

Security properties

• Customer-controlled encryption. Shares are encrypted with your Ed25519 public key. DFNS cannot decrypt the backups.
• Write-only signer access. Signers have s3:PutObject permission only. They cannot read, modify, or delete existing backups.
• Independent recovery. You can recover your keys at any time using only your private key and the backup files.
• Complementary to database backups. Layer 4 does not replace standard database backups. It provides an additional recovery path for scenarios where those backups are unavailable.

Setup

Layer 4 setup is covered in the MPC signer deployment. It involves generating an Ed25519 key pair, creating an S3 bucket, and configuring the signers. To enable Layer 4 or for questions about the setup process, contact our .