What is the difference between bring your own key and hold your own key?

In the first you generate the key and hand it to the provider, who stores and uses it for you. In the second the key never leaves your domain; the provider receives at most a short-lived authorisation. Only the second model changes the position when an official order arrives.

Is encryption at rest enough?

Against stolen disks yes, against access to a running system no. For the transfer question what matters is whether data is readable while being processed — and whether the provider holds the key for that.

What does key control cost day to day?

Features. Server-side search, previews, machine analysis and many integrations need readable data. The sensible approach is classification: reserve the highest tier for the categories where access would genuinely cause harm.

Who should hold the key if not us?

An independent third party subject to neither the provider nor its legal order — in practice a trustee or a hardware security module in your own data centre. The arrangement belongs in the contract, together with an emergency access procedure.

Back to the wiki

Technology · 2 min read · Updated 16 August 2026

Key control

In shortEncryption only helps if the provider does not hold the key.

At a glance

Core question: Can the provider make the data readable without your involvement?
Three tiers: Keys at the provider; keys generated by you but escrowed at the provider; keys beyond the provider's reach
Effective against: Disclosure orders, unauthorised access by provider staff, compromise of the storage layer
Ineffective against: Provider outage, loss of availability, absence of an export path
What the EDPB says: Encryption is a recognised supplementary measure, but only where the key is beyond access in the recipient country
Price: Lost features — server-side search, previews and full-text indexing all require readable data

Almost every cloud provider advertises encryption. Almost every one of them genuinely encrypts — in transit and at rest, usually to current standards. The claim still says little while a second question is open: who holds the key?

Encryption does not protect against the party permitted to decrypt.

The first two tiers differ in convenience, not in effect. Only the third changes the legal position.

The three tiers

Keys at the provider. The default. The provider generates, stores and uses the key. That protects against stolen media and against attackers who reach the storage layer. It does not protect against an order served on the provider, because the addressee can comply.

Customer keys, escrowed at the provider. Often marketed as bring your own key. You generate the key and hand it over. That improves traceability and lets you revoke access. The moment an order arrives, the position is the same as tier one.

Keys beyond the provider's reach. In your own data centre, in a hardware security module, or with a trustee subject to a different legal order. Only here can the provider not make the data readable — and only here does disclosure become the handover of unusable blocks.

Why this matters legally

The European Data Protection Board lists encryption explicitly as a supplementary measure within the meaning of Schrems II — with a condition that is frequently skipped: the key must be beyond access in the recipient country.

That is exactly where the first two tiers fail. They are operational security, not transfer protection. For the assessment you have to document anyway, that is the difference between an effective and an ineffective measure.

The price nobody likes to state

Key control costs features. Server-side full-text search needs readable data. So do previews, automatic classification, duplicate detection, machine analysis and a large share of integrations.

The sensible answer is therefore rarely "everything on tier three". It is: classify, and reserve the highest tier for the categories where access would genuinely cause harm — personnel files, design data, client documents, negotiation positions.

What belongs in the contract

Who generates the key, where it lives, who may use it and under what conditions. Plus an emergency procedure: what happens if your key custodian fails? Without that, you have traded an access risk for an availability risk — and the second is far more likely to hit you.

The relation to the neighbouring terms is simple: Data residency answers where the data sits. Key control answers who can read it. The second question is the more effective one.

Common questions

What is the difference between bring your own key and hold your own key?: In the first you generate the key and hand it to the provider, who stores and uses it for you. In the second the key never leaves your domain; the provider receives at most a short-lived authorisation. Only the second model changes the position when an official order arrives.
Is encryption at rest enough?: Against stolen disks yes, against access to a running system no. For the transfer question what matters is whether data is readable while being processed — and whether the provider holds the key for that.
What does key control cost day to day?: Features. Server-side search, previews, machine analysis and many integrations need readable data. The sensible approach is classification: reserve the highest tier for the categories where access would genuinely cause harm.
Who should hold the key if not us?: An independent third party subject to neither the provider nor its legal order — in practice a trustee or a hardware security module in your own data centre. The arrangement belongs in the contract, together with an emergency access procedure.