Thales holds the keys to Google's sovereign cloud in Germany: what that fixes, and what is still Google underneath

Key points:

• What was announced: on 20 May 2026, Thales and Google Cloud announced a sovereign cloud in Germany run by a new German entity that Thales fully owns, with a region in the Berlin area, in preview now and generally available by the end of 2026 (Google Cloud Press Corner, S3NS). Google says the root of trust, keys, IP addresses, identities and operations sit with Thales, with the key handover planned by the end of 2026 (heise).
• It copies S3NS: the German entity uses the same architecture, technology and operating model as S3NS, the Thales subsidiary whose PREMI3NS offer holds SecNumCloud 3.2 in France, while staying operationally separate.
• Key custody, operator control and jurisdiction are three different protections. Keys held by Thales stop Google from reading data at rest. A Thales-owned operator stops Google staff from touching production. German law on a European-owned entity is what weakens the US CLOUD Act route. The German setup addresses all three on paper.
• It is still Google underneath, and that part does not change. Google supplies the software, the updates and the roadmap. Your code, your Terraform and your team's skills stay tied to Google Cloud APIs, so it reduces legal exposure but does not make you independent of Google as a vendor.
• Independence comes from portability. If your workloads run on Kubernetes with infrastructure as code, moving between this cloud, a hyperscaler region and an EU-owned provider stays affordable. Qovery deploys on Kubernetes in your own cloud account or on a cluster you already run, which keeps that move a procurement decision.

Thales holding the encryption keys for a Google-built cloud solves a real problem. It does not solve all of them, and the marketing word "sovereign" hides which one it solves.

I have interviewed more than 200 CTOs, and since the Thales and Google announcement for Germany, I keep getting the same two questions from European teams. Does Thales holding the keys actually solve data sovereignty? And is this real independence, or just Google with a new logo on the door? I already wrote about the four levels of EU cloud sovereignty and about Bleu, S3NS and Scaleway in France. This one is narrower. I want to separate three controls that get bundled together (key custody, operator control and jurisdiction) and show which risk each one actually removes.

What exactly did Thales and Google announce for Germany?

Thales and Google Cloud announced on 20 May 2026 a sovereign cloud in Germany built on Google Cloud technology and run by a new German entity that Thales fully owns and controls. It is in preview now, targets general availability by the end of 2026, and is designed for BSI C5 and Germany's new C3A sovereignty criteria (Google Cloud Press Corner).

Here are the facts on record, each from the vendors or the press that covered the launch:

• Operator: a new German entity, "legally and operationally independent from Google Cloud", staffed and managed by local German personnel (Google Cloud Press Corner).
• Ownership: the entity is 100% owned and controlled by Thales in Germany, and "Google acts solely as a technology provider" (S3NS).
• Location: a dedicated, isolated region in the Berlin area under German law, operating autonomously from Google Cloud (S3NS).
• Keys and control: Google Cloud's Wieland Holfelder told heise that "the root of trust, keys, IP addresses, identities and the entire operation" lie with Thales, and that Thales is to receive the cryptographic keys by the end of 2026 (heise).
• Services named at launch: BigQuery, managed Kubernetes (GKE), AI with H100 GPUs and Gemini Enterprise, and Google Secret Manager (S3NS).
• People: more than 50 jobs created by Thales for the German operations (S3NS).

A note on timing, because the question going around says Thales "now holds" the keys. The commitments on record put the key handover and general availability at the end of 2026. As of 15 November 2026, I could not find a public confirmation that the handover is complete. If your contract depends on it, ask Thales for the date and the evidence in writing.

The certification target matters too. C3A, the "Criteria enabling Cloud Computing Autonomy", was published by Germany's BSI on 27 April 2026. It assesses whether a cloud service can be used in a self-determined way within a given risk context, and it presupposes that the provider already meets C5 (BSI, BSI press release). C3A is a criteria catalogue for buyers, and the BSI says an audit guide will follow. Until those audits exist, "designed with C3A in mind" describes a design goal.

How does the German cloud relate to S3NS in France?

The German entity is a copy of the S3NS model, run separately. S3NS describes itself as the blueprint, with "the same architecture, the same technology (Google Cloud), and the same operating model", while the German offer stays "operationally separate to meet local sovereignty requirements" (S3NS).

S3NS gives us the best preview of how the German cloud will work, because it has been running for three years:

• Qualification: S3NS's PREMI3NS offer received SecNumCloud 3.2 qualification on 17 December 2025, covering IaaS, CaaS and PaaS (Thales).
• Ownership: S3NS is controlled by Thales. Google holds a minority stake, which Futurum puts at about 20% (Futurum). The German entity goes further: 100% Thales.
• Updates: at S3NS, Google Cloud updates "are received in a quarantine zone, inspected, and only moved to production once validated by S3NS" (S3NS).
• Adoption: S3NS says more than 70 customers already use it (S3NS).

The two regions are meant to back each other up. Thales calls it a pan-European, geo-redundant sovereign cloud with cross-border disaster recovery, and S3NS aims for both SecNumCloud and C5 plus C3A across both regions (Google Cloud Press Corner). For a company selling to both the French and German public sectors, that is the most concrete benefit in the whole announcement: one technology stack, two national certifications, two operators.

In Google's own vocabulary, this is "Google Cloud Dedicated (partner-operated)": dedicated infrastructure run by a local partner under local law, designed to keep operating for up to twelve months if disconnected from Google (Google Cloud).

Who holds the keys, who runs the cloud, and whose law applies?

These are three separate questions, and every sovereign offer answers them differently. Key custody decides who can decrypt your data. Operator control decides who can log in to production, patch it and see metadata. Jurisdiction decides which government can compel the company that does either of those things. A cloud can score well on one and badly on another.

Here is what each control removes, and what it leaves in place:

"Thales holds the keys" protects you from Google. It does not protect you from Thales. From the customer's side, the key holder is still a third party. If your threat model includes the operator itself, you want keys that you hold, and you should ask whether the German offer lets you bring your own external key manager on top. I could not find that answered in the public material yet.

On Google's public cloud, customer-held keys already exist. Cloud External Key Manager (Cloud EKM) lets you keep keys in a supported external key manager, and Google states that "the external key material is never exposed to Google" and that externally managed keys "are never cached or stored within Google Cloud" (Google Cloud EKM). Thales is one of the three supported partners, alongside Fortanix and Futurex. Key Access Justifications adds a reason code to each key request so you can approve or deny it by policy (Google Cloud).

So external key management on a hyperscaler is old news. In Germany, the key holder, the operator and the legal entity are the same European company, and Google is reduced to a supplier. That combination is the new part.

Does Thales holding the keys stop the US CLOUD Act?

Thales holding the keys does a lot against the CLOUD Act, but the ownership structure does more. The CLOUD Act obliges a US provider to disclose data "within such provider's possession, custody, or control, regardless of whether" it is located inside or outside the United States (18 U.S.C. 2713). The legal test is possession, custody or control.

In the German setup, Google is supposed to have none of the three. The infrastructure is operated by a German entity Google does not own, the staff are local, and the keys sit with Thales. A US order served on Google would hit a company that, by design, cannot produce readable data. That is a stronger position than the one most hyperscaler offers can claim, where the data is in an EU region but the US parent still owns the operating company.

Three caveats I would put in front of any legal team:

1. Design is not a court ruling. The structure is built to keep Google out of "possession, custody, or control". No court has tested this exact arrangement under the CLOUD Act that I know of.
2. Keys protect data at rest. Google's own EKM documentation describes protection of data at rest in services that support customer-managed keys (Google Cloud EKM). Data being processed lives decrypted in memory, so the people who run the machines matter as much as the people who hold the keys. Here, that is Thales again.
3. Thales has its own jurisdiction. Thales is a French group, so French and EU law apply to it, including lawful access by European authorities. For most European buyers that is the point. For some, it is a fact to write down.

France already settled part of this debate. SecNumCloud 3.2 includes requirements on protection against non-EU law (ANSSI). ANSSI qualified S3NS's dedicated PREMI3NS offer; S3NS's "Local Controls" offer, which runs on Google's public cloud, does not carry the qualification. Germany's C3A now asks the same family of questions with its own criteria. If you want the longer version of the CLOUD Act argument, I compared it across Microsoft's offers in Does Microsoft's Sovereign Private Cloud actually escape the US CLOUD Act?.

What is still Google underneath, and does it matter?

Yes, it is still Google underneath, and for most buyers that is acceptable. The hardware design, the hypervisor, GKE, BigQuery, the APIs and the product roadmap all come from Google. Google keeps responsibility for technology supply, software updates and supply chain management (cloudmagazin). Thales runs it.

What that means in practice depends on which risk keeps you up at night:

• Risk: a foreign government reads your data. Mostly addressed. Operator, key holder and legal entity are European.
• Risk: your supplier stops shipping updates (sanctions, export controls, a commercial dispute). Partly addressed. Google says partner-operated Dedicated clouds are designed to keep running for up to twelve months if disconnected (Google Cloud). Twelve months buys time to plan a move. It does not replace one.
• Risk: malicious or vulnerable code in an update. Partly addressed. The S3NS model quarantines and inspects updates before production (S3NS). Inspection lowers the risk; reviewing every line of a hyperscaler's code is not realistic for any operator.
• Risk: lock-in and pricing power. Not addressed at all. Your Terraform, your IAM model, your BigQuery SQL and your team's habits are Google Cloud's. If you ever want to leave, you leave Google, sovereign wrapper or not.
• Risk: feature lag. Real, and worth checking per service. Partner-operated clouds ship what the operator has validated, so the catalogue and the release cadence can trail the public regions.

The phrase "rebrand the infrastructure underneath" is too harsh, in my view. A rebrand changes the logo. This changes who can log in, who holds the keys and which court can order what. The phrase "real independence" is too generous. You are independent from Google as an operator. You are still dependent on Google as a supplier.

How does it compare with the other sovereign options in Germany?

A German buyer now has at least five shapes of "sovereign" to choose from. They differ mostly on two axes: who owns the operating company, and whose software runs underneath.

Two numbers explain why the partner-operated model exists at all. AWS, Microsoft and Google hold about 70% of European cloud spend, while European providers hold about 15% (Synergy Research Group). And Google estimates 5.5 billion euros of German infrastructure investment through 2029 (heise). European buyers want hyperscaler services; regulators want European control. The Thales model sells both at once.

If you are weighing the EU-owned row instead, I compared what actually runs on STACKIT, IONOS and Open Telekom Cloud, and the hardware-plus-cloud angle in the Bull and Schwarz Digits sovereign stack.

Does it give European companies real independence?

It gives European companies independence from Google as an operator and as a legal target, and no independence from Google as a technology supplier. Whether that is enough depends on who you sell to and what you are protecting.

Here is how I would decide, by buyer:

• German public sector or critical infrastructure that wants Google services: this is built for you. Track the C5 and C3A evidence and the GA date, and do not sign on "designed for" language alone.
• A company selling to both French and German regulated buyers: the S3NS plus Germany pairing is attractive because one stack can target SecNumCloud and C3A at once. Check that the services you need exist in both regions.
• A regulated enterprise already on Google Cloud: compare the cost and catalogue against staying on a public region with Data Boundary and Cloud EKM using your own keys. If your auditors accept that, it is cheaper and broader.
• A SaaS company with no contract clause naming C5, C3A or SecNumCloud yet: stay where you are, keep data in an EU region, hold your own keys, and invest in portability. That is what keeps the next contract from becoming a migration project.
• Anyone whose threat model includes the supplier itself: look at EU-owned providers, accept a thinner catalogue, and plan for it.

As I wrote in my earlier piece, decide sovereignty per workload. Running customer data on a partner-operated cloud and CI on a public region is normal and defensible.

How do I keep the exit cheap whichever sovereign cloud I pick?

You keep the exit cheap by making your applications indifferent to the cloud underneath. The Thales cloud offers managed Kubernetes (GKE) (S3NS), and so does every serious option in the table above. Kubernetes is the one layer you can carry from a Google public region to a partner-operated cloud to an EU-owned provider without rewriting your apps.

What tends to break a move is everything around the cluster:

• Deployment pipelines written against one provider's CI, registry and IAM.
• Managed services (a proprietary database, queue or analytics engine) with no equivalent on the destination.
• Infrastructure code that encodes one provider's resource model.
• Tribal knowledge about how to promote a release, roll back and grant access.

This is where Qovery fits. Qovery is an Agentic DevOps platform that deploys and runs your applications, databases, jobs and Helm charts on Kubernetes in your own AWS, GCP, Azure or Scaleway account, or on a Kubernetes cluster you already run, including on-premise ones. The control plane (Qovery) is separate from the data plane (your cluster), and your apps and data stay in your cluster. Developers keep git-push deployments and preview environments per pull request, and the platform team keeps RBAC and audit logs, wherever the cluster lives.

One honest point for sovereignty reviews: Qovery's control plane is a service your cluster connects to. Most data residency reviews are fine with that because application data never leaves the cluster, but if your scope forbids any external control plane, raise it early and talk with us about your setup. Qovery helps you meet controls like access management and change tracking. It does not make you compliant, and it does not hold a C3A or SecNumCloud qualification for you.

Before you sign with any sovereign provider, run the drills in 7 tests before you trust a sovereign cloud migration. The cheapest one is redeploying a real service on a second cluster at a different provider and timing it.

How do I test portability with Qovery from Claude Code or Cursor?

You can let a coding agent set up the portability test for you. Install the Qovery Agent Skills, then ask the agent to deploy the same app to two clusters in different clouds.

curl -fsSL https://skill.qovery.com/install.sh | bash

# MCP Server for Claude Code: OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

The first command installs the skills (qovery-onboard, qovery-deploy, qovery-troubleshoot and others) into your agent. The second connects Claude Code to the Qovery MCP Server in read-only mode, so the agent can inspect clusters and deployments without changing anything; it opens an OAuth login you approve in the browser. Then ask in plain language, for example: "deploy this app to my GCP cluster and to my existing Kubernetes cluster with Qovery, and tell me what differs". The agent asks you to approve each action. See the AI agent quickstart and the Claude Code integration.