For years, the world operated on a simple assumption: data has a physical place of residence. If it was stored on a server in Dublin, it fell under Irish and European law. That assumption collapsed in 2018, when the United States enacted the CLOUD Act — a law that grants American authorities access to data controlled by US companies, regardless of where that data is physically stored in the world. Several years later, Brussels responded with its own protective framework: the Data Act, now fully applicable, which attempts to limit the extraterritorial access of third-country authorities to data held within the European Union.
Here is what these two texts actually provide, where they collide, and why the only truly robust protection against this conflict remains technical impossibility of access.
The American CLOUD Act: access based on control, not location
The CLOUD Act (Clarifying Lawful Overseas Use of Data Act), enacted in March 2018, amended US law by adding 18 U.S. Code § 2713. This provision requires any provider of electronic communication services or remote computing services to preserve, back up, or disclose the contents of a communication or any record pertaining to it, whenever that data is in the provider’s possession, custody, or control, regardless of whether the data is located inside or outside the United States.
It is precisely this final clause that changes everything. The criterion is no longer the physical location of the server, but the control exercised by the parent company over its subsidiaries. A US company operating data centres in Europe therefore remains subject to American legal demands, even for data stored entirely on European soil.
The European Data Act: a legal barrier to extraterritorial access
Regulation (EU) 2023/2854, known as the Data Act, entered into force on 11 January 2024 and has been fully applicable since 12 September 2025, with certain provisions phased in through 2026 and 2027. Its Article 32 directly addresses the question of international governmental access to data.
The text establishes a clear rule: any decision or judgment of a court or administrative authority of a third country requiring a data processing service provider to transfer or give access to non-personal data held in the European Union is recognised and enforceable only if it is based on an international agreement, such as a mutual legal assistance treaty (MLAT), in force between the requesting country and the Union, or between that country and the relevant Member State.
In the absence of such an agreement, Article 32 provides a second avenue, but one that is strictly circumscribed: the foreign decision may only be enforced if the legal system of the third country requires that the request be reasoned, proportionate, and sufficiently specific — for example, by establishing a clear link to specific individuals or offences — and if the recipient’s reasoned objection can be submitted to the review of a competent court in that third country.
A direct legal collision
The problem is immediate: the CLOUD Act requires disclosure based on the control exercised by the parent company, without a proportionality requirement comparable to that demanded by European law. The Data Act, conversely, conditions recognition of such a request on the existence of an international agreement or specific procedural safeguards. A US company operating in Europe, ordered by an American authority to hand over data hosted within the Union, thus finds itself caught between two contradictory legal obligations: comply with the American mandate and violate Union law, or respect the Data Act and face the consequences of refusal in the United States.
This tension is not theoretical. It has already been documented by the Court of Justice of the European Union (CJEU) in two landmark rulings, Schrems I (2015) and Schrems II (2020). In the Schrems II judgment, the CJEU held that American surveillance conducted under Section 702 of FISA (Foreign Intelligence Surveillance Act) and Executive Order 12333 does not respect the minimum safeguards required by Union law under the principle of proportionality, and therefore cannot be regarded as limited to what is strictly necessary. The Court also noted the absence of an effective judicial remedy for Union data subjects, in violation of Article 47 of the Charter of Fundamental Rights. This ruling invalidated the Privacy Shield framework, which had until then governed data transfers between the EU and the United States.
The structural risk: Harvest Now, Decrypt Later
Beyond the jurisdictional conflict, a more insidious threat looms over data hosted in infrastructures subject to US law: the so-called Harvest Now, Decrypt Later (HNDL) strategy. The principle involves an intelligence service or hostile state actor intercepting and storing encrypted data today, in anticipation of sufficient quantum computing capabilities to decrypt it in the future.
This strategy transforms any prolonged dependence on American cloud infrastructure into a deferred security liability: what is confidential today may become readable in ten or fifteen years, without any further action required on the part of the attacker — only time and patience.
Why only technical impossibility constitutes a genuine guarantee
Legal analysis converges on a finding shared by many compliance experts: however solid the Data Act’s legal framework may be, it remains a text that geopolitical power dynamics and diplomatic pressures can circumvent, delay, or reinterpret. The only protection that depends on no future negotiation is technical impossibility of enforcement.
A zero knowledge architecture, in which the service provider never holds possession or custody of the decryption keys, renders a legal demand materially inoperable. One cannot be compelled to hand over what one never possesses.
This is the logic that underpins ecosystems such as Arpokrat:
- Jurisdictional neutralisation: the infrastructure is hosted in Switzerland, under the Swiss Federal Act on Data Protection (FADP/LPD), outside the direct scope of the CLOUD Act’s extraterritoriality
- No custody: the zero knowledge architecture deprives the service provider of any ability to hand over keys or content it never holds
- Reduced identity footprint: by eliminating the requirement to register with a phone number or email address — identifiers that FISA Section 702-based surveillance can easily track — the user ceases to be an identifiable subscriber and becomes an anonymous cryptographic key
The chain of custody does not stop at message encryption
A point often underestimated in compliance analyses: encrypting the content of a communication is not enough if the underlying operating system — whether Android or iOS — continues to capture metadata or kernel-level telemetry destined for servers under US jurisdiction. Protecting confidentiality requires a complete closure of the chain of custody, from content all the way down to the hardware infrastructure itself.
This is why digital sovereignty also requires reflection on the operating system in use, not just on messaging applications. De-Googled systems, in which modules such as Bluetooth or GNSS geolocation can be disabled directly at the kernel level, eliminate physical attack vectors that no application-layer encryption can compensate for.
Post-quantum cryptography: an already-engaged horizon
In the face of the threat posed by the HNDL strategy, adopting post-quantum cryptography (PQC) standards becomes a necessity for anyone wishing to guarantee the confidentiality of sensitive data over the long term — whether that involves trade secrets, professional correspondence, or health data. Encryption considered robust today under classical standards does not guarantee that it will withstand the quantum computing capabilities expected within the next fifteen years.
The conflict between the Data Act and the CLOUD Act illustrates a broader reality: digital sovereignty can no longer be built on legislation alone, however solid that legislation may be. It requires closing the chain of custody at every level — from the encryption protocol to the hosting jurisdiction, and including the operating system itself. It is this layered approach, rather than trust placed in a single regulatory framework, that defines genuine digital sovereignty by design today.