OVHcloud's SecNumCloud GA in June 2026: Why 'EU-Headquartered' Isn't a Sovereignty Certification

"Our fleet runs on EU-headquartered bare metal" is a true statement — and for a regulated buyer, an incomplete one.

In June 2026, OVHcloud's SecNumCloud-qualified offering went generally available for on-demand instances, metal instances, block storage, and object storage, with managed Kubernetes and managed databases queued next. The underlying qualification is ANSSI's SecNumCloud 3.2 — a French security visa built on ISO 27001 plus roughly 360 additional controls, explicit immunity requirements against extraterritorial laws like the US CLOUD Act and FISA 702, and caps on non-EU ownership. OVHcloud's qualified services run out of Roubaix, Gravelines, and Strasbourg under that visa. The GA announcement arrived alongside a new Bare Metal 2026 server line and a 2026–2028 pricing path of 9–11% average annual increases for new Public Cloud, Private Cloud, and Bare Metal deployments.

Here is why that matters if your sovereignty pitch is still one line — "we're on Hetzner, a German company" — and where the line stops being enough.

That table is the whole argument. The rest of this post shows what is behind each row, where the EU's emerging SEAL framework lands, why a US hyperscaler's "sovereign region" still answers the wrong half of the question, and when your PaaS actually needs to point at a named visa to close a deal.

What OVHcloud Actually Shipped in June 2026​

OVHcloud is not new to SecNumCloud. Its Hosted Private Cloud (VMware on OVHcloud) and its Bare Metal Pod have carried SecNumCloud qualification for some time, running in French data centers with per-customer physical and network isolation. What went GA in June 2026 is a broader qualified surface: on-demand instances, metal instances, block storage, and object storage — the primitives a tenant actually builds a PaaS fleet on — with managed Kubernetes and managed databases following on the same qualified path.

Three details worth reading precisely:

Scope is per-service, not per-company. SecNumCloud qualifies a specific service running in a specific operational configuration, not a company's entire catalogue. OVHcloud listing "on-demand, metal, block, object — K8s and databases next" is a scope statement: those SKUs run under the visa, others do not yet. A buyer who needs a qualified database does not get it by putting an unqualified managed DB next to a qualified VM and calling the architecture sovereign. Scope is checked SKU by SKU.

Location is France, not "EU." The qualified services run out of Roubaix, Gravelines, and Strasbourg. France-qualified is not EU-qualified by automatic extension; ANSSI's visa is a French national qualification that the EU's forthcoming EUCS High+ and CADA frameworks reference as a benchmark, but the operational perimeter that an auditor checks today is those three French sites. If your threat model is "any EU data center," Hetzner's Nuremberg/Falkenstein/Helsinki footprint covers it. If your buyer's procurement clause literally names SecNumCloud, the qualifying perimeter is French soil.

The price path is part of the announcement. OVHcloud's April 1, 2026 pricing update — the same one that lifted VPS-1 roughly 55% and VPS-4 roughly 67% — set a 9–11% average annual increase for new Public Cloud, Private Cloud, and Bare Metal deployments created between 2026 and 2028, alongside 2–6% on pre-2025 iron and a Bare Metal 2026 refresh of the server catalogue. The visa is not free. Packaging it as a qualified on-demand instance bakes in the cost of the audited operational controls, the dedicated isolation, and the compliance overhead that a commodity VPS never carried. Planning a fleet without modelling that slope is the same mistake as planning a Hetzner fleet on a frozen pre-April-2026 price.

What SecNumCloud 3.2 Actually Requires​

ANSSI's SecNumCloud referential (v3.2, dating to 2022) is the most demanding sovereign-cloud visa in Europe. Public summaries put it at ISO 27001 plus roughly 360 additional requirements across technical security, sovereignty, and ownership structure. That number is not marketing — it reflects that sovereignty is treated as a security property, not a jurisdiction label. Five buckets do most of the work beyond ISO:

1. ISO 27001 as floor, not ceiling. Every qualified provider is ISO 27001-certified. The visa then layers Annex A-plus controls for cloud-specific operational security: privileged-access management, incident handling under ANSSI oversight, cryptographic governance, and supply-chain vetting. ISO alone says "you have a management system." SecNumCloud says "that system runs a specific cloud service in a way ANSSI has audited on the ground."

2. Operational control separation. The service's day-to-day operations — who can touch the control plane, how administrative access is granted and logged, where operational staff sit — must be demonstrably separable from any non-EU administrative domain. "Control separation" is not a sentence in a DPA; it is an audited operational design where ANSSI has verified that administrative access and support tooling do not route through systems subject to non-EU legal compulsion. The existing Hosted Private Cloud pattern on OVHcloud (fully dedicated servers and network per customer within an OVHcloud DC) is a concrete example of the isolation shape this requires.

3. Capital and voting-rights caps. SecNumCloud 3.2 incorporates legal-sovereignty criteria that directly cap foreign control: non-EU entities may not individually hold more than 24% of capital or voting rights, and collectively more than 39%. This is the "24% rule" now echoed in EU sovereignty discussions. It is not an anti-investment rule; it is the legal mirror of the operational rule — a provider cannot be operationally sovereign if a non-EU shareholder can, in law, compel it. For a venture-backed European startup hoping to self-certify, this is the row that quietly eliminates most cap tables before the technical audit begins.

4. Immunity to extraterritorial laws — by design, not by promise. Version 3.2 explicitly requires protection against non-EU extraterritorial regimes. ANSSI's public commentary names the US CLOUD Act and FISA 702 as the specific laws the update was designed to counter; the broader requirement extends to any foreign legal instrument that could compel data access. The provider must demonstrate architectural and legal controls that prevent such compulsion — not a contractual commitment to "push back," but a design where the data is not reachable by the foreign jurisdiction in the first place. This is the row where most US-headquartered providers fail at the structural level, before any technical detail is even examined.

5. Government-vetted operational processes. Qualification is not self-attested. ANSSI evaluates the provider's request, validates prerequisites (Eurozone HQ, ISO 27001 posture, scope definition — Scaleway's public J0 milestone is a visible example of the staged gate), and audits the running service. The visa is a security visa in ANSSI's literal sense: a qualification the agency issues after examination, not a badge the provider claims. Procurement that names SecNumCloud is therefore outsourcing part of its vendor diligence to ANSSI's audit rather than running it all in-house.

None of these five rows is satisfied by "our provider is headquartered in the EU." EU headquarters clears a necessary condition (Eurozone incorporation) but none of the operational or immunity conditions. That is the gap the rest of the post maps.

The Three Layers of Sovereignty — and Where "EU-Headquartered" Stops​

Sovereignty is not one claim. The EU's Cloud Sovereignty Framework makes this explicit with its SEAL grading — Sovereignty Effectiveness Assurance Levels from SEAL-0 (no sovereignty) to SEAL-4 (full assurance). Underneath the acronym, three layers fall out that any buyer can use without learning the full framework:

Layer 1 — Jurisdictional sovereignty: where the data sits and whose law formally applies. Hetzner clears this: German company, EU data centers, GDPR-governed DPA. So does any EU-region deployment of a US hyperscaler. This is the layer most PaaS marketing means when it says "sovereign." It is necessary and nowhere near sufficient for regulated workloads.

Layer 2 — Operational sovereignty: who actually operates the control plane and whether a non-EU entity can direct that operation. Hetzner clears this for itself — German operations, German staff — but your PaaS layer on top does not automatically inherit it. If your own control plane, observability stack, or support tooling routes administrative access through a US SaaS (status page, logging, PagerDuty, a US-hosted CI runner that can push to production), you have reintroduced a non-EU operational dependency that Layer 1 does not capture. SEAL-2 lives here: EU law is applicable, but material non-EU dependencies remain in the operating chain.

Layer 3 — Certified immunity: an auditor — not the vendor — has verified that layers 1 and 2 hold against a named threat model, and the verification is scoped to a specific service. This is SecNumCloud. ANSSI has audited the service's operational separation, its legal control structure, and its extraterritorial immunity design, and issued a visa covering that SKU in that site. A buyer whose procurement clause names SecNumCloud (or, soon, EUCS High+ which aligns closely with 3.2) is not asking "are you sovereign?" They are asking "which visa, for which service, in which site, under which version of the referential?" A jurisdiction sentence does not answer that question.

Where Hetzner sits in this stack is worth stating plainly: Hetzner is a German company with German and Finnish data centers, BSI C5 Type 2 and ISO 27001 certifications, and no SecNumCloud qualification. That is not a criticism — Hetzner has never claimed to be a government-qualified sovereign cloud, and its price-performance for general-purpose fleet capacity remains the reference this list benchmarks every alternative against. But SEAL-wise, Hetzner-backed infrastructure without a per-service ANSSI visa sits at the jurisdictional layer. For a startup running a SaaS on a German node pool, that is the right answer. For an OIV or OSE buying cloud for a hospital, a ministry, or a vital-importance operator, procurement will name a visa. The two buyers are not arguing about the same word.

Why a US-Hyperscaler "Sovereign Region" Answers the Wrong Half​

AWS's European Sovereign Cloud went GA in January 2026 — a Germany-based region described as physically and logically separated from the rest of AWS, backed by a stated €7.8B investment, and expanding to Belgium, the Netherlands, and Portugal. It runs under a dedicated EU legal entity in Brandenburg. On paper it reads like the jurisdiction fix: EU soil, EU entity, EU staff, EU-only operations.

It fixes the technical half. It does not fix the corporate-jurisdiction half — and SecNumCloud 3.2 tests exactly that half.

The test is not "where are the bits?" It is "who can be compelled to produce them, and does the provider's ownership structure make that compulsion structurally impossible?" A US-headquartered parent remains subject to the US CLOUD Act regardless of where a subsidiary's data center sits. AWS's own eu-west-1 (Dublin) already stores data in the EU; the new sovereign cloud adds operational separation and a local entity but does not change the parent's jurisdiction. Standard EU regions and the sovereign cloud both fail the extraterritorial-immunity row of the SecNumCloud checklist for the same reason a US-hosted status page fails your own operational-sovereignty row: the compulsion path runs through the corporate parent, not the data-center door.

This is where the 24%/39% caps bite structurally. S3NS (Thales + Google Cloud) and Bleu (Capgemini + Orange + Microsoft) were designed around those caps precisely because their US technology partners cannot clear them directly. The joint ventures exist to put EU-controlled capital and governance between the customer and the US-parent compulsion path, and only then pursue the SecNumCloud 3.2 qualification. AWS's sovereign region, operated directly by AWS, has not taken that joint-venture step — and until it does, it cannot clear the legal-sovereignty gate no matter how isolated the technical perimeter is.

For a self-hosted PaaS, the implication is symmetrical: you cannot borrow sovereignty from your IaaS provider's marketing page. If your fleet runs on AWS — even in eu-central-1, even in the new European Sovereign Cloud — your tenant's sovereignty claim inherits AWS's corporate jurisdiction. If it runs on OVHcloud's SecNumCloud-qualified SKUs in Roubaix/Gravelines/Strasbourg, it inherits a French-qualified perimeter. If it runs on Hetzner, it inherits German jurisdiction without a French visa. Each is a fact about what you can claim downstream, not a judgment about good or bad providers.

So Does Your PaaS Need to Name a Visa?​

Not every buyer needs the same answer. Here is a decision matrix grounded in how SecNumCloud procurement actually works in France and where the EUCS/CADA trajectory is taking the rest of Europe:

Three practical takeaways for a platform that runs its fleet on owned hardware:

1. Don't oversell jurisdiction as certification. "We run on EU-headquartered bare metal in Nuremberg" is a strong jurisdiction claim. Saying "therefore we are sovereign cloud" in front of a buyer whose tender names SecNumCloud 3.2 will lose the deal in the first compliance call — not because the buyer's requirement is unreasonable, but because you used the wrong noun. Name what you are (jurisdictionally sovereign infrastructure) and what you are not (a government-qualified sovereign cloud service) in the same sentence. The buyer who does not need a visa will not penalize you for precision; the buyer who does will penalize you for the lack of it.

2. If you need a visa, you need a qualified SKU in a qualified site — not just a qualified provider somewhere in your supply chain. OVHcloud's GA makes this actionable: if your Cluster API fleet can provision worker nodes onto OVHcloud's SecNumCloud-qualified on-demand and metal instances in the qualified French sites, and your control-plane and operational tooling can themselves run without routing privileged access through non-EU systems, you can point a regulated tenant at a concrete, auditable scope. "We use OVHcloud" without naming the SKU and site is not that scope. This is also why mixing providers complicates the claim — a fleet with ten Hetzner nodes and two qualified OVHcloud nodes is not a qualified fleet unless the tenant's workload and its operational dependencies are pinned to the qualified subset with documented separation.

3. Cost the visa, don't hide it. A SecNumCloud-qualified node costs more than a commodity CCX. It should — the audited operational separation, the dedicated isolation, and the compliance overhead are real costs that the 9–11% annual slope for new OVHcloud deployments between 2026 and 2028 already prices in. Hetzner's CCX/CPX lines repriced far more sharply (up to 176% on the June 15, 2026 standardization for new orders and rescales) on the same DRAM shock, but that is a market price for commodity capacity, not a qualification premium. Comparing a qualified French node to a commodity German node on monthly price alone repeats the pre-2026 mistake this list has tracked three times — treating a frozen baseline as truth. The honest comparison is qualified French node versus qualified alternative (3DS Outscale, S3NS, Bleu) at today's numbers, and commodity German node versus commodity alternative at today's numbers. Mixing the two comparisons flatters the cheaper side of each without ever pricing what the visa itself is worth to the buyer who requires it.

For Bex — a git-push PaaS that provisions fleets through Cluster API — the shape this points to is not "migrate everything to France." It is a node-pool-aware sovereignty story: default pools on cost-efficient Hetzner for tenants who need jurisdiction, qualified pools on OVHcloud's SecNumCloud SKUs in Roubaix/Gravelines/Strasbourg for tenants whose procurement names a visa, with the control plane's own operational dependencies audited to the same standard as the worker pool. The platform's job is to make the tenant's compliance claim a scheduling decision (which pool, which site, which SKU), not a migration project. That is a narrower claim than "we are a sovereign cloud" — and the narrowness is what makes it auditable.

The Honest Framing​

OVHcloud's June 2026 GA does not make every workload sovereign by moving it to OVHcloud, and Hetzner's lack of a visa does not make every workload non-sovereign by staying on Hetzner. Sovereignty is scoped — to a service, a site, a version of a referential, and a specific threat model (which foreign laws the design is immune to). A startup choosing between a €10 CX22 and a €20 qualified instance is not making a sovereignty decision at all; it is making a cost decision. An OIV choosing between a qualified and an unqualified SKU for patient data is not making a cost decision at all; the tender already made it.

The shift worth marking is not that OVHcloud got a visa. It is that, as of mid-2026, "EU-headquartered" and "government-qualified" are no longer interchangeable shorthand in European procurement — and the EU's CADA / EUCS High+ direction means the gap between them will widen, not close. A self-hosted PaaS that can name, per tenant, which layer it clears and which visa (if any) backs that claim will keep both buyers. One that collapses the layers into one marketing sentence will keep only the buyer who never asked.

Self-hosting sovereignty is a scheduling decision, not a migration. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with Cluster API fleet control so a tenant's compliance claim is which node pool it lands on. Star the repo on GitHub.