BYOK and HYOK: who really controls your cloud encryption keys

Cloud storage, databases, and managed services encrypt data at rest out of the box, using envelope encryption: data keys wrapped under a master key in the provider's KMS. That stops a stolen disk from leaking data, but it says nothing about who can decrypt. With provider-managed keys, the provider creates, rotates, and uses the master key under its own policies, and you can't audit or revoke its use independently.

The options that follow move control of that master key, step by step, from the provider toward you. Each step buys something real and costs something real, and the marketing names (customer-managed keys, BYOK, HYOK, external key management, cloud HSM) blur together. The useful question for each one is: when the provider's service decrypts my data, whose key does it need, and who can say no?

Bring Your Own Key means the key material is born in your own HSM, under your entropy source, your FIPS 140-3 validation, and your key ceremony, and is then imported into the cloud KMS. The import is the key-transport pattern from the key wrapping use case: the KMS issues a wrapping public key (and usually a short-lived import token), you wrap the key material under it, and the KMS unwraps it inside its own HSMs, where it becomes a key version like any other.

Two wrapping methods are typical. RSA-OAEP with SHA-256 can wrap a symmetric key directly, since a 32-byte AES key fits easily within OAEP's payload limit. For anything larger, such as an RSA or EC private key, the standard choice is a hybrid: generate a one-time AES key, wrap the target key with AES Key Wrap with Padding (RFC 5649), and wrap the one-time AES key with RSA-OAEP. PKCS#11 names this combination CKM_RSA_AES_KEY_WRAP, and most HSMs can produce it without the target key ever appearing in clear outside a hardware boundary.

BYOK gives you provenance (you know how and where the key was generated), an independent copy for durability or for leaving the provider, and a strong delete: you can remove the imported material from the cloud and, if you also destroy your copy, render every data key wrapped under it permanently unreadable (crypto-shredding). Some regulators and internal policies want exactly that evidence trail.

What it doesn't buy is exclusivity. Once imported, the key sits in the provider's HSMs and is used by the provider's services whenever your key policy allows, just like a key the KMS generated. If your threat model includes the provider itself, an insider there, or a legal order served on the provider, BYOK by itself doesn't change the answer. It also adds operational load: you must protect the copy you kept, and imported keys often can't use the KMS's automatic rotation, so rotating means generating and importing new material yourself.

Hold Your Own Key, offered by the major providers as an 'external key store' or 'external key manager' option, keeps the master key in a key manager or HSM you operate, on your premises or with a third party. The cloud KMS holds only a reference to it. Whenever a service needs to unwrap a data key, the KMS calls out over an authenticated channel to your key manager, which performs the operation and can apply its own policy, its own logging, or simply refuse. Cut the link or revoke access, and the provider can no longer decrypt data protected under that key: a kill switch under your control.

This is the strongest answer to 'can the provider decrypt without me?', and it's why HYOK features heavily in data-sovereignty discussions. After the Court of Justice of the EU's Schrems II ruling (July 2020) invalidated the EU-US Privacy Shield, the European Data Protection Board listed strong encryption, with keys held solely under the data exporter's control, among the supplementary measures that can protect transferred data, though its example covers data the provider never needs to process in the clear. That caveat matters, as the next section shows.

Availability becomes yours. If your key manager is down, unreachable, or slow, every cloud service depending on that key stops being able to read its data, which can mean production outages far from where the fault is. HYOK designs therefore run clustered key managers in more than one site, and services cache unwrapped data keys for a while, which in turn shortens how quickly pulling the plug actually takes effect.

And HYOK protects keys, not data in use. To process your data, the cloud service still needs the plaintext data key and the plaintext data in its memory, so a compromised or compelled service can read what it is processing while access is granted. HYOK gives you a veto over future decryption and a log of every use; it doesn't make the provider blind. Only client-side encryption, where data is encrypted before it reaches the cloud and keys never go there, does that, at the price of the provider being unable to search, index, or otherwise compute on it.

Start from the threat, not the acronym. Against lost disks and casual misconfiguration, provider-managed keys are enough. If you need your own audit trail, separation of duties, and the ability to disable a key, customer-managed keys in the provider's KMS cover it with no extra infrastructure. BYOK adds provenance and an off-cloud copy when policy requires knowing where key material came from. HYOK or a dedicated HSM is for when the provider, or legal process against the provider, is in the threat model, and it is worth its availability and latency cost only for the data that actually justifies it.

Whatever the option, check two things in the provider's documentation rather than the product name: the FIPS 140-3 validation and security level of the HSMs that actually hold the key (and whether that is your key or a fleet-wide wrapping key), and exactly which operations the provider's own services can perform with the key without a call that you can refuse.