Encryption policies usually say keys must be rotated on a schedule, and storage teams usually discover what that means only when the first rotation is due. In object storage the answer depends on which key is being rotated. Changing the key that protects other keys is a small metadata job. Changing the key that actually encrypted the data means reading and rewriting every affected object, which at petabyte scale is a project measured in weeks.
The difference comes from how almost every object store handles encryption at rest. Objects are not encrypted directly with a master key. Each object, or each part of one, gets its own data key, and that data key is stored alongside the object in wrapped form, encrypted by a higher-level key. The arrangement is called envelope encryption, and it is what makes rotation practical at all.
In an envelope scheme there are at least two layers:
Rotating a KEK means generating a new version of it and, over time, re-wrapping the stored DEKs with the new version. The object data does not change. Each re-wrap is a small cryptographic operation on a few dozen bytes, so even billions of objects can be processed without touching the bulk of the stored capacity.
Rotating a DEK is different. The content was encrypted with that key, so a new DEK means decrypting and re-encrypting the object itself. In practice that is a full rewrite: read every byte, write every byte, and update the metadata that points to the new copy. Most policies that say "rotate encryption keys annually" are satisfied by KEK rotation, and teams that read the requirement as DEK rotation sign up for far more work than the control intends.
The table below summarizes the practical difference between the common rotation events in an object store.
| Rotation event | What changes | Data rewritten? | Typical scale of work |
|---|---|---|---|
| New KEK version, old version kept for decryption | New writes wrap DEKs with the new version | No | Configuration change |
| Re-wrap of existing DEKs under the new KEK | Wrapped key metadata on each object | No | Metadata pass over all objects |
| Retirement of the old KEK version | Old version disabled or destroyed in the KMS | No, but only safe after re-wrap completes | Verification, then one KMS action |
| DEK rotation for existing objects | Object content re-encrypted under new DEKs | Yes | Full read and write of affected capacity |
| Algorithm or key length change | Cipher used for content | Yes | Full read and write, plus client compatibility testing |
The third row is where most incidents happen. A KEK version that is destroyed while some objects still have DEKs wrapped under it makes those objects unreadable. Nothing about the storage hardware has failed, and the data is intact on disk, but it can no longer be decrypted. Retiring a key version should be gated on a count of objects still referencing it, and that count should be zero.
Several properties of object storage complicate what would otherwise be a routine job.
Versioning. When bucket versioning is enabled, every noncurrent version is a separate object with its own wrapped DEK. A re-wrap pass that only walks current versions leaves older versions tied to the old KEK. The object count for a rotation should include every version, and capacity planning for versioned buckets already has to account for how many of those exist.
Immutability. Objects under a retention lock cannot be overwritten or deleted until the lock expires. A KEK re-wrap usually still works, because it changes key metadata rather than object content, but a DEK rotation that requires rewriting the object is blocked by design. For locked data, the realistic rotation scope is the KEK layer, and the policy should say so explicitly rather than leave an auditor to find the gap.
Customer-provided keys. With S3 server-side encryption using customer-provided keys (SSE-C), the storage system never holds the key. Rotation is then entirely the application's job: it must read each object with the old key and write it back with the new one. The storage team can report which objects use SSE-C but cannot rotate them.
Multipart and large objects. Large objects written in parts may carry a key per part or per object depending on the implementation. A rewrite of a multi-terabyte object is a long-running operation that has to survive node failures and client retries, and partial rewrites must not leave an object half under one key and half under another.
A rotation that touches billions of objects is a background workload, and it competes with client traffic the same way a rebalance or a rebuild does. A few planning steps keep it predictable:
The same verification discipline used to check migrated data applies here: a job reporting success is not proof that every object is readable.
Rotation also changes what a recovery depends on. Backups of the object store, or replicas at another site, are only useful if the keys needed to decrypt them are available at recovery time. If a replica site holds data wrapped under a KEK version that has since been destroyed at the primary KMS, the replica is unreadable. Key backups, KMS replication and the retention of old key versions need to be planned together with data retention, a point covered in more detail in the discussion of what happens when backup encryption keys are lost.
Custody matters as well. The organization that controls the KMS controls whether data can be read, regardless of where the storage sits. That is why key ownership features prominently in data sovereignty discussions, and why a rotation runbook should name who is authorized to create, disable and destroy key versions.
Scality RING is software-defined object and file storage that runs on standard servers in infrastructure the customer operates. When an external key manager is used alongside it, both the storage and the key service can sit inside the same administrative boundary, so the people able to rotate, disable or destroy a key version are defined by the customer's own access model rather than by a service provider.
RING is multi-tenant, with accounts, buckets and policy-based isolation, which allows key scope to follow tenant scope instead of one key covering every workload. That keeps a rotation for one tenant or application from becoming a platform-wide event. Background tasks such as rotation passes run on the same cluster that serves clients, and RING exposes operational metrics and logs the operator keeps locally, so the load a rotation adds can be observed and paced.
Before the next scheduled rotation, it is worth confirming a short list of facts:
With those answers recorded, key rotation becomes a scheduled background job with a clear end state rather than an open-ended risk to data that is otherwise perfectly intact.