On the 27th of April this year, SAP and S3NS issued a joint press release announcing that Thales would run SAP RISE Private Cloud Edition on the S3NS PREMI3NS platform, with commercial availability targeted for H2 2026. Thales is described, in proper press-release voice, as the “first strategic customer.” The Trusted Cloud™ branding does a lot of work in that sentence, so it’s worth pulling it apart before anyone in EU financial services treats this as a validated production architecture. It isn’t one yet. It’s an intent-to-deploy that signals the pattern’s commercial viability, on a platform whose sovereignty rating is one notch lower than the four providers the European Commission picked for its own procurement ten days earlier.
If you run or audit SAP estates inside the EU, the announcement is useful as a market-direction signal. SAP RISE (SAP’s transformation-as-a-service offering) on a SecNumCloud-qualified substrate is no longer slide-ware. ANSSI (Agence nationale de la sécurité des systèmes d’information, the French cybersecurity agency) has stamped the substrate, and a major regulated buyer has committed. The bits that matter for your DORA (Digital Operational Resilience Act) register and your CSF (the EU Commission’s Cloud Sovereignty Framework) posture, though, are exactly the bits the press release works hardest to gloss past.
What the deal actually is
S3NS is a Société par Actions Simplifiée incorporated under French law, fully controlled by Thales, with Google Cloud holding a minority shareholding (reportedly around 20%, consistent with SecNumCloud’s sub-25% individual non-EU equity ceiling, though the exact cap-table figure is not in primary public records). The PREMI3NS platform runs on Google Cloud technology (Compute Engine, GKE, BigQuery, Cloud Storage, Cloud SQL) operated exclusively by S3NS personnel inside French data centres, with what S3NS describes as “limited, supervised assistance from Google, without system access”. ANSSI granted SecNumCloud version 3.2 qualification on the 17th of December 2025, covering IaaS, container, and PaaS layers in a single decision. SecNumCloud is the ANSSI qualification that the French “Cloud de Confiance” doctrine treats as the technical floor for hosting sensitive public-sector and regulated-industry data.
The SAP layer is RISE Private Cloud Edition, the managed S/4HANA bundle including SAP Business Technology Platform entitlements, lifecycle tooling, and SAP-operated infrastructure. Under RISE, the customer signs one contract, with SAP. SAP picks the substrate, runs the platform through SAP Enterprise Cloud Services, and accepts SLA accountability. In the S3NS variant, the substrate is PREMI3NS instead of an AWS or Azure region, and the operational layer is Thales-employed engineers operating Google-licensed technology under French jurisdiction. The press release describes the Thales engagement as “a transformational refoundation of [Thales’s] SAP ERP landscape” unifying finance, supply chain, manufacturing and procurement on PREMI3NS, but no contract value, user count, or migration timeline has been disclosed in primary or secondary sources at time of writing.
The SEAL-2 ceiling, in plain terms
Ten days before the Thales news, on the 17th of April this year, the European Commission published the result of its sovereign cloud procurement. The Commission applied its new SEAL (Sovereignty Effectiveness Assurance Levels) framework to the bidders. STACKIT, the Post Telecom-led partnership (with OVHcloud and CleverCloud), and Scaleway hit SEAL-3 (Digital Resilience). The Proximus-led consortium, which is the bid vehicle that includes S3NS, was placed at SEAL-2 (Data Sovereignty).
The difference is not cosmetic. SEAL-2 means the provider’s data and operations are protected under EU law without requiring extra customer effort. SEAL-3 adds something specific: immunity from supply-chain disruption originating outside the EU. The supply-chain dimension carries the highest weight (20%) in the framework’s eight-objective scoring, and it is exactly where S3NS’s Google technology dependency creates a structural ceiling. If Google discontinued the licence, refused updates, or tore up the partnership, S3NS could not simply fork the stack and keep going. There is no independent re-implementation of the GCP API surface running anywhere. The Commission’s own framing said it cleanly: “Proximus leverages capacities of partners S3NS, Clarence and Mistral from a technical environment based on Google Cloud technology, exclusively operated by EU companies.” Operated by EU companies, technology supplied by a US one. That is precisely the SEAL-2 shape.
SecNumCloud 3.2 and SEAL measure overlapping but different things. SecNumCloud certifies operation under EU law, data and operations inside French jurisdiction, and operational-level immunity from extraterritorial compelled access. SEAL adds the industrial-policy lens: who built the technology, and how exposed are you if that supplier walks away. ANSSI itself has been blunt that SecNumCloud is a cybersecurity qualification, not an industrial-sovereignty certificate. CISPE (Cloud Infrastructure Services Providers in Europe), the trade body for around 38 EU cloud providers, called recognising S3NS as sovereign “clearly an own goal” that “threatens to institutionalize sovereignty washing” (Francisco Mingorance, CISPE Secretary General, as quoted in The Register’s coverage of the tender). Both views can be correct at once, which is the whole problem.
SecNumCloud says the provider can host sensitive data under French law without giving Washington a back door. SEAL-3 asks a harder question: would the provider survive if Washington asked the technology vendor to leave?
What S3NS actually does to mitigate the Google dependency
The mitigation architecture is genuinely interesting, and it is the reason ANSSI granted the qualification at all. Three pieces matter.
First, operational isolation. PREMI3NS production is operated only by S3NS employees. Google personnel have no access. ANSSI audited and confirmed this, and it is the precondition for the qualification.
Second, the quarantine zone. Every Google technology update gets intercepted before reaching production, redirected into an isolated environment with no customer data, and analysed by S3NS through automated reverse-engineering of each binary. Behavioural delta vs. the prior version is checked. Only post-validation updates are deployed. Reported cadence: roughly five million components per year (per Victor Vuillard, S3NS Technical and Security Director, in Thales Group’s December 2025 explainer). It is a real and underappreciated piece of engineering. No other Google-JV cloud has publicly disclosed equivalent depth.
Third, source code access and key management. S3NS holds source-code access to the Google technology for independent audit. Customer encryption keys can be held outside Google’s control entirely via Cloud External Key Manager, with CRYPT3NS as a customer-controlled HSM-backed product on top.
What none of this does is dissolve the supply-chain dependency. Google still sits at the bottom of the stack as the technology supplier and as a roughly 20% shareholder. ANSSI decided the operational and contractual controls are sufficient for SecNumCloud immunity from extraterritorial compelled access. The Commission, applying a heavier supply-chain weight, decided the same dependency caps the SEAL band at 2. Both can be right because they are answering different questions.
The DORA wrinkle that the press release does not mention
On the 18th of November 2025, the Joint Oversight Committee of the three European Supervisory Authorities (EBA, the European Banking Authority; EIOPA, the European Insurance and Occupational Pensions Authority; and ESMA, the European Securities and Markets Authority) published the first list of nineteen CTPPs (Critical ICT Third-Party Providers) under DORA. SAP was designated, with the EBA as lead overseer. Google Cloud EMEA Limited (with its Google Cloud France, Italy and Poland subsidiaries) was designated on the same list, also under EBA oversight.
For a financial entity running SAP RISE on S3NS, that creates a compound exposure: SAP at the application layer, Google Cloud at the technology supply layer through PREMI3NS. Both have been judged systemically critical. Both come with the heightened oversight regime DORA attaches to CTPP status (designation under Article 31, ESA oversight provisions in Articles 31–44), and both belong in your Article 28(3) Register of Information.
The harder question, which published EBA/EIOPA/ESMA guidance does not yet answer, is whether Google’s CTPP designation formally extends to the S3NS-mediated substrate. The argument for extension: PREMI3NS runs on GCP-compatible technology licensed from Google. If the supervisor cares about technology continuity, the licence is the choke point. The argument against: S3NS is a French-law entity, operates the infrastructure with its own personnel, and is not Google Cloud. There is no EBA/EIOPA/ESMA Q&A on this. It is the kind of question the management body member you have designated to oversee ICT third-party risk under DORA (the governance duty flowing from Articles 5 and 28) should escalate to your competent authority rather than guess at, and worth raising during your next ICT third-party concentration risk review.
The Article 30 contracting question is similarly load-bearing. The DORA mandatory clauses (full SLA, audit rights, exit terms, sub-outsourcing transparency, business continuity obligations) need to chain through SAP’s contract down to the S3NS layer and, in turn, to the Google technology licence. How SAP’s sovereign cloud contract template accommodates audit rights over the PREMI3NS layer is not yet visible in public documentation. Anyone signing a RISE-on-S3NS deal in 2026 should treat that as a contract-negotiation work item, not an assumed default.
How this stacks up against the alternatives
For a French financial entity that needs an S/4HANA platform, three architectures are realistic in 2026.
SAP RISE on S3NS gives you SecNumCloud-qualified managed ERP, single contract, SAP-operated infrastructure on a Thales-operated Google substrate. SEAL-2, Cloud de Confiance compliant. CTPP exposure: SAP plus Google Cloud (open question on extension). Best fit when you want SAP to own operations and you can live with the SEAL-2 ceiling for the regulatory boxes you actually need to tick.
SAP RISE on Bleu is the same pattern on a different substrate (Microsoft Azure technology, operated by the Capgemini/Orange joint venture). SAP announced it on the 19th of March this year, originally targeting Q2 2026; commercial availability has since slipped to H2 2026 in line with Bleu’s own qualification timeline. Bleu is in-progress for SecNumCloud: the J0 milestone passed on the 17th of April 2025 and the J1 (evaluation strategy) milestone passed on the 17th of November 2025. The technical and operational audits that constitute J2 are now under way. Final qualification has not been issued at time of writing. Once qualified, the structural picture mirrors S3NS: non-EU technology under EU operational control, almost certainly SEAL-2.
SAP S/4HANA self-managed on OVHcloud Bare Metal Pod is the SEAL-3 path. OVHcloud’s Bare Metal Pod received SecNumCloud 3.2 on the 31st of March 2025, on a pure EU technology stack, and the Commission placed OVHcloud at SEAL-3 inside the Post Telecom-led consortium. The trade-off: no RISE bundle, so you license SAP separately, run BASIS in-house (or with a partner), and own operations. You drop one CTPP entirely (no Google Cloud dependency); SAP CTPP exposure remains. Best fit when you have the SAP operations capacity and you actively want SEAL-3 supply-chain immunity.
A self-managed deployment on Scaleway or STACKIT is technically possible. Scaleway’s public cloud SecNumCloud qualification is still in-progress: the J0 milestone was announced on the 9th of January 2025 with an end-2025 target that has since slipped, and Scaleway still appears in the “in qualification” section of the ANSSI register at time of writing. STACKIT has no SecNumCloud (it operates under German law instead) but reached SEAL-3 in the Commission’s tender. Worth tracking, not yet a default for a French regulated buyer.
A scenario to make this concrete
Take a Dutch insurer running an S/4HANA estate on Microsoft Azure, with a French subsidiary subject to ACPR (the French prudential supervisor) under DORA. The board wants to move sensitive workloads to a sovereign substrate before NIS2 (the EU’s revised network and information security directive) is finalised in France. The French transposition has missed its H1 2026 window and is now expected over the summer of 2026, with continued risk of further slippage.
If the priority is “fewest internal changes, most regulatory upside,” RISE on S3NS gets you SecNumCloud and Cloud de Confiance compliance with SAP still on the hook for operations. You accept SEAL-2 and the compound CTPP question. If the priority is “highest sovereignty grade, lowest non-EU dependency,” self-managed on OVHcloud Bare Metal Pod gets you SEAL-3 and removes the Google supply-chain link, at the cost of in-house BASIS capacity and a broken-out SAP licensing deal. If the priority is “wait for the dust to settle,” waiting on Bleu’s J2 audits and final J3 decision is reasonable. Bleu has cleared J0 and J1, and the public timeline points at H2 2026 for both qualification and SAP RISE general availability on the platform; the structural assumption is that Bleu will land in the same SEAL-2 zone as S3NS but with Microsoft instead of Google upstream. There is no clean winner. There is a position you have to take and document for your supervisor.
SEAL mapping, in one paragraph
SAP RISE on S3NS targets SEAL-2 (Data Sovereignty) in the Commission’s framework, with SecNumCloud 3.2 qualification on the substrate and Cloud de Confiance compliance for French public-sector and regulated-industry use. SAP RISE on Bleu, once qualified, almost certainly lands in the same SEAL-2 band. Self-managed S/4HANA on OVHcloud Bare Metal Pod is the SEAL-3 option in the French market today. STACKIT and Scaleway can reach SEAL-3 too, with caveats on jurisdiction (STACKIT is German, not French) and qualification scope (Scaleway public cloud is still in-progress).
What to do this quarter
A short, deliberately unglamorous checklist:
- If you are running or scoping SAP on a US hyperscaler, add a row to your DORA Register of Information for SAP SE as a designated CTPP and one for Google Cloud or Microsoft as the substrate CTPP. The CTPP rows trigger Article 30 contract-clause obligations whether or not you migrate.
- Before assuming RISE-on-S3NS is your sovereignty answer, write down the specific regulation or doctrine forcing the move (Cloud de Confiance? DORA concentration risk? Internal board mandate?). The answer determines whether SEAL-2 is enough or whether SEAL-3 is the real target.
- If you are actively negotiating a RISE-on-S3NS contract, get the audit-rights chain in writing: customer to SAP, SAP to S3NS, S3NS to Google for the technology supply layer. Do not accept “managed by SAP, trust us” for Article 30 audit rights.
- Escalate the Google-CTPP-extension question to your competent authority (ACPR, DNB, BaFin, or whoever supervises you) under DORA’s management-body governance duties (Article 5 and the Article 28 framework) before signing. Their answer is the one that matters, not the press release.
- If you are an SAP shop with the BASIS capacity to operate self-managed, run a parallel architecture estimate for OVHcloud Bare Metal Pod. The SEAL-3 delta is structural, not cosmetic.
The Thales reference deal is genuinely the most important sovereign-cloud-ERP data point in France this year. It also isn’t the architecture’s coronation. It is the first signal that SecNumCloud-grade managed SAP is commercially real, alongside an open invitation to look hard at what “trusted” means in your specific regulatory situation.