EU Cloud III, SEAL, and the Coming Reckoning for Cloud-Rendered Browser Security

For most of the last decade, "sovereign cloud" in European procurement meant a contractual promise. A US-headquartered hyperscaler signed a piece of paper saying that EU data would stay in EU regions, that EU staff would administer it, and that the vendor would resist extraterritorial access requests where local law allowed. Buyers accepted those promises because the alternatives looked thinner. The architecture underneath was almost never inspected.

That era is ending. In October 2025, the European Commission published the Cloud Sovereignty Framework and launched its EUR 180 million tender for sovereign cloud services under the Cloud III Dynamic Purchasing System. In April 2026, the Commission awarded four contracts: Post Telecom (with CleverCloud and OVHcloud), STACKIT, Scaleway, and Proximus. The pattern in those awards is the story.

For browser security buyers, the relevant change is not the headline number. It is the SEAL scoring model that sits underneath it, and the way that model grades vendors not on what their contracts say but on what their architecture actually is. Cloud-rendered browser security products were built for a world where sovereignty was a contractual claim. They are now being asked to compete in a world where it is an architectural one.

If you are new to the category itself, start with What Is Enterprise Browser Security? and then come back to this post for the procurement angle.

What SEAL Actually Measures

The Cloud Sovereignty Framework introduces Sovereignty Effectiveness Assurance Levels (SEAL), a graded scale that runs from SEAL-0 (no sovereignty demonstrated) to SEAL-4 (full digital sovereignty, including an EU supply chain from chips to software). The intermediate levels are SEAL-1 (jurisdictional), SEAL-2 (data), and SEAL-3 (digital resilience). For the Cloud III tender, providers had to reach at least SEAL-2 to be considered eligible at all.

Above the level scale, SEAL grades providers across eight Sovereignty Objectives. Industry analyses of the framework, including innobu's breakdown of SEAL 2026 and the ayedo framework summary, enumerate them as:

1. Strategic Sovereignty
2. Legal and Jurisdictional Sovereignty
3. Data and AI Sovereignty
4. Operational Sovereignty
5. Supply Chain Sovereignty
6. Technology Sovereignty
7. Security and Compliance Sovereignty
8. Environmental Sustainability

Two of these are the ones that should keep a cloud-rendered browser-security vendor up at night. Technology Sovereignty asks whether the provider has actual technical control of the stack, including code, updates, and maintenance, or depends on a foreign parent. Operational Sovereignty asks whether the people running the system, the keys protecting it, and the procedures used to administer it sit inside EU jurisdiction.

The Commission's April 2026 announcement is explicit that the awarded providers were measured against these objectives, and that "technology, operations, governance and supply chain under complete control of EU actors in EU jurisdiction" is what separates the higher tiers from the lower ones. Post Telecom's consortium and STACKIT and Scaleway, all of whom develop their own technology, reached SEAL-3. The Proximus consortium, which depends in part on a Thales-Google joint venture, reached SEAL-2.

That gap between SEAL-3 and SEAL-2 is exactly the gap between "we own the stack" and "we sit on top of someone else's stack." For procurement, it is now a graded, scored, comparable quantity. The Kiteworks analysis of European digital sovereignty procurement makes the point bluntly: sovereignty cannot be outsourced to a provider's contractual promise. The framework now codifies that view.

Why This Matters for Browser Security Specifically

The Commission's procurement is a cloud tender, not a browser-security tender. But cloud sovereignty frameworks have a way of becoming the procurement baseline for everything that runs on a cloud, which is most enterprise security tooling. National procurement offices already mirror Commission practice. EUCS, the European Cybersecurity Certification Scheme for Cloud Services, is moving in the same direction at the regulatory layer. SEAL is the procurement-side companion.

Browser security is a particularly exposed product category in this environment for one specific reason. The browser is where the user's most sensitive content is rendered: every login, every paste into a GenAI tool, every spreadsheet uploaded to a SaaS app, every document opened from a corporate drive. A security product that processes that content has to handle it somewhere. The architectural question that SEAL Technology and Operational Sovereignty are designed to expose is: where, exactly, is "somewhere"?

For the cloud-rendered side of the browser-security market, the answer is structural. The data is processed in the vendor's cloud, on infrastructure the vendor controls, by code the vendor maintains, with operational access held by the vendor's staff. That answer can be dressed up with EU regions, EU subsidiaries, and EU support contracts. It cannot be dressed up enough to score SEAL-3 against a buyer who is actually grading the stack.

We made the architectural case for keeping browser data on the customer's perimeter, on its own merits, in Why Does Surface Security Exist? and on the Why Surface page. The Cloud III award is the moment that case stops being an architectural preference and starts being a procurement requirement.

How Each Cloud-Rendered Competitor Sits Structurally

Each of the major cloud-rendered browser security products does real work and has real strengths. The architectural challenge they share is the same: their data plane and detection live in the vendor's cloud, by design, because that is how the product was built. SEAL grades that fact.

Menlo Security

Menlo's Remote Browser Isolation renders every page in a secure cloud-hosted browser, then streams a sanitized representation back to the user. The model is well engineered. It is also, by definition, cloud-rendered. Menlo's public materials describe a global footprint of fifteen data centers and a managed cloud SaaS operations team running the service. For a SEAL-3 assessment that asks who actually executes the page and who actually runs the operating environment, the honest architectural answer is the vendor, in the vendor's cloud, under the vendor's operational control. Regional EU rendering helps with the data residency question. It does not change the technology and operational sovereignty answers.

Palo Alto Prisma Access Browser

Prisma Browser is, in Palo Alto's own documentation, "a cloud-deployed, Zero Trust browser" managed through cloud-based Strata Cloud Manager or Panorama, with telemetry flowing into WildFire, AutoFocus, and Cortex AI. The forking issue we covered in Surface vs. Enterprise Browsers is one architectural cost. The cloud control plane is the other. Palo Alto is a US-headquartered vendor running a global SaaS service. For SEAL Legal and Jurisdictional Sovereignty, that is a structural disadvantage no EU region offering can fully resolve, because the parent company sits under US extraterritorial law regardless of where any specific region is hosted.

Island

Island's enterprise browser connects through what the vendor calls the Island Management Cloud, with policy synchronization, cloud-rendered RBI for high-risk destinations, and a CASB layer that uses native SaaS APIs. Recent product launches like the SASE rebuild for the AI era lean further into a cloud control plane spanning GCP, Azure, and AWS PoPs. The capability set is broad. The architectural posture, for SEAL purposes, is a US-headquartered vendor running on US hyperscaler infrastructure. That is a hard combination for Technology Sovereignty.

LayerX (Akamai)

LayerX deserves a more careful read because it is the closest in surface architecture to an extension model. Its public materials describe a browser-agnostic extension running on the user's existing browser, and explicitly note that most data, including PII, stays in the browser; only alerts go to the LayerX cloud. That is genuinely better than a full pixel-streaming model. The remaining sovereignty constraint is the cloud control plane itself, hosted on US hyperscalers and managed by a US-headquartered vendor (now becoming part of Akamai through a USD 205 million acquisition). For a SEAL-3 assessment that grades operational sovereignty as well as data residency, the operational plane is still outside EU control. LayerX scores better than Prisma or Island on the data flow question and the same as them on the management plane question.

Versa

Versa is the most interesting case to acknowledge fairly. Versa's Secure Enterprise Browser sits inside the VersaONE SASE platform, and unlike most competitors Versa has publicly committed to a Sovereign SASE deployment model that lets enterprises and service providers run the platform inside their own on-premises or private cloud environments. That is the right shape of answer for a sovereignty-graded procurement. The remaining questions for a Cloud III style assessment are about the supply chain (who builds the underlying VOS, where, with what dependencies) and the operational model (who actually runs the deployment day to day). Versa is the competitor most likely to land on the right side of the SEAL line for some EU buyers; whether they reach SEAL-3 in any specific deployment is a question the framework now lets a procurement office actually ask.

Why an On-Prem Extension Model Is the Structural Fit

The architectural property that SEAL is grading is, at its core, very simple. Where does the sensitive data flow, where does the code that processes it run, and who has operational control of the system around it. The on-prem extension model answers all three questions inside the customer's perimeter.

Surface is a managed browser extension that runs on the user's existing Chrome, Edge, or Firefox install, paired with a control plane the customer deploys on its own infrastructure. Detection runs on-device, inside the extension, using our patent-pending Surface Vision engine. Telemetry flows to the customer's own platform deployment, on Docker, Kubernetes, VMs, bare metal, or an air-gapped network if required. There is no vendor cloud in the data path. There is no shared multi-tenant database. There is no foreign-jurisdiction processing of user activity by default.

Translated into SEAL terms:

• Data and AI Sovereignty (SOV-3). Browser session data, including DOM content, rendered visuals, and DLP inspection results, never leaves the customer's perimeter unless the customer explicitly forwards it.
• Operational Sovereignty (SOV-4). The customer's own staff administer the platform. There is no vendor SRE team holding production credentials. There are no support tunnels into the customer environment by default.
• Technology Sovereignty (SOV-6). The browser itself is not forked or repackaged. Chromium and Firefox patches arrive on their upstream cadence, not on a vendor's monthly roll-up. We made the long-form case for this in Surface vs. Enterprise Browsers. The detection stack on top is the only component the customer has to trust us to maintain, and even that ships through the hardened update pipeline we documented separately.
• Supply Chain Sovereignty (SOV-5). Because the data plane is the customer's, the supply chain question reduces from "trust the vendor cloud's entire dependency tree" to "trust the signed extension binary and the control-plane release artifacts." That is a vastly smaller surface for an EU procurement office to inspect.

None of these are claims that need a contractual promise to hold up. They are properties of the architecture.

What This Means for Buyers Right Now

For a security team in an EU institution, a national agency, a regulated industry, or any organization that procures against EUCS-aligned criteria, the practical implication of the Cloud III award is that browser security RFPs will increasingly look like cloud sovereignty RFPs. The questions will move from "where is the data stored" to "who runs the stack that processes it."

A few questions are worth adding to any enterprise browser security evaluation in this environment:

1. Where does the data plane run? On the customer's infrastructure, or in the vendor's cloud? If the vendor's, in which jurisdiction, under whose operational control, with what extraterritorial exposure?
2. What is the operational sovereignty story? Does the vendor's SRE team hold production credentials to your environment? Are there support tunnels into your perimeter by default?
3. What is the technology sovereignty story? Does the product replace the browser binary itself, or sit on top of an upstream-patched browser? If it replaces, what is the patch latency in practice?
4. What is the supply chain story? How many vendor-controlled components have to be trusted, and how is their integrity verified end to end?
5. Can you score yourself against SEAL? A vendor that cannot translate its architecture into SEAL objectives is a vendor that does not yet realize SEAL is the procurement language now.

The point of the Cloud III award is not that the European Commission is shutting US vendors out of European procurement. It is that the procurement language has shifted from contractual sovereignty to architectural sovereignty, and that products built on cloud-rendered architectures are now competing inside a scoring system that grades them on a property they cannot easily change. That is the structural part.

Surface was built on the other side of that line because we believed, before SEAL existed, that browser data belongs on the customer's perimeter. The framework now happens to grade that decision favorably. If you are running a procurement against EU sovereignty criteria, or any sovereignty criteria modeled on them, get in touch. And if you want the foundational architecture argument first, Why Does Surface Security Exist? and the comparison post on enterprise browsers are the place to start.