In 2026 the sovereignty question has moved past “is your platform European”. The questions that decide a SASE contract now are where your data is processed, where your decryption keys live, and who can legally compel access to either. The EU-US Data Privacy Framework keeps transatlantic flows legal for now, but it sits under active litigation and the US CLOUD Act runs underneath it regardless. This guide turns that into a procurement checklist you can use before signing.
The sovereignty conversations we heard at Cybersec Europe 2026 confirmed how quickly this has become a buying criterion rather than a talking point. What follows is the technical follow-up: the transfer mechanics, the data a SASE platform actually moves, the questions to put to a vendor, and where European regulators currently draw the line.
What changed in EU US data transfer between 2020 and 2026
The legal basis for sending EU personal data to the US has changed three times in six years. Schrems II invalidated Privacy Shield in July 2020. The EU-US Data Privacy Framework (DPF) replaced it as an adequacy decision adopted by the European Commission on 10 July 2023. In mid-2026 the DPF is active but contested, which is the only honest way to describe its status.
The framework survived its first courtroom test on 3 September 2025, when the General Court of the European Union dismissed the annulment action in Latombe v Commission. The court found that the Data Protection Review Court established under US Executive Order 14086, combined with oversight from the Privacy and Civil Liberties Oversight Board, met the adequacy standard at the time the decision was adopted. The judges were explicit that their review covered only the legal and factual context of 2023.
That qualifier matters. Philippe Latombe filed an appeal to the Court of Justice of the European Union on 31 October 2025, and legal analysts expect the CJEU to hear invalidation arguments by the end of 2026 at the earliest. The recurring criticism is structural. The DPF rests on a US Executive Order rather than federal legislation, which means a future US administration could weaken it without Congress. European data exporters are planning around that fragility, not against a settled regime.
The European Data Protection Board reinforced the point in January 2026 with Version 2.0 of its DPF FAQ for European businesses. The updated guidance asks exporters to verify a US recipient’s certification status on the public register before each reliance, to check explicitly that HR data is covered where relevant, and to treat removal from the register as an immediate compliance trigger. Relying on the DPF satisfies Chapter V transfer rules only. The rest of the GDPR, including the Article 5 principles and Article 28 processor terms, still applies in full.
The data a SASE platform actually processes
A SASE platform processes far more than user web traffic. It handles authentication tokens, connection metadata, decryption proxies for inspected TLS sessions, policy configurations, audit logs, and threat telemetry. Each category sits in a different place, carries different sensitivity, and creates a different cross-border exposure. Evaluating transfer risk means mapping all of them, not just the traffic logs.
The distinction that catches buyers out is the split between planes. Traffic is processed at the nearest point of presence for latency, but the logging plane that aggregates metadata and events often operates under entirely different geography. Cisco Umbrella, for example, defaults to storing event data in California, and its documentation notes that administrative audit logs and policy configurations stay in California even when a customer switches the event data warehouse to Europe. A European buyer can regionalise the visible logs and still leave the administrative trail under US jurisdiction.
Decryption keys are the sharpest point. Because roughly 94% of web traffic is now encrypted, inline inspection forces the platform to act as a man-in-the-middle proxy, terminating TLS, reading the cleartext, and re-encrypting onward. To do that transparently the gateway signs counterfeit leaf certificates from an intermediate CA, and those signing keys must sit on the compute nodes doing the work. If those nodes belong to a US-headquartered vendor, a CLOUD Act order could in principle compel production of the signing keys or compel decryption at the proxy. The TLS inspection and decryption key handling question is therefore a sovereignty question, not just a performance one.
| Data category | Where typically stored | Cross-border implication | Buyer question to ask |
|---|---|---|---|
| Authentication and identity tokens | Edge node RAM plus central identity directories, often global cloud | Directory location may sit outside the EU even when traffic does not | Where is our identity and auth data held at rest? |
| Connection metadata (IP, timestamps, ports) | Edge PoPs forwarded to regional or US logging hubs | General Court (Bindl, 2025) confirmed IP transfers trigger Chapter V liability | Where does connection metadata land, and for how long? |
| TLS decryption proxy (cleartext payloads) | Volatile memory at the edge PoP during inspection | Cleartext corporate, medical or financial data exposed in runtime memory | Where are our decryption and intermediate CA keys executed? |
| Policy configurations | Central control plane, frequently vendor HQ | Exposes network topology if compromised, rarely direct PII | Which jurisdiction holds our policy database? |
| Audit logs | Often the vendor home country regardless of data region | Administrative logs are commonly exempt from residency settings | Do audit logs follow the same residency rule as event data? |
| Threat telemetry | Global threat intelligence repositories | Usually pseudonymised, but flagged file uploads can carry PII | Is any raw sample exported outside the EU for sandboxing? |
How the EU US Data Privacy Framework works for SASE vendors in 2026
The DPF requires a US recipient to self-certify with the Department of Commerce, commit to a set of enforceable privacy principles, and submit to Federal Trade Commission jurisdiction. For a SASE buyer the question is narrower than “is the vendor certified”. It is whether the specific legal entity processing your EU data is the certified one, and whether that certification actually covers the services you license.
The register at dataprivacyframework.gov is the authoritative source. As of mid-2026 it lists more than 3,600 certified participants, a majority of them small or mid-sized companies. Certification is not free and renews annually, with fees scaling to corporate revenue. None of that tells you whether your data flow is covered, which is why the EDPB’s January 2026 guidance now expects exporters to check status as a documented, repeatable step in procurement and contract renewal.
The gap that trips up buyers is between corporate certification and data-flow-level coverage. A vendor can hold a valid certification while a sub-processor handling part of your traffic sits outside it. The EDPB has also been specific that HR data needs explicit coverage, either in the certification scope or through a public commitment to cooperate with EU data protection authorities on employee files. Treat the certificate as a starting point, not a conclusion.
There is also a post-removal rule worth knowing. If a vendor is removed from the register, it remains bound to apply DPF principles to data it received during its active period for as long as it retains that data, unless it adopts alternative safeguards or returns the data. That protects historical data but does nothing for new transfers, so an “inactive” or “removed” status means you stop relying on the DPF immediately.
Why the CLOUD Act still matters under the DPF
The US Clarifying Lawful Overseas Use of Data Act, codified at 18 U.S.C. § 2713, lets US authorities compel a provider under US jurisdiction to disclose data in its possession, custody or control, wherever that data physically sits. DPF certification does not block a CLOUD Act order. The two operate on different planes, so a buyer with a US-headquartered SASE vendor keeps CLOUD Act exposure even when every transfer box is ticked.
The trigger is corporate control, not data centre geography. If the vendor is US-headquartered, or a European vendor with a US parent or US subsidiary, the US judiciary asserts authority over data within that corporate group. A point of presence in Frankfurt operated by an American company does not change the analysis. The CLOUD Act does not reach into EU territory directly. It compels a US entity to produce data, and the entity then has to act on its own infrastructure to comply. The distinction is legally real and worth stating precisely, because the practical result for the buyer is the same either way.
This stopped being theoretical in 2025. During a French Senate inquiry on digital sovereignty on 10 June 2025, a Microsoft France executive was asked under oath whether the company could guarantee that data held in its French data centres would never be passed to US authorities without French government consent. The answer was no. He explained that as a US-controlled entity Microsoft is bound to comply with valid CLOUD Act warrants, that such requests do occur, and that neither an EU data boundary nor contractual commitments can neutralise the statute.
Vendors often counter with transparency-report statistics showing zero content disclosures to the US government. AWS, for instance, reports no disclosures of enterprise or government content stored outside the US across recent years. That is a meaningful number, but it covers content. It says nothing about the continuous export of connection metadata, login trails and source IP addresses, which is precisely the category the General Court treated as a Chapter V transfer in the Bindl ruling. Read the statistic for what it measures, not what it implies.
What questions European SASE buyers should ask vendors about cross-border transfer
European SASE buyers should ask seven questions before signing: where identity data is processed, where TLS decryption keys are stored, which legal entity holds the data, who the sub-processors are and where they sit, how CLOUD Act warrants are handled, what the EU customer data flow map looks like, and whether the vendor can provide a transfer impact assessment template. A European-headquartered platform like Jimber, with no US parent, answers most of these by default, which is what makes the evaluation faster.
The point of the list is to move the conversation from marketing claims to documented data flows. Ask each question and request the answer in writing.
- Where is our authentication and identity data processed? Identity directories are commonly global even when traffic is regional. This is where residency claims most often leak.
- Where are the TLS decryption keys for our traffic stored and executed? Intermediate CA and session keys decide whether cleartext inspection happens inside EU jurisdiction or inside a CLOUD Act envelope.
- Which legal entity holds our data, the EU subsidiary or the US parent? Corporate control determines CLOUD Act reach. A European brand owned by a US parent does not resolve it.
- Which sub-processors handle our data, and where are they located? A European vendor running on AWS or GCP inherits a nested transfer risk through the underlying hyperscaler.
- How are CLOUD Act warrants handled, and have any been served in the last 12 months? Ask for the policy and the transparency reporting, including the commitment to challenge orders.
- What is your data flow map for an EU customer on the standard configuration? Defaults matter more than capabilities. A residency option you have to configure is not a residency guarantee.
- Can you provide a transfer impact assessment template ready for our DPIA? Vendor cooperation here is a strong signal of how seriously they treat Chapter V.
For the broader evaluation around these answers, the SASE vendor evaluation framework sets out the seven criteria that matter most for organisations between 50 and 400 users.
The transfer impact assessment that EU DPAs expect in 2026
For any transfer to a non-adequate country, and as a sensible fallback even for DPF-registered vendors, EU data protection authorities expect a documented transfer impact assessment (TIA). The framework comes from EDPB Recommendations 01/2020, Annex 2. The TIA is the controller’s responsibility, which means the SASE buyer owns it, but it cannot be completed without the vendor’s cooperation on data flow disclosure.
The structure is consistent across jurisdictions. Identify the transfer and the data involved. Identify the transfer tool under Article 46, usually the 2021 Standard Contractual Clauses. Assess whether the destination country’s law undermines the contractual guarantees, which for the US means the CLOUD Act and FISA Section 702. Identify supplementary measures that close the gap. Document the outcome and keep it current.
Bare SCCs are not enough on their own. The 2021 clauses adopted under Commission Implementing Decision (EU) 2021/914 remain the only valid version, and legacy 2010 clauses expired at the end of 2022. But signing them without active technical safeguards fails a modern DPA audit. The supplementary measures that satisfy reviewers for a SASE deployment are concrete: TLS 1.3 with forward secrecy, AES-256 encryption at rest with keys held in EU-controlled hardware, pseudonymisation of identifiers at the edge before metadata leaves the country, and selective decryption that exempts banking, healthcare and sensitive SaaS from inspection entirely.
For financial services the bar is higher again. DORA Article 28 requires a register of ICT providers, audit and inspection rights over the vendor’s facilities, controls on sub-processing, and a tested exit strategy. The DORA operational resilience requirements push financial buyers toward cryptographic shredding on exit, where deleting a customer-held key renders any residual data on the vendor’s servers unreadable. That neutralises post-contract discovery risk, which is exactly the kind of measure a TIA is meant to document.
Where Belgian, French, German and Dutch DPAs draw the line
National regulators do not read US transfers the same way, and the divergence matters for any organisation operating across the Benelux and DACH. Some authorities treat any CLOUD Act exposure as an unmitigated high-risk transfer. Others have moved toward a risk-based reading for low-sensitivity, transient data. A multi-jurisdiction buyer has to plan for the strictest regulator in scope, not the most lenient.
The Belgian Data Protection Authority (GBA/APD) has taken a firm line. Its Decision 79/2025 of 13 May 2025, on the bulk transfer of “accidental Americans” banking data to the US under FATCA, found the systematic transfers unlawful for failing proportionality and for not guaranteeing enforceable rights and effective judicial remedies in the US. The authority ordered the transfers brought into compliance or stopped by 24 April 2026. The signal for corporate buyers is that the GBA will order high-risk flows to cease even when national legislation and an international treaty sit behind them.
France’s CNIL has been the most aggressive on residency claims since its 2022 Google Analytics findings. Its position through 2025 and 2026 is unchanged: physical hosting in the EU by a US-controlled provider does not by itself satisfy Chapter V, because the host retains the technical capability to access data under US compulsion. For a SASE platform terminating TLS on US-owned infrastructure, CNIL’s default reading is that a transfer occurs.
Germany’s authorities, coordinated through the DSK, are technical and demanding, advising continuous DPF verification and case-by-case TIAs. State regulators in Baden-Württemberg and Hesse have warned public sector and education bodies against US security software on FISA 702 grounds. A late-2025 German court decision did open a more pragmatic, risk-based path for transient, low-risk data with pseudonymisation in place, which is the clearest sign yet of the split between strict enforcement and evolving judicial interpretation. The Dutch AP, aligned with the government’s sovereignty guidance, expects a full DPIA for public sector cloud and treats CLOUD Act exposure for sensitive citizen data as a structural vulnerability to be neutralised rather than accepted.
Layered on top is NIS2. Belgium transposed the directive in October 2024, with the CyFun verification checkpoint on 18 April 2026. Article 21 makes supply chain security a documented obligation, which means a buyer must map the SASE vendor’s cloud sub-processors as part of NIS2 audit obligations. If decryption keys or metadata route to the US under the CLOUD Act, that becomes an unmitigated supply chain risk under CyFun’s Protect and Identify controls, and it elevates the decision from an IT checklist to board-level liability.
How a Belgian SASE platform like Jimber simplifies the cross-border conversation
A Belgian-headquartered SASE platform removes most of the transfer mechanics from the table by design. Jimber processes EU customer data within the EU in its default configuration, keeps TLS decryption keys inside EU jurisdiction, uses EU-based sub-processors, and has no US parent company. Without a US corporate chain there is no entity for a CLOUD Act warrant to compel, which is the single fact that shortens a transfer impact assessment most.
That changes what the TIA has to prove. Instead of documenting supplementary measures to compensate for a US jurisdictional gap, the assessment records that the gap does not exist for the mechanisms that usually create it: corporate control, key location, and sub-processor jurisdiction. The supplementary measures that DPAs expect, EU-held encryption keys and edge pseudonymisation among them, become architectural defaults rather than negotiated add-ons.
It also maps cleanly onto the compliance frameworks European mid-market teams are already working through. The same EU-only data flow that answers the cross-border question feeds the audit evidence for NIS2 and CyFun, and for financial entities it lines up with the DORA register and exit-strategy requirements. The European SASE vendor selection case, and the broader argument for consolidating onto the Jimber SASE platform, both rest on this overlap between sovereignty and audit-readiness.
None of this makes sovereignty a zero-risk proposition, and claiming otherwise would not survive a serious evaluation. EU jurisdiction lowers a specific set of risks: extraterritorial compulsion, nested hyperscaler exposure, and decryption-key reach. It does not remove the need for strong encryption, sound access control, or a documented TIA. What it does is make those documents shorter and the procurement conversation faster.
Frequently asked questions
Does the EU-US Data Privacy Framework eliminate the need for Standard Contractual Clauses?
Not in practice. The DPF covers certified US recipients, but many buyers keep SCCs as a fallback against a future invalidation and to cover sub-processors outside the certification. Given the pending CJEU appeal, SCCs plus supplementary measures remain a prudent second layer in 2026.
Can a US-headquartered SASE vendor with EU data centres avoid CLOUD Act exposure?
No. The CLOUD Act follows corporate control, not data centre location. A US-headquartered vendor, or a European subsidiary of a US parent, can be compelled to produce data it controls regardless of where the servers physically sit. EU points of presence do not resolve this.
What is a transfer impact assessment and is it mandatory for SASE platforms?
A transfer impact assessment documents whether a destination country’s laws undermine GDPR protections for a given transfer, following EDPB Recommendations 01/2020. For SASE deployments involving non-adequate transfers it is effectively mandatory, since DPAs expect it on audit and it is the controller’s responsibility to produce.
Where does a SASE platform store TLS decryption keys?
On the compute nodes that perform inline inspection. The intermediate CA and session keys must sit where decryption happens, so for a US-headquartered vendor those keys fall under US jurisdiction. Buyers should require EU-held keys in EU-controlled hardware security modules.
Are Standard Contractual Clauses still valid in 2026?
Yes. The 2021 SCCs under Commission Implementing Decision (EU) 2021/914 are the current valid version. Legacy 2010 clauses expired in December 2022. SCCs alone are insufficient without documented technical supplementary measures such as TLS 1.3 forward secrecy and edge pseudonymisation.
Does NIS2 require EU data localisation?
NIS2 does not mandate data localisation outright, but Article 21 requires supply chain security assessment. In Belgium, CyFun verification expects you to map vendor sub-processors and treat US jurisdictional exposure on critical security data as a documented risk, which pushes many essential entities toward EU processing.
What is the EDPB position on supplementary measures for SASE transfers?
The EDPB’s Recommendations 01/2020 require case-by-case supplementary measures where third-country law undermines SCC guarantees. Its January 2026 DPF guidance adds continuous register verification. For SASE specifically, the expected measures are strong in-transit encryption, EU-held keys, and pseudonymisation of identifiers before cross-border logging.
For European mid-market IT teams running a transfer impact assessment in 2026, the conversation goes faster with a vendor that processes data in the EU by default and has no US parent. Book a 30-minute walkthrough to see how Jimber maps to your specific data flow requirements.
