Encryption appears in nearly every sovereignty discussion as the control that settles the question. Data is encrypted at rest and in transit, so the argument goes, and a foreign operator or a compelled disclosure order therefore reaches nothing but ciphertext. That conclusion holds only if the party being asked cannot produce the key. In most deployments somebody can, and the architecture rarely records who, under what process, or how quickly that access could be withdrawn.
Encryption relocates the question rather than answering it. Ciphertext is only as sovereign as the key that opens it, and a key has its own custody chain, location, administrators and legal exposure. A deployment can hold every byte inside a national border and still depend on a key service operated elsewhere, by a company subject to another government's production orders.
The useful question is not whether data is encrypted. It is which named entity can cause plaintext to exist, through what process, and whether the system can produce evidence that no other entity did so. Who controls the data is decided at the key boundary at least as much as at the storage boundary, and the two boundaries are frequently drawn in different places.
What encryption moves and what it leaves alone
Encryption converts a data access problem into a key access problem. That is a genuine reduction in exposure, since key material is small and centrally held, unlike petabytes spread across disks and sites. It is not a removal of exposure. Any party that can obtain a key, or can compel the party holding it, retains effective access to the plaintext.
Two mechanisms are commonly conflated. Encryption at rest protects media rather than running systems. It defends against drive theft and improper decommissioning, and nothing against an authenticated request on the normal data path. Encryption in transit protects the wire. Neither addresses the scenario that sovereignty regimes actually contemplate, which is an instruction issued to an organization that already holds the means of decryption.
Three custody models and the line between them
Provider-managed keys are generated, stored and rotated by the storage or cloud operator. The customer may see key identifiers and rotation events, but the operator holds the material and can decrypt without customer participation. The model is operationally simple and offers no sovereignty benefit against the operator itself.
Customer-managed keys are usually a variation on the same arrangement. The key exists inside the provider's key management service under a customer-owned identifier, with customer-controlled policy governing its use. What matters is where the material physically resides and who administers the service holding it. If the key service is run by the same entity as the storage, or by an affiliate under the same jurisdiction, a single order can reach both halves.
Customer-held keys, the arrangement usually labelled hold your own key or reached over KMIP to an external key manager or hardware security module, keep the material in infrastructure the customer operates. The storage system requests an unwrap and receives a usable key for the duration of the work. What matters is not that the provider never sees a key, but that it cannot obtain one without a request the customer's own system records and can refuse.
| Custody claim | What it usually means in practice | What to verify |
|---|---|---|
| Encrypted at rest | Media-level encryption with keys held by the operator | Whether any customer action is required for a running read to succeed |
| Customer-managed keys | A customer-owned key identifier inside the provider's own key service | Physical location of the material and the legal entity operating that service |
| Hold your own key | External key manager reached over KMIP or a vendor API | Cache lifetime after unwrap, and behavior when the key manager is unreachable |
| Revocation supported | Future unwrap requests fail | Effect on sessions, mounts and keys already resident in node memory |
| Per-tenant keys | A separate key per account or bucket | Whether system metadata and indexes share a single system key |
Where keys live while the system is running
Encryption in a storage system is almost always two tiered. A data encryption key protects the object, and a key encryption key protects the data encryption key. Only the key encryption key is held externally in a hold-your-own-key design. Data encryption keys are unwrapped on demand and kept somewhere the data path can reach quickly, which in practice means process memory on the storage nodes.
That cache is the part of the design most often left unspecified, and it determines what revocation means. If unwrapped keys persist for the life of a session, a mount or a node process, a key revoked at the external manager protects nothing until those caches expire or the processes restart. A documented cache lifetime, and a documented way to force a flush, matter more than the choice of cipher.
Failure behavior is the companion question. When the external key manager is unreachable, a system either fails closed and refuses reads until the service returns, or continues serving from cache. Both are defensible, but the choice should be deliberate rather than discovered during a network partition. The same care applies to key material protecting backup copies, which frequently follows a different custody path from the primary system.
What revocation actually accomplishes
Revocation is often described as a kill switch: withdraw the key and the data becomes inert wherever it sits. The mechanism is narrower. Revoking a key causes future unwrap requests to fail. It does not reach data already decrypted and delivered, keys already cached in memory, plaintext written into logs or temporary files, or copies taken by a downstream system that stored them under its own encryption.
A truthful description is that revocation stops new access on a timescale set by cache lifetime, and does nothing about material that has already left. That is still worth having, since it bounds an incident, but it is not the guarantee procurement language tends to imply. Time to effect is the figure worth establishing, and only a test against a running system produces it.
Running that test also exposes dependencies nobody wrote down, such as an administrative console or a support process that keeps working because it holds a separate credential path. A sovereignty audit that never performs a revocation is asserting a control rather than demonstrating one.
Where Scality RING fits
RING is software-defined object and file storage that runs on standard x86 servers in the operator's own facility. Because the hardware, the network boundary and the key management arrangement all sit inside infrastructure the customer runs, the set of parties able to reach plaintext is determined by the customer's own administrative model rather than inherited from a service operator. That does not make key custody automatically correct, but it removes the structural problem of a storage operator and a key operator sharing a jurisdiction.
RING is multi-tenant, with accounts, users, buckets and policy-based isolation, so key scope can be aligned with tenant scope rather than applied as one system-wide secret. Geographic placement of data across sites is configured by the operator, which means the storage boundary and the key boundary can be drawn to match instead of being reconciled after the fact, a point worth settling early in any sovereign cloud architecture.
What to write down and test on a schedule
Record, per data set, the entity that holds the key encryption key, the entity that operates the service storing it, the jurisdiction of each, and the named process by which either could be compelled to act. A sovereignty claim that cannot be stated in those four fields is not yet an architecture. Record alongside it the unwrap cache lifetime, the flush mechanism and the fail-closed or fail-open behavior of the data path.
Test revocation at least annually on a non-production data set that mirrors the production key topology, and measure the interval between the revocation event and the first failed read. Repeat after any upgrade that touches the data path, since cache behavior is an implementation detail that changes without announcement. Keep the measured interval in the same document as the claim, so the control is evidenced rather than asserted.