Encryption Overview
Overview of Cloudback encryption modes - built-in and customer-managed - and how to choose the right one for your organization.
Every Cloudback backup is a password-protected ZIP archive. The password is generated automatically for each backup and is never reused. What differs between encryption modes is who controls that password and how it is stored.
Cloudback offers a built-in encryption mode and a growing family of customer-managed encryption key (CMEK) providers:
Built-in (Cloudback-managed)
Cloudback
Transparent - just click Restore or Download
Available
RSA Lockbox
You (RSA key pair); ciphertext in Cloudback database
Paste your RSA private key each time
Available
Customer-Held RSA Lockbox
You (RSA key pair); ciphertext as .lockbox sidecar in your backup storage
Paste your RSA private key each time
Available
External KMS
Your KMS (AWS KMS, Azure Key Vault, GCP KMS, etc.)
Transparent - Cloudback calls your KMS at restore time
Planned
External Password API
Your custom API
Transparent - Cloudback calls your API to retrieve the password
Planned
Built-in encryption (default)
Every account starts with built-in encryption enabled. In this mode:
Cloudback generates a unique random password for each backup.
The password is stored in the Cloudback database, encrypted at rest.
When you restore or download a backup, Cloudback retrieves the password automatically. No action is required on your part.
This mode is suitable for most users. It provides strong encryption with zero friction.
CMEK providers
RSA Lockbox
RSA Lockbox puts you in full control of backup encryption. You provide your own RSA public key, and Cloudback uses it to encrypt each backup's password. The encrypted password (ciphertext) is stored in the database, but only you can decrypt it with your private key.
Key properties:
Cloudback never stores or persists your private key.
If Cloudback's database were compromised, the attacker could not decrypt your backups without your private key.
You are responsible for safeguarding your private key. If you lose it, the backups protected by that key cannot be recovered.
For a detailed walkthrough, see RSA Lockbox: Setup and Usage.
Customer-Held RSA Lockbox
Customer-Held RSA Lockbox is a variant of RSA Lockbox where the encrypted password is stored as a .lockbox file beside the backup archive in your own backup storage, instead of in the Cloudback database. You supply an RSA public key, and Cloudback encrypts each backup's password with it.
Only you can decrypt the archive password using your private key. Cloudback never stores your private key.
This gives you control over both the private key and the encrypted password location. If Cloudback were compromised, your archives stay protected without your private key and the matching .lockbox sidecar file.
For a detailed walkthrough, see Customer-Held RSA Lockbox: Setup and Usage.
External KMS (planned)
External KMS lets you delegate password encryption to your own key management service (e.g., AWS KMS, Azure Key Vault, or GCP Cloud KMS). On each backup, Cloudback sends the generated password to your KMS for encryption and stores only the ciphertext. At restore time, Cloudback calls your KMS to decrypt - no manual key input is required.
This mode combines full customer control with a frictionless restore experience, and is ideal for organizations that already centralize key management.
External Password API (planned)
External Password API lets you bring your own password service. You configure a custom API endpoint, and Cloudback calls it to retrieve the password for a given backup. This gives you complete flexibility over how passwords are generated, stored, and rotated on your side.
This mode is suited for teams with specialized security infrastructure or compliance requirements that go beyond standard KMS workflows.
How encryption mode applies
Encryption is configured per account, not per repository. You set the encryption mode in Account Settings under Backup Encryption. Once changed, all future backups for that account use the selected provider. Existing backups are not affected - they retain whatever encryption was active when they were created.
You can create multiple CMEK providers (e.g., separate RSA Lockbox encryption providers for different teams) and share them across accounts using access controls.
Choosing the right mode
Setup effort
None
Generate RSA key pair, upload public key
Configure KMS access
Deploy and configure your API
Restore workflow
One-click
Paste private key each time
One-click (Cloudback calls KMS)
One-click (Cloudback calls your API)
Key management
Cloudback handles everything
You manage your RSA private key
Managed by your KMS
Managed by your API
Compliance (CMEK)
May not satisfy
Yes
Yes
Yes
Risk if key is lost
None
Backups unrecoverable
Depends on your KMS policies
Depends on your API
Frequently asked questions
Can I switch between modes? Yes. Changing the encryption mode in Account Settings affects only future backups. Existing backups remain accessible using whatever encryption was active when they were created.
What happens to existing backups when I switch providers? Nothing. They stay encrypted with the previous provider and can still be restored normally. Only new backups use the newly selected provider.
Can I use different encryption for different repositories? No. Encryption is set at the account level. All repositories under an account share the same encryption provider.
What RSA key sizes are supported? RSA keys must be at least 2048 bits. Cloudback uses RSA-OAEP with SHA-256 for encryption.
When will External KMS and External Password API be available? Both are on the roadmap. Check our changelog or contact support for the latest timeline.
Learn More
RSA Lockbox: Setup and Usage - step-by-step setup, usage, and key rotation
Password-Protected Archives - AES-256 ZIP encryption details
Account Settings - configuring the default encryption provider per account
Audit Log - tracking encryption provider operations
Last updated
Was this helpful?