In this blog
When your cloud backups get written to object storage, something has to encrypt them. Where that happens is more important than it sounds.
With server-side encryption, your backups travel to the storage location and encryption happens once they arrive. This is the model Rubrik's Cloud Native Protection (CNP) has supported for years. It works well for many teams.
The tradeoff is where the encryption event actually occurs: even if you're using your own KMS key, the storage provider's infrastructure is still the one performing that encryption. TLS secures the data while it's moving, and the storage layer takes over with its own encryption once the data arrives. That's the standard, secure model behind most cloud storage.
But there's another way.
You can encrypt the data at the source—before it's ever written to storage—with keys you control. That’s client-side encryption. With our latest release, CNP now supports client-side encryption, built on the Rubrik Unified Encryption Management (UEM) platform. The result? The storage layer only ever sees ciphertext and wrapped keys. It never sees your plaintext data and it never sees an unwrapped key.
(Note: Client-Side Encryption is being progressively rolled out and enriched to all RSC instances throughout August and September of 2027)
It All Starts with a Boundary of Trust
Every cloud backup usually ends up as objects in a bucket, whether that's your S3 environment or Rubrik-managed storage. Either way, something has to encrypt those objects at rest. Where that encryption happens defines our trust boundary.
Rubrik has long supported server-side encryption, complete with a few flavors: leveraging default platform-managed keys (PMK) from the hyperscaler or using a customer-managed key (CMK) served up through the cloud provider's Key Management System (KMS). No matter which option you choose (or whether you or the hyperscalar controls the key) the encryption itself doesn’t happen until the data reaches its final destination.
For a lot of organizations, this behaviour is perfectly acceptable. The transfer itself is protected by TLS, so this was never about data crossing the wire in the clear. It comes down to what happens at the destination: the data arrives readable and the storage service is the one that encrypts it and holds the keys.
For teams that want control in their own hands, the better model is to encrypt the data before it ever leaves for the storage, with keys you control. That's exactly what client-side encryption delivers.
What is Client-Side Encryption?
With client-side encryption, your backup data is encrypted at the client, before it's written to the backup location. In Rubrik's case, the client is Exocompute, Rubrik's cloud-native compute layer. It's an ephemeral, container-based data plane that runs inside the cloud, close to your workloads, and spins up on demand to handle the heavy lifting of backup, archival, and recovery before tearing back down. Exocompute is where your data is actually read and processed, making it the natural place to encrypt the data. That way, the data lands in the bucket already encrypted, with keys that roll up to a master key you own.
The result: the data arrives at the storage layer already encrypted. The master key to unlock it all lives outside the storage account, under your complete control—and it never receives an unwrapped key.
All of this hinges on getting key management right: generating the keys, wrapping them, and keeping the master key under your control. That's the part Rubrik UEM handles.
Meet Rubrik UEM
Rubrik UEM is a framework, not a key management service. It doesn't replace AWS, KMS or Azure Key Vault. Instead, it's Rubrik's platform-wide layer for creating and managing encryption keys and their lifecycle consistently across workloads, and it integrates with your cloud provider's native KMS to do the heavy cryptographic lifting.
Why build a framework rather than bolting encryption onto each workload independently? Once you've got a common model for generating, wrapping, and unwrapping keys, every new workload that wants client-side encryption can plug into it instead of reinventing the wheel. CNP is one of the consumers of that framework. The master key you bring lives in your KMS, under your control, and Rubrik UEM is the mechanism that uses it correctly.
How Envelope Encryption Works
Before we get to Rubrik's specific encryption mechanisms, let's cover the concept underneath it: envelope encryption.
The naive approach, sometimes called direct encryption, is to take one key and encrypt everything with it. It works, but it creates real problems at scale. Everything now hangs on that single key, so if it's ever exposed, every backup it protects is exposed along with it.
That same key also has to be available everywhere data gets encrypted or decrypted, so it ends up living and traveling in more places than you'd like, widening the surface for it to leak. And rotating it is painful: because the key is tied directly to the data, replacing it means decrypting and re-encrypting everything it ever touched, which is a non-starter when you're protecting terabytes or petabytes of backups.
Envelope encryption takes a different path. Rather than hinging the entire process on a single key, we are now dealing with three (or more) levels of keys.
First, we encrypt our data with a Data Encryption Key (DEK). Second, the DEK is then encrypted by a Key Encryption Key (KEK) and stored alongside our data (unreadable as it’s encrypted). Finally, our KEKs are in turn encrypted by a master key and stored within the root of the backup storage. It’s the master key that the customer owns and controls, and can, at any given time, be revoked resulting in the backup data being unreadable. In turn, our DEKs are letters, our KEKs are envelopes, and the master key seals the envelope.
Envelope Encryption helps on many levels. First, the DEKs can be stored encrypted alongside their respected encrypted data, allowing the ability to decrypt to follow the data itself across locations. Secondly, rekeying, or rotating keys can easily be done without having to decrypt massive amounts of data. We simply decrypt our keys and re-encrypt with newly generated keys, which in turn get re-encrypted by our master key.
The Four-Level Key Hierarchy
The previous envelope walkthrough had three layers: a data key, a key that wraps it, and a top-level key you control. Keep in mind that we don’t just have one DEK, that would drastically increase our risk if a key was compromised. Instead, we have multiple DEKs, each encrypted a respective KEK, all encrypted by our master key.
Rubrik's implementation follows this same shape, but introduces an additional KEK layer which is tracked per backup location, again, decreasing the risk should a single key be compromised.
Here are the four levels, top down:
Master Key: Your key, held in your cloud KMS. It's the root of trust and the one you control directly. Rubrik doesn't hold standing access to it in unwrapped form. It wraps the level below it.
Root Key-Encryption-Key (Root KEK): One per backup location, encrypted by your master key. It in turn wraps the intermediate keys.
Intermediate KEKs (Level-2): Encrypted by the root key. These wrap the data keys.
Data Encryption Keys (DEKs): Encrypted by an intermediate key. These are what actually encrypt your backup data, and a DEK is generated at a fine granularity as data is archived.
Picture it as a chain of custody: your master key protects the root key, the root key protects the intermediate keys, and the intermediate keys protect the data keys that lock the data itself. Every link is encrypted by the link above it, and the whole chain is anchored to a key only you control.
How Your Data Gets Encrypted (The Backup Flow)
Now let's follow a backup as it gets archived.
When Rubrik Cloud Data Protection archives a workload, the data streams into Exocompute. There, Rubrik UEM provides a fresh data encryption key for the data being written. That DEK is the bottom of the hierarchy we just walked through: it's created under an intermediate key, which is wrapped by the root key for the desired backup location, which is in turn wrapped by your master key in your KMS. The DEK has to be generated and used without ever exposing an unwrapped key to the storage layer, so both the key handling and the actual encryption happen right there in the compute layer. The data is encrypted with the DEK inside Exocompute.
For every DEK, Rubrik writes a small companion alongside the encrypted data that holds the wrapped version of that DEK, plus a reference to the key hierarchy it belongs to. So the encrypted data and the still-encrypted key that unlocks it travel together into the bucket. The DEK sitting next to the data is wrapped by its intermediate key, and useless on its own without climbing back up through the root key to your master key.
The result is that the storage layer only ever sees ciphertext and wrapped keys. It never sees the plaintext data, and it never sees an unwrapped key.
How Recovery Works
Recovery runs the same path in reverse, and it's worth walking through because it shows where the trust stays anchored.
When you recover, Exocompute reads the wrapped DEK from the companion stored alongside the data. To turn it back into a usable key, it has to climb the hierarchy: the wrapped DEK is unwrapped by its intermediate key, the intermediate key by the root key, and the root key by your master key in your KMS. In the end, nothing can be unwrapped without access to the master key.
Once the DEK is back in plaintext, again inside the compute layer, the data is decrypted and your recovery proceeds as normal.
The thing worth underlining is that the ability to decrypt your backups is tied to access to your master key. If that access goes away, so does the ability to read the data. For a lot of security teams, this is the desired behaviour.
Protecting the Keys Themselves
There's a subtle problem hiding in all of this. If the wrapped key material is what makes your data recoverable, then the key material itself becomes something you have to protect carefully. In a corruption or cyber event, if the keys are affected, the ability to read the data could also be compromised.
So the key hierarchy files get the same treatment as the data they protect. They're written with immutability locks. The key material is also kept in storage tiers that support instant retrieval, so it's always available for the operations that need it rather than sitting in a cold tier waiting to be rehydrated.
You Hold the Keys
With client-side encryption, the master key lives in your cloud KMS, under your governance. Rubrik uses it through the framework but doesn't hold standing access to your keys in unwrapped form. It’s this key that holds the power to drive the entire encryption process from end to end.
Practically, that means cryptographic control sits with you. You decide who can use the key, and you can revoke that access. The envelope model gives you control without Rubrik needing to hold plaintext key material anywhere in the pipeline.
Why it Matters
Client-side encryption moves the trust boundary off the storage layer and into your hands, before any data is moved. You hold the keys, so cryptographic control remains entirely within your organization. The master key lives in your cloud KMS under your governance and Rubrik never holds standing access to unwrapped keys when not needed. You decide who can use the key and you control revocation.
This is a meaningful shift in security posture. By ensuring your data is encrypted before it lands ensures the storage service never handles readable data or unwrapped keys, you align your backup architecture with a zero-trust mindset and strict compliance requirements.
Want to Learn More?
Want to learn more about how Rubrik delivers enterprise-grade security with features such client-side encryption, granular RBAC, Quorum Authorization and Retention Lock, and more? Try the following resources:
Take Rubrik for a test drive by taking one of our self-guided, hands-on labs on Rubrik Explore.
See where your organizations lands on the Cloud Maturity Model by taking our free cloud assessment
Learn more about client-side encryption and many other features by visiting the Rubrik Cloud Native Protection solutions page.
Safe Harbor Statement: Any unreleased services or features referenced in this presentation are not currently available and may not be made generally available on time or at all, as may be determined in our sole discretion. Any such referenced services or features do not represent promises to deliver, commitments, or obligations of Rubrik, Inc. and may not be incorporated into any contract. Customers should make their purchase decisions based upon services and features that are currently generally available.