Wallet-as-a-Service (Palisade) backs up encrypted wallet key material to your AWS S3 bucket so you can recover wallets if needed. As an owner or administrator, you are responsible for setting up the AWS infrastructure, connecting it to Palisade, and maintaining the backup lifecycle.
For the full technical setup — including IAM policies, bucket configuration JSON, key generation commands, troubleshooting, and recovery procedures — see the Wallet backup configuration reference.
When you configure a backup and recovery kit:
- Palisade generates recovery data encrypted to your RSA public key.
- Palisade writes the encrypted recovery data to your S3 bucket through an IAM role that Palisade assumes. If you configure AWS KMS, Palisade uses KMS for S3 server-side encryption of the object.
- Only you hold the RSA private key needed to decrypt the recovery data after you retrieve it from S3.
This design ensures that Palisade never has unilateral access to your backup data. Recovery requires the RSA private key that you control. If the S3 object uses SSE-KMS, you also need AWS access to read/decrypt the object from the bucket before running recovery.
The full setup has four steps. The Wallet backup configuration reference provides detailed instructions, policy JSON, and troubleshooting for each step.
| Step | What you do | Where |
|---|---|---|
| 1. Generate a recovery key pair | Create an RSA-4096 key pair. For example, run openssl genrsa -out recovery.key 4096, then export the public key in DER format with openssl rsa -in recovery.key -pubout -outform DER -out recovery.pub.der. Upload the public key (DER) to Palisade; store the private key offline. | Your workstation or HSM |
| 2. Create an S3 bucket | Create a bucket with versioning, KMS encryption, and a bucket policy that enforces TLS and encryption. | Your AWS account |
| 3. Create an IAM role | Create a role that Palisade's MPC service can assume, with permissions to write to your bucket and use your KMS key. | Your AWS account |
| 4. Configure in Palisade | Create a backup kit. Enter a name, upload public keys, then select Use own AWS configuration and enter your bucket name, role ARN, region, external ID, and KMS key ARN. The default option (Palisade AWS configuration) stores backups in a Palisade-managed bucket. | Settings > Backup & Recovery > Create kit |
After you create the backup kit, assign it to an MPC quorum during quorum creation. Palisade backs up only quorums created with an assigned backup kit; you can't add, remove, or change the backup kit later through quorum restructuring. See Manage MPC quorums.
Decide who holds the recovery private key and where to store it. Common approaches:
| Approach | Pros | Cons |
|---|---|---|
| Hardware security module (HSM) | Tamper-resistant, auditable access | Higher cost, setup complexity |
| Encrypted offline storage (USB, air-gapped machine) | Low cost, simple | Relies on physical security |
| Split across multiple custodians | No single point of failure | Coordination required for recovery |
If you lose the recovery private key, you can't decrypt backups. Never store it on the same systems or accounts that hold the backups.
Use separate AWS infrastructure for sandbox and production backups:
- Different S3 buckets
- Different IAM roles
- Different KMS keys
- Different recovery key pairs (recommended)
This prevents a sandbox misconfiguration from affecting production backups.
After completing the basic setup, apply these additional measures:
- CloudTrail logging — enable data event logging on the S3 bucket to track all access to backup files.
- S3 Object Lock — enable compliance-mode retention to make backups immutable and prevent accidental or malicious deletion.
- Minimal IAM permissions — avoid granting
s3:DeleteObjectors3:*to the Palisade role. - MFA Delete — consider enabling on production buckets for an additional layer of protection.
- CloudWatch alarms — monitor for failed write attempts or unusual access patterns.
See the advanced security configuration section of the reference for CloudTrail and Object Lock configuration JSON.
After configuring the kit and assigning it to a quorum:
- Create a wallet using the quorum.
- Check your S3 bucket for backup files in the expected folder structure (
<key_id>/recovery_shard-*.txt). - Confirm CloudTrail logged the write operation.
Backups aren't one-time configurations. Maintain them throughout the life of your organization:
| Event | Required action |
|---|---|
| Key reshare | Create a new backup immediately. Resharing invalidates existing backups because the key shards change. |
| Quorum restructure | Create a new backup after the restructure completes. |
| Personnel change | If the person who held the recovery key leaves, create a new backup kit with the new recovery public key for future quorums. You can't update existing quorums to use a different backup kit, so plan migration or replacement with Palisade support if you must retire that key. |
| Annual review | Verify you can still access the recovery private key. Run a test recovery in sandbox. Confirm your offline record of quorum IDs, key IDs, and key algorithms is up to date — without these, recovery is impossible if the Palisade platform is unavailable. |
- Test recovery in sandbox — verify you can decrypt and use a backup before you need it in production. Use the Palisade Wallet Recovery CLI to test the process end-to-end.
- Monitor backup creation — use CloudTrail logs to confirm Palisade writes backups to S3 as expected.
- Set retention policies — configure S3 lifecycle rules to manage backup retention, but always keep the most recent backup.
- Document your backup architecture — record which S3 buckets, IAM roles, and KMS keys each environment uses, and who has access to the recovery private key.
- Wallet backup configuration — Full technical reference with AWS policy JSON, key generation, troubleshooting, and recovery procedures
- Manage MPC quorums — Assign backup kits to quorums