Sovereign key management is the discipline of ensuring that the cryptographic keys protecting sensitive data remain under the exclusive legal and physical control of the data owner, stored in tamper-resistant hardware and governed by documented procedures that satisfy regulatory audit requirements. For European government bodies and regulated organisations, this is not an optional hardening measure; it is the difference between encryption that provides genuine legal protection and encryption that merely creates the appearance of security while leaving a foreign authority a clear path to plaintext.
Why Cloud KMS Breaks Data Sovereignty Even When Data Is Encrypted
Storing data in encrypted form inside a US-controlled cloud does not remove it from the reach of US law if the cloud provider also manages the keys. The legal mechanism is straightforward and well-documented.
The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) allows US federal authorities to compel any US-based provider to disclose data and, critically, the means to decrypt it, regardless of where the data physically sits. FISA Section 702 enables the collection of communications of non-US persons from US-based electronic communication service providers without a warrant. The Patriot Act’s successor provisions similarly reach stored data. None of these mechanisms require prior notification to the data subject or to the organisation whose data is disclosed.
“The CLOUD Act allows US authorities to compel US-based providers to disclose data stored anywhere in the world, regardless of the country where the data physically resides.”
European Data Protection Board (EDPB), Information Note on data transfers under the CLOUD Act
The consequence for encrypted data is direct: if Microsoft Azure Key Vault, AWS KMS, or Google Cloud KMS holds or can reconstruct your encryption keys, a US National Security Letter or court order served on that provider reaches your plaintext. The data can sit in a Frankfurt data centre and still be legally exposed.
Hardware Security Modules: Physical Key Custody and Required Certifications
A Hardware Security Module (HSM) is a dedicated cryptographic processor with a tamper-evident and tamper-resistant physical enclosure that generates, stores, and performs operations with cryptographic keys without ever exposing the raw key material outside the module boundary.
The relevant certification standards are FIPS 140-3 (published by NIST in 2019 as the successor to FIPS 140-2) and Common Criteria. FIPS 140-3 defines four security levels; Level 3 adds physical tamper resistance and identity-based authentication, and is the minimum accepted for financial, healthcare, and government use cases in most EU member states. Common Criteria EAL4+ provides a deeper evaluation of the module’s design, implementation, and operational environment, and is required by a number of national security frameworks including Germany’s BSI guidelines.
Leading HSM products evaluated against these standards include the Thales Luna HSM (available in network-attached and PCIe form factors, FIPS 140-3 Level 3 certified) and the Utimaco HSM range (German-manufactured, Common Criteria EAL4+ certified). Both expose keys to applications through the PKCS#11 key management API, which is the industry-standard interface used by most enterprise software, including OpenSSL, Java cryptography libraries, and key management platforms such as HashiCorp Vault.
Designing a Key Ceremony for GDPR, DORA, and NIS-2
A key ceremony is the formal, witnessed procedure for generating, splitting, and activating a cryptographic key. Its purpose is to create an auditable record demonstrating that no single individual had unilateral access to key material, satisfying the technical and organisational controls required by three overlapping regulatory frameworks.
GDPR Article 32 requires “appropriate technical and organisational measures” to ensure a level of security appropriate to the risk, explicitly citing encryption as one such measure. DORA Article 9 mandates that financial entities implement data security policies covering the confidentiality and integrity of data, with cryptographic controls specifically named in the associated regulatory technical standards. NIS-2 Article 21 requires essential and important entities to adopt “policies on the use of cryptography and, where appropriate, encryption.”
A compliant key ceremony for these frameworks should include the following structural elements:
- Role separation: Separate the roles of key custodian (holds a key share), ceremony officer (conducts the procedure), and auditor (witnesses and logs). No single person may hold more than one role.
- Quorum requirement: Use Shamir’s Secret Sharing or multi-party computation to split the key into N shares, requiring M of N (for example, 3 of 5) to reconstruct it. This prevents a single compromised custodian from exposing key material.
- Audit logging: The HSM must generate a cryptographically signed log entry for every key operation. This log must be stored immutably and be available for regulatory inspection without requiring the decryption of operational data.
- Air-gapped ceremony room: Key generation should occur on a system with no active network interface. The Thales Luna HSM and Utimaco HSM both support offline key generation workflows.
“Encryption is only as strong as the key management behind it. If a third party can be legally compelled to hand over your keys, your encryption provides no meaningful protection.”
European Union Agency for Cybersecurity (ENISA), Cloud Security Guidance
Key Escrow: Risks, Legitimate Uses, and Sovereign Structuring
Key escrow means depositing a copy of key material with a trusted third party so that encrypted data can be recovered if operational keys are lost. The legitimate use cases are real: a healthcare provider that loses its database encryption key loses patient records permanently. A law firm that loses its email encryption keys may be unable to produce discoverable documents in litigation.
The risk is equally real: an escrow agent domiciled in a jurisdiction that has a mutual legal assistance treaty (MLAT) with a foreign government becomes a second point of compulsion. Serving a subpoena on a US-based escrow agent reaches the same key material as serving it on the original key holder.
Sovereign escrow structuring requires three controls working together. First, the escrow agent must be domiciled in a jurisdiction that does not have relevant MLAT obligations toward the requesting country. Switzerland is frequently chosen because its revised Federal Act on Data Protection (revFADP) provides strong data subject rights, and Swiss providers are not subject to the CLOUD Act. Second, the escrowed key material must itself be split using Shamir’s Secret Sharing across multiple custodians, so the escrow agent alone cannot reconstruct a usable key. Third, the escrow agreement must contain a mandatory notification clause requiring the agent to inform the data owner before complying with any disclosure order, to the extent local law permits. Swiss law generally allows this notification window unless a secrecy order accompanies the request.
BYOK vs HYOK: Which Model Actually Works
The distinction between Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK) is frequently misrepresented by cloud providers, and the difference has direct compliance implications.
| Model | Who generates the key | Where encryption/decryption occurs | Does the cloud provider have transient plaintext access | Sovereign verdict |
|---|---|---|---|---|
| Cloud-managed KMS | Cloud provider | Cloud provider infrastructure | Yes, always | No sovereignty |
| BYOK | Customer (HSM) | Cloud provider infrastructure | Yes, during processing | Partial: storage protection only |
| HYOK | Customer (HSM) | Customer infrastructure | No | Full: provider never sees plaintext |
With BYOK, the customer imports a key they generated into the cloud provider’s key management service. The provider still uses that key to perform encryption and decryption on its own compute infrastructure. This means the provider’s systems have transient access to plaintext during every read and write operation, and a CLOUD Act order can reach that transient plaintext as well as the key. BYOK is better than cloud-managed keys for at-rest storage scenarios where the regulatory concern is media theft, but it does not remove cloud provider access during processing.
HYOK means the customer’s own HSM, located on their own infrastructure, performs all encryption and decryption. The cloud environment only ever receives and stores ciphertext. Microsoft’s Azure Information Protection offers a HYOK configuration specifically for this scenario. For most regulated European organisations, HYOK combined with an on-premises or Swiss-hosted HSM is the only model that genuinely satisfies the sovereignty requirement.
European and Open-Source Alternatives to US Cloud KMS
The dependency on AWS KMS, Azure Key Vault, and Google Cloud KMS is not technical necessity but procurement habit. Certified European and open-source alternatives cover the same functional requirements.
On the hardware side, Utimaco (headquartered in Aachen, Germany) and Securosys (headquartered in Zurich, Switzerland) produce HSMs certified under FIPS 140-3 and Common Criteria EAL4+. Both expose the PKCS#11 key management API and integrate with standard enterprise platforms. Thales Luna HSM, while a French-American product (Thales Group is French-headquartered), is widely deployed in European regulated sectors and is evaluated under both certification schemes.
On the software side, HashiCorp Vault is the dominant open-source key management platform. It can run entirely on-premises, integrates with HSMs via PKCS#11 for hardware-backed key storage, and supports fine-grained access policies and audit logging compatible with GDPR Article 32 and DORA Article 9 requirements. OpenStack Barbican is the alternative for organisations already running OpenStack infrastructure. Neither sends key material to any external service unless explicitly configured to do so.
The IBM Cost of a Data Breach Report 2023 found that the global average breach cost reached USD 4.45 million, the highest in the study’s 18-year history. Organisations that had deployed encryption with customer-managed keys consistently showed lower breach costs than those relying on provider-managed encryption, because the attacker path to usable data was longer and the regulatory exposure smaller.
FAQ
Does encrypting data in a US cloud provider’s infrastructure protect it from CLOUD Act compulsion?
Not if the provider manages the encryption keys. Under the CLOUD Act, US authorities can compel the provider to hand over both the encrypted data and the keys needed to decrypt it. The data is only truly protected if the keys are held exclusively by the data owner in a jurisdiction outside US legal reach.
What is the practical difference between BYOK and HYOK?
With BYOK, the customer supplies a key but the cloud provider’s infrastructure still performs encryption and decryption, meaning the provider has transient access to plaintext during every operation. HYOK keeps both the key and all cryptographic operations on the customer’s own infrastructure, so the cloud provider never sees plaintext under any circumstances. For sovereignty purposes, only HYOK is sufficient.
Which HSM certifications should a regulated European organisation require?
At minimum, FIPS 140-3 Level 3 for physical tamper resistance. For higher-assurance government or critical infrastructure use, Common Criteria EAL4+ provides a deeper evaluation. Both Thales Luna HSM and Utimaco HSM offer models certified at these levels, and both expose the PKCS#11 key management API for standard integration.
Can key escrow be structured so that a foreign government cannot compel disclosure without the organisation’s knowledge?
Yes, with three controls: use an escrow agent in a jurisdiction without relevant MLAT obligations (Switzerland is a practical choice); split the escrowed key material using Shamir’s Secret Sharing so the agent alone cannot reconstruct a usable key; and include a contractual notification obligation requiring the agent to inform the key owner before complying with any disclosure order, to the extent local law permits.
What open-source or European alternatives to AWS KMS and Azure Key Vault exist?
HashiCorp Vault (open-source, PKCS#11 compatible, fully on-premises deployable) is the most widely adopted software alternative. OpenStack Barbican serves organisations on OpenStack infrastructure. For hardware, Utimaco (German) and Securosys (Swiss) manufacture FIPS 140-3 and Common Criteria EAL4+ certified HSMs that integrate with both platforms, keeping the entire key management stack within European supply chains and legal jurisdiction.