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 Dfns at https://support.dfns.co. 