Your SaaS application serves customers in Europe. Its authentication provider offers an EU region, so you choose Frankfurt. Does that mean your users' identity data is beyond the reach of US authorities? And could a US government decision ever interrupt your login service?
The honest answer is that data location matters, but it answers only one part of the question. Where information is stored, who controls it, who can read it, and who can keep the service running are different things. For authentication, the distinction is especially important: the system may hold email addresses, account records, session information, login events, and authentication credentials. If it becomes unavailable, users may be locked out of the application itself.
Here is the short version:
The US Stored Communications Act sets out legal processes for obtaining data from covered communications and computing service providers. In 2018, the CLOUD Act clarified that a provider must comply with a valid order for data in its possession, custody, or control regardless of whether that data is located inside or outside the United States.
That does not mean a government official can browse a provider's databases at will. The type of data requested matters, and lawful demands have procedural requirements and potential avenues for challenge. It does mean that choosing a server in Frankfurt is not, by itself, a legal answer to a US order directed at a provider that controls the data.
The well-known Microsoft Ireland case illustrates the issue. Microsoft challenged a US warrant for emails stored in Dublin, and a US appeals court initially agreed with Microsoft. Congress then enacted the CLOUD Act, the government obtained a new warrant, and the US Supreme Court dismissed the original dispute as moot. The Supreme Court did not decide that US law generally overrides EU law. The case shows why a data center's address does not settle who can be compelled to produce data. US Supreme Court, United States v. Microsoft (2018)
There is also a practical difference between an order for data and access to readable content. A provider cannot hand over a private key it never had. But many cloud and SaaS systems need access to data while serving requests. Encryption at rest does not prevent ordinary processing from making plaintext available. Metadata, account details, and operational logs can remain available even where selected content is encrypted on the client.
For perspective, AWS states that, since it began tracking this category in 2020, it has received no government requests resulting in the disclosure of enterprise or government customer content stored outside the US to the US government. This is AWS's reported figure for a specific category, not proof that every form of request or future risk is absent. It is useful context when assessing likelihood alongside legal possibility.
The CLOUD Act discussion usually concerns disclosure orders in criminal investigations. Section 702 of the Foreign Intelligence Surveillance Act (FISA) concerns foreign intelligence collection. Under its statutory conditions, it allows compelled assistance from covered US electronic communications service providers in targeting non-US persons reasonably believed to be outside the US and relevant to specified foreign intelligence purposes. It does not follow that every dataset at every US-headquartered cloud company is automatically accessible under Section 702. US Intelligence Community explanation of targeting
European data protection law raises another question: may the requested data be transferred to a foreign authority? According to the European Data Protection Board's guidelines on Article 48 GDPR, a third-country order is not automatically recognized or enforceable in the EU. A disclosure of personal data still needs an applicable GDPR basis and must satisfy the rules on international transfers. The GDPR does not ban every disclosure to a foreign authority, either. A real conflict can arise when an entity faces an obligation under US law and cannot establish a lawful route for the same disclosure under EU law. There is no simple, universal rule saying one law always wins.
The French Health Data Hub dispute makes this less abstract. The project used Microsoft technology for sensitive health data hosted in Europe. In 2020, France's Conseil d'État held that the possibility of a US authority seeking access could not be entirely ruled out and called for additional safeguards; it did not immediately stop the processing. In a March 2026 decision, the court upheld a particular authorization with protections including pseudonymization and limited retention. That authorization did not permit transferring the health data studied to the US. Neither decision resolved a specific US demand for those records or declared that all EU use of US technology is lawful or unlawful. Conseil d'État, 2020
Schrems II and the EU–US Data Privacy Framework (DPF) are related, but distinct. In Schrems II, the EU Court of Justice invalidated the former Privacy Shield adequacy decision in light of the level of protection for EU–US transfers, while leaving standard contractual clauses available subject to appropriate assessment. The current DPF adequacy decision provides a transfer route for certified US organizations. It does not repeal the CLOUD Act or FISA. Court of Justice, Schrems II
This is a sanctions and service-continuity question, not a CLOUD Act question. US sanctions or export controls can restrict a US company from supplying particular services to designated persons, organizations, or locations. GitHub reported that sanctions had limited the availability of its services in several places; it later obtained a license enabling full service to developers in Iran. The US Treasury restricted certain IT support and cloud-based software services for recipients in Russia in 2024, subject to defined scope and exceptions.
These examples do not show that EU companies are about to be cut off. They do show that political and legal decisions can affect a provider's ability to serve specific customers. An EU-hosted workload may still depend on a global account system, a control plane, updates, billing, DNS, or an external identity provider. Encryption cannot keep a login endpoint available when its underlying service is unavailable.
“Sovereign cloud” describes several different approaches. Some add residency and access controls to an existing global public cloud. Others separate operations and infrastructure under EU entities or local partners. They should be assessed by their actual legal and technical boundaries, not by the word sovereign.
These structures can materially reduce access paths and strengthen operational autonomy. Oracle, for example, argues that its separate EU sovereign cloud means a US Oracle entity should not have possession, custody, or control of its tenant data. That is the provider's legal position, not a blanket court ruling covering every future order. Whether an order reaches a particular entity and dataset depends on the actual structure and facts.
A sovereign cloud therefore cannot, merely by its name, guarantee that the CLOUD Act is inapplicable. Nor does it automatically make the data end-to-end encrypted.
The key question is where and when plaintext exists.
The European Data Protection Board's guidance on supplementary measures likewise distinguishes effectively encrypted data from cloud processing that requires provider access to plaintext. For an authentication service, genuine end-to-end encryption of all operational data would be an implausible promise: the service has to process identity and session information to perform logins. A passkey's private key and device biometric data are different: they are not sent to the authentication server in the first place. The server still needs account information and public credential data. Hanko Cloud DPA, technical measures
For customer-facing SaaS and mobile applications, the useful question is not “Is this cloud European?” but which control do we need over which risk?
There is no universal reason for every EU startup to avoid AWS or another US service. But an EU region should not be treated as a complete answer when contracts require European operational control, the data is especially sensitive, or the application cannot tolerate a provider-level disruption.
We build open-source authentication for web and mobile apps. Today, Hanko Cloud uses AWS infrastructure in Germany. We have been very satisfied with AWS and have had no reason to believe that our data is unsafe there. Our data processing agreement sets out our current commitments on data location, access, subprocessors, and export.
At the same time, the questions in this article are real for us and for customers in the EU. As a German company, we have decided to move our production infrastructure to an EU cloud provider in the near term. Our aim is to bring the hosting and operational chain for Hanko Cloud more fully under European control, so that our German legal entity, data-protection commitments, and infrastructure choices reinforce one another. We will share the provider and migration details when the plan is ready. The move is about reducing a specific jurisdictional and operational dependency; it is not a claim that moving servers alone creates end-to-end encryption or makes government access impossible.
For international customers, the Hanko product, APIs, and integrations are intended to work as they do today. We will manage the infrastructure transition and communicate any changes relevant to customers. Longer term, we want to offer additional selectable data locations, potentially including the United States, so customers can choose the location that fits their users, contracts, and regulatory needs. That would be a customer choice, not a silent move of existing EU projects.
Customers who need to choose and operate their own infrastructure can self-host Hanko. Hanko Cloud customers can request a complete export to support migration to a self-hosted deployment. Self-hosting only changes the jurisdictional risk when the chosen infrastructure and other dependencies change with it.
The principle we are working toward is straightforward: make the trade-offs visible, give teams real deployment choices, and let them decide how much control they need over their users' identities and access to their applications.
Magic links and email passcodes both promise passwordless login with low friction. But once you look at cross-device sign-in, browser behavior, email
Why we’re moving Hanko from a Kubernetes-native single-tenant setup to a multi-tenant architecture and what “cloud native” got wrong for a small team.
"Zombie passkeys" – passkeys that exist in a limbo state between client devices and authentication servers.