The recent announcement that the Schwarz Group is moving hundreds of thousands of employees to Google Workspace is being marketed as a "triumph of digital sovereignty".
They built an impressive European data center infrastructure with STACKIT. But migrating from one American hyperscaler to another and calling it sovereignty is essentially an official declaration of surrender.
It is a brilliant marketing campaign, but from an enterprise architecture and compliance perspective, it is a structural failure.
The Cryptographic Facade
To be clear, the technical execution of the storage layer is solid.
Schwarz Digits is utilizing External Key Management combined with Client Side Encryption.
Architecturally, holding the cryptographic keys in their own STACKIT environment while using Google purely for encrypted storage is the correct way to mitigate the US CLOUD Act for data at rest. Google only sees encrypted blobs.
However, encrypting the payload is only a fraction of the governance equation.
Architectural Blind Spot 1: The Execution Context
The fundamental flaw lies in the execution layer. The data is encrypted on the endpoint, but who delivers the application code that performs this encryption?
If users are accessing Workspace via a web browser, Google is delivering the Javascript payload.
If a United States intelligence court issues a secret subpoena, they can legally compel the vendor to serve a modified code payload to a specific target. In that scenario, the local encryption is compromised before the data ever reaches the STACKIT key management vault.
You cannot claim sovereignty if a foreign entity controls the execution environment of your software.
Architectural Blind Spot 2: The Metadata Reality
Encrypting the document content completely ignores the value of metadata. Google still processes the authentication requests, the IP addresses, the timestamps, and the collaboration networks. In state level surveillance or corporate espionage, knowing exactly who is talking to whom, and when, is often more valuable than the actual file content. The hyperscaler still owns the telemetry.
Architectural Blind Spot 3: Structural Dependency
The final point is raw operational governance. What happens when the vendor changes their terms of service, alters their pricing model, or faces extreme political pressure? The cryptographic architecture does not change the fact that the entire enterprise is completely dependent on a US software platform.
True sovereignty requires absolute control over the software itself, not just the encryption keys. Investing massive resources into European data centers just to run American software is not digital independence.
The Governance Reality
The industry needs to stop framing vendor transition projects as "sovereign architectures." True IT security and compliance dictate that you must control the boundaries of the code, the execution, and the data.
The future of enterprise architecture belongs to organizations that invest in owning their systems, not just renting new ones.
Sources:
https://t3n.de/news/echte-europaeische-alternativen-ich-sehe-schwarz-1730598/
justice.gov/dag/cloudact (Official US Department of Justice CLOUD Act mandate)
cloud.google.com/workspace/security (Google Workspace Security and Client Side Encryption architecture)
stackit.de/en/security (STACKIT Cloud Security and Compliance documentation)
edpb.europa.eu (European Data Protection Board guidelines on supplementary measures for data transfers)
nist.gov/publications (National Institute of Standards and Technology Zero Trust Architecture outlining execution context risks)
enisa.europa.eu (European Union Agency for Cybersecurity guidelines on data sovereignty and engineering)
Top comments (12)
This was a really eye-opening perspective for someone like me still learning cloud and security fundamentals. I used to think encryption alone was enough, but your point about the execution layer being controlled externally made me realize sovereignty is more about owning the full system, not just the data. It makes me wonder, is true digital sovereignty realistically achievable for smaller companies, or is it mostly limited to governments and very large enterprises?
Hello Aryan,
To answer your question directly: absolute digital sovereignty is currently a luxury reserved for governments and massive enterprises.
Smaller companies simply do not have the operational budget to own the entire stack. They are forced to compromise. That is exactly why the industry needs better open source alternatives that provide secure execution environments without requiring massive private data centers.
The problem with the Schwarz Group is that they marketed themselves as the biggest provider for a sovereign cloud, but they basically just switched from one hyperscaler to another. Both are owned by United States companies. It is a betrayal of what they claimed to stand for and a massive admission of failure.
That makes a lot of sense, and I appreciate how directly you explained it. It’s interesting, it shifts the idea of sovereignty from being a purely technical problem to being an economic and structural one. It also makes me realize how much trust modern software development implicitly places on external execution environments, even when we believe we’re building “secure” systems. I’m curious to see how open source execution environments evolve over the next few years, because that seems like the only realistic path toward narrowing that gap for smaller organizations.
Thank you Ali!
Author nailed the execution context trap—but here's what beginners miss: even perfect crypto is worthless if you don't control the runtime.
Real sovereignty = owning the full stack (code delivery + keys + infra). Start small: self-host a docs tool (Nextcloud/CryptPad) on your own VPS. You'll learn more about IAM, TLS, and blast radius than any AWS tutorial.
The STACKIT case isn't failure—it's pragmatism. True sovereignty costs millions. For SMBs? Hybrid: critical data self-hosted, commodity workloads on hyperscalers with strict boundary controls.
On the value of self hosting for beginners...I agree with you.
Building out a CryptPad instance on a Virtual Private Server is exactly how you learn the real architectural boundaries of Identity and Access Management.
However, I have to push back on classifying the Schwarz Group move as mere pragmatism. For a small to medium business, hybrid is absolutely the correct and only viable operational reality. They do not have the budget for full stack sovereignty.
But Schwarz Group is a massive enterprise that marketed STACKIT specifically as the sovereign alternative for Europe. When an entity with their capital defaults to a United States hyperscaler for the execution layer, it is not pragmatism. It is a structural surrender. Over eight years of professional experience has taught me that when enterprises with infinite budgets compromise on the execution layer, the resulting architecture is just a "decentralized dependency".
The JavaScript payload attack vector is the real killer here — encryption is meaningless if the execution context is compromised before keys are even touched. Metadata analysis alone can reconstruct most of what the encrypted content would reveal.
Thank you 🙏 Klemment!
The vendor-swapping-isn't-sovereignty argument applies even more strongly to AI tooling than to traditional cloud. Teams are building workflows deeply coupled to specific model APIs, specific context window sizes, specific tool-calling formats. Swapping from one LLM provider to another isn't just a compliance exercise — it's an architecture migration. The abstraction layers that claim to make models interchangeable (LangChain, etc.) hide the differences but don't eliminate them. Every model has different failure modes, different strengths on different task types, different cost curves. True sovereignty in the AI stack means owning your evaluation framework so you can actually measure what changes when you swap.
Very interesting read, thanks for sharing. I am reading more into digital sovereignty topics and am curious if you have any good resources recommendations to educate myself better on this topic?
That is a great question.
If you want to understand digital sovereignty, you need to look beyond writing code and understand where that code is executed.
I recommend starting with three foundational sources.
First, read the architectural guidelines published by „ENISA“, the European Union Agency for Cybersecurity.
Second, look into the technical framework of „Gaia X“ which explains federated data infrastructure.
Third, study the „Cloud Native Computing Foundation“ whitepapers on avoiding vendor lock in.
Amazing, thank you very much! I will take a look at these resources.
No problem.