Who Can Actually Compel Your Data?

Part of the pillar series Sovereignty You Can Actually Operate.

In the companion post we argued that a passed audit can hide a live dependency. Here is the sharpest example of that gap. Two systems can both be "encrypted at rest" and have completely different sovereignty: in one, a lawful order to the provider produces your data in plaintext; in the other, the same order produces ciphertext that no one present can read. The difference is not the encryption. It is key custody.

This post is about where the keys live, who can be compelled to use them, and how to build so that the honest answer to a foreign legal order is "there is nothing readable to hand over."

Encryption is necessary. It is not the whole answer.

Encryption defends data against the wrong people getting the bytes. It does nothing, on its own, against the right people being lawfully ordered to decrypt. If your provider holds the decryption keys, even inside an "EU region", then a compulsion order served on that provider's parent company can reach your data, because the provider has the practical ability to produce it.

So the useful question is not "is it encrypted?" but "who can be made to turn it into plaintext?", exactly the fork shown above.

This is why "bring your own key" schemes that still store the key inside the provider's own key manager don't fully close the gap: the provider can still be compelled to use it. What closes the gap is keys held outside the provider's reach: by you, or by an EU-governed entity that is not subject to the foreign order.

The layers that actually matter

Real data protection is not one control but a stack of them, each answering a different threat. Here is the model, described by what each layer does rather than by any product.

Layer	What it protects against	What "good" looks like
In transit	Interception on the wire	Strong transport encryption everywhere, internal and external
At rest (field-level)	Bulk theft of stored data	Authenticated encryption on sensitive fields; ciphertext can't be a key or a filter
Key derivation	One leaked key unlocking everything	Keys derived per purpose, so a key for one job can't decrypt another
Key rotation	A compromised key staying valid forever	Versioned ciphertext, so keys roll without a mass re-encryption outage
Key custody	Lawful compulsion of the provider	Keys held by you or an independent EU entity, outside provider reach
In use	Exposure during processing	Hardware-isolated execution with attestation, with eyes open (see below)

The first two are table stakes. The differentiators are lower down: purpose-derived keys mean a breach of one subsystem doesn't hand an attacker the whole estate; versioned ciphertext means you can rotate keys routinely instead of treating rotation as a risky event; and custody is the one that decides the compulsion question.

What about "encryption in use"?

The newest frontier is processing data while it stays encrypted, inside hardware-isolated environments that even the operator supposedly can't read, with cryptographic attestation that the isolation held. It is genuinely useful and worth adopting. But treat the marketing with care. In late 2025, researchers demonstrated attacks that defeated several mainstream hardware-isolation technologies with a low-cost physical interposer and even forged attestation (BleepingComputer, 2025). For the sovereignty threat model specifically, where the adversary you're worried about is the party with physical access to the hardware, confidential computing narrows the window but does not, by itself, replace customer-held keys. The honest stack uses both.

Evidence you can't quietly edit

There is a second custody question that gets less attention: who can rewrite the record of what happened? An audit trail that the operator can silently alter is not evidence; it is a story.

The architectural answer is a tamper-evident, hash-chained audit log: each entry cryptographically chained to the last, protected by an integrity key, and verifiable after the fact. The design choice that makes it real is counterintuitive: the log should fail closed. If its integrity key is missing, the system should refuse the operation rather than write a record it cannot later prove. Better to reject an action than to log something unverifiable.

How the Soveryne Cloud Foundation handles keys and evidence

We built the Soveryne Cloud Foundation around the principle this whole post argues for: sovereignty is decided at the key boundary, so the boundary is where we put the engineering.

Data is encrypted end to end, in transit and at rest, with keys held inside EU jurisdiction, not in a foreign provider's key manager, so an order served on a foreign provider yields ciphertext only. Sensitive fields are individually encrypted with keys derived per purpose, so a single compromise can't cascade, and ciphertext is versioned for seamless key rotation rather than treated as a once-a-decade emergency. Every privileged action is written to a tamper-evident, hash-chained audit log that fails closed without its integrity key. So your record of who did what is something you can prove, not just assert. And because AI and LLM inference run on EU-sovereign infrastructure, the data you send to a model never crosses the key boundary you just established.

For the strictest postures, the Soveryne tier adds a dedicated environment with its own inference GPUs and on-premises options, plus knowledge transfer to your team, so the keys, and the control of them, stay with you.

FAQ

Does the CLOUD Act apply if my data is encrypted? It depends on who holds the keys. If the provider can be compelled to decrypt, encryption doesn't defeat the order. If the keys are held by you or an independent EU entity outside the provider's reach, the order yields only ciphertext.

What's the difference between BYOK and HYOK? "Bring your own key" usually still stores the key inside the provider's key manager, so the provider can be compelled to use it. "Hold your own key" keeps the key outside the provider entirely, which is what actually removes the provider's ability to produce plaintext.

Is "encrypted at rest" enough for data sovereignty? No. It protects against theft of stored data, but not against lawful compulsion of whoever holds the keys. Custody, not encryption alone, decides the sovereignty question.

Does confidential computing solve foreign-access risk? It helps by protecting data during processing, but recent research shows hardware isolation can be attacked with physical access: the exact scenario sovereignty cares about. Use it alongside customer-held keys, not instead of them.

---

The bytes don't matter if someone else holds the key that turns them back into words. See how the Soveryne Cloud Foundation keeps custody (and the audit trail) in EU jurisdiction: explore the platform, or read the companion piece on why compliance isn't sovereignty.

Sources

• The Register, Microsoft "cannot guarantee" data sovereignty (2025): https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
• BleepingComputer, hardware-isolation (TEE) attack research (2025): https://www.bleepingcomputer.com/news/security/teefail-attack-breaks-confidential-computing-on-intel-amd-nvidia-cpus/
• Public Sector Network, encryption doesn't guarantee sovereignty: https://publicsectornetwork.com/insight/cloud-act-and-data-protection-encryption-doesnt-guarantee-sovereignty
• Utimaco, achieving data sovereignty through key control: https://utimaco.com/news/blog-posts/achieve-data-sovereignty-gaining-control-over-encryption-keys-three-approaches
• CSIS, the CLOUD Act and transatlantic trust: https://www.csis.org/analysis/cloud-act-and-transatlantic-trust