Encryption at rest, encryption in transit, customer-managed keys, HSMs, BYOK — the terminology multiplies, but a single question cuts through all of it: who can use the keys without your participation?
Part 3 of 10 in Trust through mathematics
Every conversation about data security eventually arrives, or should arrive, at the same place. Not “is the data encrypted?” – almost everything is encrypted now, in some sense, somewhere. The question that actually determines your position is: who can use the keys without your participation?
It is striking how much architectural and marketing complexity exists to avoid answering that question plainly. This post is an attempt to answer it plainly.
Encryption Without Custody Is Bookkeeping
Cloud providers encrypt customer data at rest as a matter of routine, and it is a real protection against stolen drives and certain classes of infrastructure mishap. But when the provider generates, stores, and operates the keys, the encryption does not protect the data from the provider, nor from anyone who can compel, compromise, or impersonate the provider. The data is exactly as accessible as the provider’s access-control decisions allow – which is to say it is protected by policy, not by mathematics.
This is not a criticism of cloud providers, whose key management is generally excellent engineering. It is a statement about what that engineering does and does not change. Provider-held keys convert “can anyone read our data?” from a cryptographic question into a governance question about somebody else’s organisation. For a great deal of data, that trade is perfectly sensible. For some data it is not, and the failure mode is not noticing which kind you are holding.
The Custody Spectrum
Key arrangements are best read as a spectrum of operator exclusion, and the industry’s terminology maps onto it less neatly than the acronyms suggest.
Provider-managed keys sit at one end: the provider generates and uses keys invisibly. Zero operational burden, and zero exclusion of the operator. This is the default almost everywhere.
Customer-managed keys (CMK) let you control the key lifecycle – creation, rotation, revocation – within the provider’s key-management service. That adds real governance value: you can revoke access and produce audit trails. But the keys still live and operate inside the provider’s infrastructure, and the provider, suitably motivated or compelled, can still use them. Exclusion: limited.
Bring Your Own Key (BYOK) sounds stronger than it usually is. You generate the key, then import it into the provider’s KMS – at which point a copy exists in their infrastructure and the situation largely collapses back to the previous case. The phrase does a great deal of reassuring; the architecture does rather less.
Hold Your Own Key (HYOK) and external key stores keep keys in infrastructure you operate, with the provider calling out to your key service for each operation. Now the provider’s access depends on your systems being willing to answer: you can sever access unilaterally and observe every use. The cost is that your key service becomes operationally critical, and its availability is now your problem. This is where real exclusion begins.
Client-side encryption sits at the far end: data is encrypted before it leaves your environment, and the provider stores ciphertext it never had the means to read. Maximum exclusion, maximum responsibility. Lose the keys and the data is gone – there is no support ticket for mathematics. The same principle holds at individual scale, and it is why our Signet authenticator keeps OTP secrets exclusively on-device, with backups encrypted under keys only the user holds. The absence of a recovery path is not an oversight. It is the product.
The Questions Custody Actually Decides
Why does this one design choice carry so much weight? Because it silently answers several questions organisations believe are separate.
Take jurisdiction. Legal demands for data are served on whoever can satisfy them. If your provider can decrypt your data, its confidentiality is bounded by every legal regime that can reach your provider – today, and after their next acquisition. If they cannot decrypt it, a demand on the provider yields ciphertext, and the conversation necessarily returns to you, in your jurisdiction, under your legal advice. Data-sovereignty discussions that do not begin with key custody are mostly discussions about flag emojis on data-centre maps.
Or a breach. When a provider that holds keys is breached, your exposure is set by the attacker’s reach within their systems – something you cannot assess, bound, or remediate. When you hold the keys, a provider-side breach of stored ciphertext is an unpleasant headline rather than a notifiable catastrophe.
Or the insider. Provider-held keys mean provider staff, under whatever controls the provider operates, sit inside your trust boundary. Vetting and access controls reduce that risk; custody removes it.
Or exit. The ability to revoke keys is the ability to leave – genuinely, verifiably, without depending on a deletion certificate from a supplier you are in the middle of leaving.
Choosing Honestly
None of this means everything should be client-side encrypted. Key custody is a responsibility, and responsibility has costs: recovery design, availability engineering, the unglamorous discipline of key ceremonies and escrow arrangements inside your own organisation. Most data does not warrant it. The mature position is segmentation: identify the small fraction of data whose exposure would be intolerable – board communications, deal information, security architecture, regulated personal data at scale – and move that towards the custody end of the spectrum, accepting provider-managed convenience for the rest.
What is not defensible is the common middle position: paying for the vocabulary of control – BYOK, sovereign cloud, customer-managed – whilst the architecture quietly leaves the operator holding usable keys. That arrangement has a name. It is trust by contract, wearing trust by mathematics as a costume.
The test is simple to state. Imagine your provider compelled, compromised, or simply changed. What do they hold of yours – plaintext, or ciphertext? Whatever the documentation says, the keys decide.