Why server location alone does not protect companies
Introduction
Critical IT infrastructure has concentrated sharply around a handful of global hyperscalers over the past decade, and a recent Bitkom survey found that 78 percent of German companies consider their dependence on US cloud providers too high. The instinct to bring everything back in-house is just as risky as the dependency itself, since self-hosting rarely scales well or improves security. The real question is not whether to keep control in-house, but which controls actually matter.
Key Takeaways
- The US CLOUD Act lets US federal authorities compel data disclosure from American companies regardless of where the data is physically stored, so a Frankfurt or Dublin data center run by a US provider offers no real legal shield.
- Most hyperscalers manage encryption keys as part of their service, which means the provider, not the customer, holds decision-making power if a legal request arrives.
- "Sovereignty washing" describes providers marketing a European data center location as proof of sovereignty without changing the underlying legal or technical architecture.
- Genuine sovereignty rests on three questions: who controls the encryption keys, which legal jurisdiction actually governs the provider, and who holds administrative access to production systems.
- A workable path forward is a criticality-based multi-cloud strategy, keeping the most sensitive workloads in sovereign, key-independent environments while standard workloads can remain on global platforms.
Sommer's argument starts with a legal mechanism most IT teams underestimate. The US CLOUD Act applies to any company headquartered or operationally rooted in the US, independent of where its servers physically sit, which puts European data protection law on a direct collision course with US federal law whenever a US-based provider is involved.
The technical layer compounds the legal one. Because most hyperscalers offer encryption as a managed service, they typically generate, store, and rotate the keys themselves, meaning the provider, not the data owner, effectively decides what happens under a legal disclosure request. Modular, multi-vendor architectures make this harder to track, since a European SaaS product can quietly depend on US-based infrastructure, CDNs, or logging platforms several layers down.
Sommer is direct about the marketing risk this creates: providers advertising a German or Swiss data center as proof of sovereignty, without addressing key control or jurisdiction, are engaged in what he calls sovereignty washing. Real sovereignty, in his framing, comes down to three architectural decisions, tracking jurisdiction as an ongoing vendor-management variable, adopting a genuine zero-knowledge architecture where the provider never has access to unencrypted data, and keeping administrative access time-limited, logged, and subject to customer approval.
His recommended path is not full repatriation to on-premises systems, which he considers impractical for most organizations, but a multi-cloud strategy that classifies workloads by sensitivity. Identity management, key infrastructure, and regulated data move to sovereign environments with verifiable key ownership and clear EU or Swiss jurisdiction, while lower-risk, standardized workloads can stay on global platforms. Portability and separated key management across providers are what keep this approach from creating a new single point of failure.
👉 Read the full article on CloudComputing-Insider:
https://www.cloudcomputing-insider.de/warum-der-serverstandort-allein-unternehmen-nicht-schuetzt-a-27b84c389568b5bf0b9691aeb71b5d26/
Published on: cloudcomputing-insider.de
Author: Alexander Sommer
Conclusion
Digital sovereignty is not a question a data center address can answer. It requires a systematic look at access paths, legal jurisdiction, and encryption architecture across every service in use, and the willingness to treat cloud dependencies as a spectrum rather than a single yes-or-no decision.
_converted.avif)