Every major cloud provider sells a key management service, and most sell a "bring your own key" option layered on top, marketed as the difference between trusting the provider and trusting yourself. The pitch is clean. The mechanics underneath are not, and the part that actually determines who can read your data is rarely the part the sales page shows you.
If you've provisioned storage on AWS, Google Cloud, or Azure in the last few years, you've seen the encryption-at-rest checkbox: "encrypt with a key you manage." It sounds like a meaningful control. In practice it's three different architectures wearing the same marketing label, and they don't provide the same guarantee.
What a KMS Actually Does
A cloud Key Management Service is a hosted service that generates, stores, and performs operations with cryptographic keys on your behalf. When you ask a KMS to encrypt something, in most cases the plaintext key material never leaves the service's boundary. What you get back is a ciphertext blob and, for envelope encryption schemes, a wrapped data key you can use locally. The design goal is real: keys shouldn't sit in application memory or config files where a compromised host can grab them.
The question that matters is not "does a KMS exist in this architecture" but "who can invoke it, and under what legal or operational conditions." That's where customer-managed keys and bring-your-own-key start to diverge in ways the naming doesn't make obvious.
Customer-Managed Keys vs Bring-Your-Own-Key
Customer-managed keys (CMK) means the key was generated inside the provider's KMS, under your account, and you control the access policy: who can use it, when it rotates, whether it can be disabled. The key material itself still lives entirely inside the provider's infrastructure. You never see the raw bytes. You're managing permissions on a key you didn't generate and can't export.
Bring-your-own-key (BYOK) means you generate the key material yourself, outside the provider's environment, typically in an on-premises hardware security module, then import it into the provider's KMS. This closes one specific gap: the provider's KMS never generated your key, so a compromise of the provider's key-generation process (a weak random number generator, for example) doesn't touch your key's origin. It does not mean the key stays outside the provider once imported. After import, it typically lives inside the same KMS infrastructure as a CMK, subject to the same access model, unless you're using the external variant below.
BYOK controls where the key came FROM. It does not, by itself, control where the key currently LIVES or who can invoke operations with it. Those are separate properties, and marketing copy routinely conflates them.
The HSM Boundary Nobody Talks About
Underneath both CMK and standard BYOK sits a hardware security module: tamper-resistant hardware built so that key material can be used for cryptographic operations without ever being extractable in plaintext, even by the operator running the box. The relevant fact here is jurisdictional: the HSM is owned and operated by the cloud provider, sitting in the provider's datacenter, subject to the provider's operational access and the legal process that reaches the provider's infrastructure.
This matters because a legal order compelling a cloud provider to produce data doesn't need to break the HSM's tamper resistance. If the HSM will perform a decrypt operation for anyone holding valid provider-side credentials, and the provider can be compelled to issue or honor those credentials (through a court order, a subpoena, an internal policy override), the hardware protection is irrelevant to that particular threat. The HSM protects against key exfiltration by an outside attacker or a rogue employee acting outside policy. It does not protect against the provider itself acting under lawful compulsion, because the provider retains the ability to invoke the key.
External Key Manager: Holding the Key Outside
Several providers now offer a further step, usually called an external key manager or "hold your own key" (HYOK). Here the key material never enters the provider's KMS at all. It stays in an HSM you operate, and every encrypt or decrypt request the cloud service needs is proxied out, in real time, to your external HSM for approval. Revoke network access to your HSM, or simply take it offline, and the provider immediately loses the ability to decrypt anything, including data it's currently serving.
This is a materially different guarantee. It converts key custody from a permissions setting the provider ultimately still enforces into an availability dependency the provider cannot route around. The trade-off is operational: your external key service becomes a single point of failure for every read and write, and it needs to be reachable with low enough latency that it doesn't become the bottleneck for the workload sitting on top of it.
| Model | Key generated by | Key lives in | Revoking access stops decryption |
|---|---|---|---|
| Provider-managed key | Provider | Provider's KMS | No, provider retains use |
| Customer-managed key (CMK) | Provider (on your request) | Provider's KMS | Depends on provider honoring your policy |
| Bring-your-own-key (BYOK), imported | You, then imported | Provider's KMS after import | Depends on provider honoring your policy |
| External / hold-your-own-key (HYOK) | You | Your infrastructure, proxied per-request | Yes, immediately and unilaterally |
What Changes When You Revoke Access
A useful test for any "you control the keys" claim is to ask a concrete question: if you disable this key right now, does data that's already resting on the provider's servers become unreadable to the provider within minutes, or does the provider need to cooperate for that revocation to take effect? For CMK and standard imported BYOK, the answer usually routes through the provider's own enforcement of your policy, which is a promise, not a physical constraint. For a true external key manager, the answer is closer to a physical constraint: no key service reachable, no plaintext produced, regardless of what the provider's own systems want to do.
Key custody claims are only as strong as the party who can still say no. If that party is the same company holding your data, you've added a policy layer, not a trust boundary.
Where This Fits for Actual Threat Models
None of this makes CMK or BYOK pointless. For compliance regimes that require demonstrable key rotation, access logging, and separation of duties inside a single organization, provider-managed key schemes solve a real, auditable problem. What they don't solve is protection from the provider's own legal exposure, which is a different threat model entirely. If that's the threat you're modeling against, the question to ask a vendor isn't "do you support customer-managed keys." It's "can you produce plaintext data to a court order without my cooperation, and if so, under what conditions."
Originally published at havenmessenger.com
Top comments (0)