Encryption became the default answer to every cloud security question around 2010. Is the data safe? It is encrypted. What if the provider is compromised? The data is encrypted. What about the other tenants on the platform? Encrypted. The word did a great deal of work in procurement conversations, and it concealed the only question that actually determines control: who holds the keys. If the provider generates the keys, stores the keys and applies them automatically on every read, then the data is encrypted against someone who steals a disk. It is not encrypted against the provider, against a party that compels the provider, or against an attacker who obtains the provider's administrative access — because in all three cases, the system that decrypts data is doing exactly what it was built to do. That is not a criticism of provider-managed encryption. It is a description of what it protects against, and the gap between that description and what buyers believed they were getting was the real issue in 2010.
Three Arrangements, Three Very Different Positions
Provider-managed keys. The provider generates, stores and rotates keys. Data is encrypted at rest and decrypted transparently. This protects against physical media theft and some classes of infrastructure compromise. It does not separate the data from the provider's own ability to read it, and it offers no independent control point. Customer-managed keys in the provider's key service. The customer holds authority over key material hosted in the provider's key management infrastructure, with the ability to control access policy and to revoke. This is a genuine improvement — revocation becomes possible and key usage is auditable — but the keys still reside within the provider's environment. Customer-held keys. Key material is generated and held outside the provider's control entirely, sometimes in the customer's own hardware security modules. This is the only arrangement in which the provider genuinely cannot read the data. It is also operationally demanding, breaks a substantial amount of provider functionality, and makes the customer solely responsible for the consequences of key loss. The practical difficulty is that these three arrangements were routinely described using the same word in vendor material, and the differences between them are the entire substance of the control.
| Arrangement | Control to establish | Operational question |
|---|---|---|
| Provider-managed | Provider key generation and policy | Who can request decryption and how is access reviewed? |
| Customer-managed in provider service | Customer authority over policy and revocation | What depends on the provider key service? |
| Customer-held outside provider | External key generation and custody | How are recovery, availability and plaintext use controlled? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What Key Custody Actually Determines
Four questions resolve differently depending on where the keys sit, and each of them turns up in a regulatory conversation eventually. Can the provider read your data? With provider-managed keys, technically yes. Whether they do is a matter of policy, contract and controls — which is a different kind of assurance from cannot. What happens when a third party compels disclosure? A provider served with a lawful demand and holding the keys can produce readable data. A provider holding only ciphertext can produce only ciphertext, and the demand is redirected to whoever holds the keys — which may be you, in your jurisdiction, with your legal process and your knowledge that it happened. Can you revoke access unilaterally? Customer-controlled keys allow the customer to render data unreadable without the provider's cooperation. This matters at contract termination, during a dispute, and in a compromise scenario. Provider-managed keys offer no equivalent lever. Does encryption survive the provider's own compromise? An attacker with administrative access to a platform that decrypts transparently obtains plaintext. Encryption with externally held keys is one of the few controls that survives this scenario.
The Operational Cost Is Real
Customer-held keys are not free, and organizations that adopted them without planning discovered the costs in sequence. Key loss is catastrophic and irreversible. If you hold the keys and lose them, the data is gone — there is no provider recovery path, because the design point is that no such path exists. This demands escrow, backup and tested recovery procedures more rigorous than most organizations apply to anything else. Provider functionality degrades. Server-side search, indexing, deduplication, backup verification, malware scanning and increasingly AI features all require the provider to process plaintext. Withholding keys withholds those capabilities. Availability becomes your responsibility. If the key service is unreachable, the data is unavailable. You have added a dependency whose uptime you now own. And the operational overhead is continuous: rotation, access policy, audit review, separation of duties for key administrators, and the recovery testing that nobody does until an audit asks.
Choosing Deliberately
- Match custody to the data, not to the platform. Most organizational data is adequately protected by provider-managed encryption. A small proportion — regulated records, material non-public information, sensitive personal data, source code and secrets — justifies stronger custody. Applying the strictest model everywhere guarantees it will be undone somewhere.
- Establish what the vendor means before signing. "Your data is encrypted" is not a specification. Who generates the key, where it is stored, who can access it, whether usage is logged to you, and what the revocation mechanism is.
- Test revocation before you need it. A revocation capability that has never been exercised is an assumption. Validate what actually becomes unavailable, how quickly, and how it is restored.
- Treat key backup as a tier-one control. Escrow, geographic separation, documented recovery, and a restoration test performed on a schedule with real people following the written procedure.
- Enforce separation of duties. The administrator who manages keys should not be the administrator who manages the data. This is the control that makes key custody meaningful against insider risk.
- Log key usage and read the logs. Every decrypt operation, by whom, for what. This turns key management from a configuration setting into a detection capability.
- Understand what you give up. Enumerate the provider features that stop working before deployment, not after users report them as faults.
- Plan the exit. At termination, customer-held keys let you render provider-resident data unreadable immediately. That is worth more in a contract negotiation than most of the clauses people argue about.
Why This Became the Sovereignty Question
The cross-border debates of the 2010s — conflicting lawful access regimes, invalidated transfer frameworks, localisation mandates — kept converging on a single technical fact. If the provider cannot read the data, several of the hardest legal questions become considerably simpler, because the provider's ability to comply with a demand is limited by cryptography rather than by contract. That is why customer-managed and customer-held key models moved from exotic to standard offerings, and why sovereign cloud propositions now lead with key custody. It is the one control that changes the structure of the problem rather than documenting it.
The AI Complication
The current generation of systems creates real tension with this model, and it is not being discussed honestly enough. AI processing requires plaintext. A model cannot embed, retrieve from or reason over data it cannot read. Every AI feature layered onto a storage or productivity platform requires the platform to decrypt, which means that data protected by customer-held keys is, by design, data the AI cannot use. Organizations are resolving this tension in the easiest available direction — relaxing key custody to enable AI features — frequently without recording that they have made a security decision at all. The residency and custody commitments given to a regulator two years ago may not describe the system once an AI layer is processing the same records. The honest position is that this is a trade-off, and it should be made explicitly, per data category, with the same rigour applied to the original custody decision. Some data is worth processing with AI at the cost of weaker custody. Some is not. Deciding that by default, feature by feature, is how organizations end up unable to answer the question they have already answered in writing.
Common Questions
What is the difference between provider-managed and customer-managed encryption keys?
With provider-managed keys, the provider generates and stores the key material and can decrypt transparently. Customer-managed keys give the customer authority over key policy and revocation, though the keys still sit in the provider's infrastructure. Customer-held keys are generated and stored entirely outside the provider's control.
Why does key custody matter more than encryption itself?
Because encryption protects data from anyone who cannot obtain the key. If the provider holds the key, the data is protected against disk theft but not against the provider, a party compelling the provider, or an attacker with provider administrative access.
What are the risks of holding your own encryption keys?
Irreversible data loss if keys are lost, loss of provider functionality that requires plaintext processing, an additional availability dependency on your key service, and continuous operational overhead for rotation, access control and recovery testing.
How does AI affect encryption key strategy?
AI processing requires plaintext, so data protected by customer-held keys cannot be used by AI features. Organizations are frequently relaxing key custody to enable those features without recording it as a security decision or checking it against existing regulatory commitments.
Key Management Assessment — Outpace establishes who can actually read your data today, matches key custody to the data that warrants it, and makes sure enabling AI does not quietly undo the commitments you have already made.