Skip to main content

The EU's Cloud Sovereignty Framework Grades Providers SEAL-0 to SEAL-4: Where Owned Hetzner Hardware Lands That a Hosted PaaS Provider Can't Follow

10 min readDora NodaDora Noda
Share
On this page

In April 2026, the European Commission handed a piece of a €180 million sovereign-cloud contract to S3NS — a joint venture between Thales and Google Cloud — and rated it "sovereign." A French industry group called it "sovereignty washing" the same week. That's the punchline of the EU's new Cloud Sovereignty Framework: it doesn't grade vendors on a marketing claim, it grades them on a published, 48-criteria methodology that produces a single number, SEAL-0 through SEAL-4, and that number doesn't always say what a logo does.

So where does a self-hosted platform running end-to-end on owned Hetzner bare metal actually land on that scale? Concretely: SEAL-3, Digital Resilience — the same tier three of the EU's own four tender winners hit — but only if the company operating the platform is itself EU-incorporated. Hardware jurisdiction and operator jurisdiction are scored separately, and owning the rack in Falkenstein doesn't automatically clear the second one. Full SEAL-4 stays out of reach for the same reason it was out of reach for every real 2026 tender winner: the chips underneath are still Intel and AMD silicon, not an EU-fabbed stack.

That's the answer. The rest of this post is where it comes from — the framework's actual scoring mechanics, why an EU-region deployment on a US-headquartered PaaS can score lower than a self-hosted stack on the exact same continent, and why Germany's NIS2 law just turned "we're EU-based" from a slide-deck line into a number someone has to produce.

What SEAL Actually Measures

The Cloud Sovereignty Framework, published by the European Commission on June 1, 2026, isn't a badge program — it's an assessment methodology the Commission built to run its own €180 million Cloud III procurement, then made public. It scores a provider across eight sovereignty objectives — Strategic, Legal & Jurisdictional, Data & AI, Operational, Supply Chain, Technology, Security & Compliance, and Environmental — broken into 48 specific, individually-defined criteria. The objective scores roll up into a single Sovereignty Effectiveness Assurance Level (SEAL):

LevelNameWhat it actually means
SEAL-0No SovereigntyService fully controlled by a non-EU party under non-EU law. Automatically disqualified from the EU's own tender.
SEAL-1Jurisdictional SovereigntyEU contracts exist on paper, but operational control — and a foreign parent's ability to compel access — still sits outside the EU.
SEAL-2Data SovereigntyEU law is both applicable and enforceable. Non-EU dependencies can remain, but they don't override EU data protection. This was the minimum eligibility bar for the Commission's own tender.
SEAL-3Digital ResilienceService, technology, and operations are immune to supply-chain disruption from non-EU third parties.
SEAL-4Full Digital SovereigntyA completely EU-sourced stack, chips to application layer. No tender winner reached it.

Two things fall out of that table immediately. First, SEAL-2 is a floor, not a target — it's the level at which a provider merely isn't disqualified. Second, SEAL-4 has never been awarded to anyone, because it requires EU-fabricated silicon, and there isn't a commercially available EU CPU supply chain to buy from yet. Every real answer on this scale, including the one further down for owned Hetzner hardware, lives in the SEAL-2-to-SEAL-3 band.

The Real Scoresheet: What the April 2026 Tender Actually Awarded

The Commission didn't just publish a rubric — it ran it. Four providers split the €180 million Cloud III contract, and their published levels are the closest thing to ground truth this framework has produced:

WinnerSEAL LevelWhy
Luxembourg's POST Telecom (with OVHcloud, CleverCloud)SEAL-3Own technology stack, EU-incorporated operator, EU-jurisdiction operations end to end.
Germany's STACKITSEAL-3Same profile — self-developed platform, no foreign-parent compulsion path.
France's ScalewaySEAL-3Same profile.
Belgian/French consortium led by Proximus, with S3NSSEAL-2S3NS runs on Google Cloud's underlying technology. Google Cloud is a US corporation subject to the CLOUD Act — a dependency the framework counts against the Legal & Jurisdictional objective even though S3NS itself is EU-incorporated and EU-operated.

That last row is the whole framework in miniature. S3NS didn't fail the tender — SEAL-2 was the eligibility bar, and it cleared it. But three competitors running their own stack top to bottom landed a full tier higher, and the gap between them is exactly one thing: whose law can reach the technology underneath, not whose logo is on the invoice. CISPE, the European cloud industry association, put it bluntly: recognizing a Google-technology-dependent service as "sovereign" risks "institutionalizing sovereignty washing at the highest levels." The Commission's counter-argument — that even non-EU technology can clear a sovereignty bar "when operated within a strict and appropriate framework" — is true as far as SEAL-2 goes. It just isn't SEAL-3.

Residency vs. Sovereignty: Why the CLOUD Act Is the Whole Mechanism

The framework's authors are explicit that this scale exists to formalize a distinction most vendor pitches blur: data residency is where the bytes physically sit; data sovereignty is who can be legally compelled to hand them over.

Residency is easy to buy. Pick an EU region from a hyperscaler's console, and the disks are in Frankfurt or Dublin. That answers a geography question. It does not answer the sovereignty question, because the US CLOUD Act requires any US-incorporated company to produce data under its control to US law enforcement on a valid order — regardless of where that data is physically stored. No European data center address overrides that obligation, because the obligation attaches to the corporate entity, not the rack.

That's precisely why an EU-region deployment on a US-headquartered hosted PaaS scores low on the Legal & Jurisdictional objective even when every byte sits inside EU borders: the operator is reachable by a non-EU court, full stop. It's also precisely why owning Hetzner-brand hardware in Nuremberg doesn't automatically fix the same problem for a self-hosted platform, which is the caveat the next section can't skip.

The Honest Gap: Hardware Jurisdiction Isn't Operator Jurisdiction

Here's where a lot of self-hosting pitches get sloppy, and where this one won't. "We run on Hetzner, therefore we're sovereign" conflates two things the framework scores separately:

  • Where the machine sits and whose supply chain it depends on — this is the Operational and Supply Chain objectives, and owned Hetzner bare metal clears them well: Hetzner is a German company, the hardware is provisioned and controlled directly (not resold through an intermediary), and there's no foreign-parent contract sitting between the tenant and the rack.
  • Who can be legally compelled to act on the data running on that machine — this is the Legal & Jurisdictional objective, and it scores the entity operating the platform, not the entity making the box. A platform operator incorporated in the US, running its software on rented Hetzner capacity, still inherits CLOUD Act exposure through its own corporate structure — the exact mechanism from the section above, just moved one layer up the stack. Hetzner's own jurisdiction doesn't launder that away.

Put those together and the honest answer looks like this: a self-hosted PaaS running entirely on owned Hetzner hardware, operated by an EU-incorporated entity with no non-EU parent able to compel access, lands at SEAL-3 — Digital Resilience — the same tier POST Telecom, STACKIT, and Scaleway hit, and for the same underlying reason: EU law applies, is enforceable, and there's no foreign supply-chain or corporate dependency left to disrupt it.

It does not land at SEAL-4. That tier requires a fully EU-sourced stack from silicon upward, and Hetzner's servers — like every other provider's in this tender, including the three that hit SEAL-3 — run on Intel and AMD processors. There is currently no commercially viable EU alternative CPU supply chain to swap in. Claiming SEAL-4 for any x86-based deployment in 2026 would be the same category of overreach CISPE flagged in S3NS, just pointed the other direction. SEAL-3 is the real, defensible ceiling, and it's still a full tier above what a US-headquartered operator can reach no matter which EU region it deploys into.

NIS2 Just Turned This Into a Compliance Question, Not a Sales Pitch

This would be an academic distinction if nothing forced anyone to check it. Germany's NIS2UmsG — the national law transposing the EU's NIS2 directive — became binding on December 5, 2025, with no transition period, and set a registration deadline of March 6, 2026 with the BSI (Germany's federal cybersecurity agency). Roughly 29,500 companies fall in scope, and NIS2's risk-management obligations require explicitly assessing the jurisdictional risk of a cloud dependency — not just where a vendor says its servers are, but who can be compelled to reach into them.

That's the shift the SEAL framework is built to answer. "We're EU-based" used to be a line in a pitch deck. Under NIS2, it's a line in a documented risk assessment, and an assessor asking "can a non-EU government compel access to this data" wants a methodology behind the answer, not a slide. A concrete SEAL score — derived from the same 48 criteria the Commission used to award its own €180 million contract — is an answer with a paper trail. "Sovereign-sounding" isn't.

The Takeaway for Anyone Actually Running the Stack

The Cloud Sovereignty Framework didn't invent a new requirement out of nothing — it gave a name and a number to a distinction that was always going to matter once NIS2 had teeth. A hosted PaaS can rent an EU region; it can't rent its way out of the jurisdiction its own incorporation puts it under, and the April 2026 tender proved that the Commission will score that gap even against a well-connected consortium. A self-hosted platform on owned EU hardware, run by an EU-incorporated operator, clears the same bar the tender's best-scoring entrants cleared — SEAL-3 — by construction, not negotiation. It just can't pretend to SEAL-4 either, and shouldn't.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned through Cluster API onto Hetzner's own bare metal. The jurisdiction question isn't something to negotiate with a vendor's sales team after the fact; it's answered by who owns the fleet. Star the repo on GitHub or deploy your first app today.

Sources

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex