In the UK, giant cloud providers – Amazon Web Services (AWS), Google Cloud and Microsoft – run the systems we depend on for vital functionality in the public and private sectors.
In the public sector alone, US hyperscale cloud providers have near-universal penetration and account for the bulk of technology spending.
In the financial year 2023/2024, 95% of central and local public sector organisations in the UK spent budget on hyperscale cloud services across more than 1,100 public sector bodies, including government departments, councils, police forces and NHS organisations, according to data that comes from analyst Tussell.
This begs the question, if the UK’s key national infrastructure is run by foreign-owned companies, is the data of UK citizens secure should a court in the US compel a hyperscaler to provide it? Here lies the nub of data sovereignty.
In this article, we provide a definition of data sovereignty, the ways it may be undermined from overseas – particularly by the US Cloud Act and FISA Section 702 – drill down into the detail of differing states of encryption and what they mean for security and sovereignty, and look at the inherently cross-border nature of cloud services and its impact on data sovereignty.
Core to the article are questions we asked the hyperscalers that aimed to get at exactly how their services could be described as providing data sovereignty.
These included how they could technically prevent US court-compelled snooping, the protection afforded by encryption, especially during processing, and how court-compelled backdoors might be injected into infrastructure updates. We also asked to what extent it is possible to offer a sovereign UK cloud region and whether standard cloud terms conflict with data sovereignty.
The results illustrate the paradox that lies at the heart of cloud services and data sovereignty.
Defining data sovereignty
We live in a land where the government can’t define data sovereignty. We asked the UK Department for Science, Innovation and Technology (DSIT) in February about its progress towards a definition of data sovereignty, but it couldn’t give one or say when it would have one.
But we can work out a definition.
The idea of sovereignty as applied to states means the solely held power to govern or control a country.
For example, if country A invades country B and establishes control over a swathe of land, where country B’s armed forces, police, and so on, no longer have any authority, then it can be said that country B no longer has sovereignty in the portion of its territory so affected.
We can form a definition of data sovereignty based on the same principle.
So, if a company headquartered in country A provides technology services in country B, and can effect access to data of citizens of that country, then country B cannot say the data of its citizens is sovereign.
Country B may have laws that protect the data of its citizens. But if the country in which the tech company is headquartered has the ability to compel it to provide data held in its systems in another country, then those two sets of laws conflict. Or more to the point, the laws of country B are undermined, and are not sovereign.
It’s a parallel to where a country has laws that govern its citizens, but the presence of foreign armed forces and the rules they impose nullify its writ.
The Cloud Act and FISA Section 702
A good example of a law that compels companies headquartered within its jurisdiction to hand over data they possess is the US Cloud Act, passed into law during US President Donald Trump’s first term.
Cloud here stands for Clarifying Lawful Overseas Use of Data. It was enacted in 2018 after Microsoft refused to hand over customer data held in a datacentre in Ireland, and it was determined that the US Department of Justice could not use domestic warrants to seize data held overseas.
The Cloud Act compels US companies to provide to US law enforcement data in their “possession, custody, or control” even if overseas.
At the same time, a US court can issue a non-disclosure order alongside any order under the Cloud Act. That’s basically a gag order that prohibits a company from telling the data subject that their information has been requested or handed over.
There are ways a company subject to a Cloud Act order can challenge the court. These include a challenge on grounds of “comity”, in which the user in question is not a US person and that disclosure would violate the laws of a “qualifying foreign country”, namely one that has a bilateral agreement with the US, like the UK or Australia.
Also, the Cloud Act is considered to be “encryption neutral”, so companies can be compelled to hand over what they have, but it does not compel them to break their own encryption if they do not already have the keys.
Having said all that, US government agencies have other laws in their toolbox.
Namely, the Foreign Intelligence Surveillance Act (FISA) Section 702, which is up for an imminent vote to re-authorise it. Using this, the US government can compel a service provider to provide “technical assistance” to facilitate a search, with no protection for foreign citizens who are targeted by provisions under the act.
The European Court of Justice (ECJ) has twice struck down data-sharing agreements between the US and EU (Schrems I and Schrems II) because FISA Section 702 does not provide equivalent protection to EU citizens.
Such “technical assistance” could take the form of compiled code in a software update that enabled the exfiltration of data.
Does encryption protect citizen data?
When we get to the responses of the hyperscalers to questions about data sovereignty, we will see an appeal to the fact that data in their systems is encrypted and that only customers hold the keys.
We have also seen that the US Cloud Act does not compel a court-ordered company to hand over encryption keys, although FISA 702 can compel “technical assistance” to gain access to data.
Here, it is important to drill down into encryption.
Firstly, to say that for most data for most of the time, encryption is as good a protection as you can get. Current encryption standards dictate algorithms that are practically impenetrable.
So, if you apply, for example, AES-256 to data-at-rest or data-in-transit, it cannot be read.
The fly in the ointment comes when data is being processed. It’s also a problem for companies that argue that the data they hold is secure because it is encrypted.
The problem is that – generally speaking – data-in-use must be unencrypted to be processed. And so, in theory, a foreign law enforcement agency that wanted to access data in a cloud system overseas could order data to be collected during processing.
Memory scraping, in which malware scans active memory to steal unencrypted data, is possible, for example.
It’s true that most data-in-use is unencrypted, although cloud providers do offer so-called confidential computing of some sort.
For example, a trusted execution environment (TEE) in so-called confidential computing creates a hardware-encrypted “black box” inside the central processing unit (CPU), which means an unauthorised intruder cannot see inside it while data is being processed.
TEEs are breakable, however. It is possible to “listen” to the CPU and measure power consumption or tiny timing fluctuations to guess the data being processed.
Fully homomorphic encryption (FHE) is the Holy Grail, however, because it allows for computation without decrypting data. But that also means it is computationally expensive and isn’t commonplace.
Air gaps, updates and follow-the-sun
Hyperscaler clouds are an international web of regions and availability zones. They comprise a global operating system, almost entirely managed by artificial intelligence (AI) and orchestrated automation.
Cloud networks are made up of regions and availability zones (AZs). Regions are geographically separate – and thus upon them rests the claim of sovereignty by the cloud providers – while AZs are datacentres within a region. AZs within a region are connected by high-bandwidth connections, whereas regions are all interconnected but not by the same low-latency connections.
Clouds run on software-defined everything, with every component represented as code, where faults can be monitored and workloads shifted to a different location should issues be detected, and with rolling updates on a non-disruptive zone-by-zone basis.
Follow-the-sun in support terms is when support teams hand off responsibility to teams elsewhere in the world to benefit from more convenient (ie, less costly) working hours than the region in question.
Follow-the-sun in workload terms means the movement of workloads across the globe to take advantage of lower energy costs or cooler ambient temperatures.
In both cases, there is potentially a risk to sovereignty, by dint of where data resides at any given time and the jurisdiction under which support staff may operate, although customers can specify that data permanently resides in a given region.
If you sign a standard business or enterprise support contract with a hyperscaler, you are opting in to follow-the-sun by default. A standard agreement usually means you agree to terms that allow the provider to support your account from any global location to meet 24/7 uptime guarantees.
It also allows them to route technical metadata (logs, access records, telemetry) to global hubs to maintain the cloud and to allow global administrators access for emergency maintenance, regardless of where those administrators are.
The fact that it is metadata that moves potentially allows a provider to say, “We don’t move your data”, but the metadata may be enough for a FISA Section 702 investigation, for example.
You can’t just uncheck a box in the settings to opt out of follow-the-sun. Instead, you have to move to a sovereign cloud or regulated industry contract – the AWS European Sovereign Cloud or Microsoft Sovereign Cloud, for example. These guarantee that support and operations are handled only in a specific region.
There are also “sovereign cloud” solutions, in which the “cloud” is disconnected from the wide area network (WAN).
Obviously, if a customer is on a standard contract, support has full oversight of maintenance and updates, and quite likely from anywhere in the world. You’d think that a local sovereign cloud would remove that scenario, but the cloud provider’s infrastructure must still be maintained, and it is via patching that that occurs. Here is where unwanted snooping could be introduced.
Even if the UK staff are the only ones physically in the datacentre, the private keys used to sign “official” software updates likely reside in a hardware security module (HSM) in the US or its facility elsewhere.
So, if a US court compels the company to sign an update that contains legally sanctioned spyware, UK “sovereign” staff have no technical way to verify that the code doesn’t contain a backdoor.
Questions to the hyperscalers
We asked AWS, Google Cloud and Microsoft five questions around data sovereignty. We also asked IBM and Oracle, because they are both fair-sized US-based suppliers to the UK public sector.
The intention was to gauge the levels of exposure their customers could face with regard to data sovereignty.
All responded except Oracle, whose PR representatives failed to reply to three emails.
The questions were preceded by a preamble that drew attention to the US Cloud Act, non-disclosure orders and FISA Section 702, and the powers therein to compel a provider to grant access, forbid notifications to customers of a court order, compel “technical assistance”, and the possibility of updates authored in the US as a means to effect access to customer data.
The questions asked about:
- The technical barriers, if any, in the provider’s cloud services that prevent a court order from forcing the use of encryption keys to decrypt customer data.
- The technical means by which data-in-use functions are carried out without cloud provider access to encryption keys.
- Whether the cloud provider can guarantee a US-authored software update that contains “technical assistance” aimed at gaining access to data cannot bypass air-gapped systems.
- Whether the cloud provider has a wholly distinct UK region with exclusively UK-resident support and engineering, including third-party contractors.
- Whether standard terms of cloud service allow for customer data to be moved offshore, or whether a customer can have 100% UK data residency without a bespoke contract.
Hyperscalers dodge the questions
Here we summarise their responses. Full responses are available to view in the box at the end of this article.
Hyperscaler responses to our questions fall under the following categories.
“Don’t look there! Look at the air gap!” The subject of the questions was cloud services in general, but responses often shifted attention to specifically air-gapped offerings.
Google opted to talk about its niche, air-gapped Google Distributed Cloud in response to nearly every question. Perhaps a tacit admission that standard cloud terms of service come nowhere near providing data sovereignty.
Google wasn’t alone here, though; just the most dependent on the tactic. AWS also pointed to its AWS Dedicated Local Zones and Outposts managed on-premise offers when asked about cloud services.
“Look! Local people!” A number of responses tried to distract from the inherent technical vulnerabilities that come with the global, linked nature of hyperscaler cloud. They instead drew attention to the residency or nationality of human operators rather than the reality that automated, US-signed code updates can bypass human gatekeepers entirely.
It is virtually impossible for a locally resident operator to scan a multi-gigabyte compiled binary for a state-level backdoor. A backdoor in a modern cloud stack wouldn’t be a line of code that said, “if (user == ‘FBI’) return data”. It would be a subtle mathematical weakness in an encryption library or a port knocking sequence hidden in a network driver.
Local operators can, at best, scan for known viruses, not state-level “technical assistance”.
Encryption? Of course. For data-in-use? Errr. All hyperscalers highlighted the use of encryption in customer data and customer key retention to imply total security.
That works for “at-rest” and “in-transit” scenarios. But it glosses over data-in-use scenarios where data must, in most cases, be decrypted in memory.
If a US-compelled “technical assistance” order under FISA Section 702 forces a US company to push a firmware update to its own HSMs or Nitro controllers, that update is signed by the US parent. Hardware isolation is only as sovereign as the person who holds the cryptographic signing key for the firmware.
Also, in a software-as-a-service (SaaS) environment like M365, Microsoft provides the application and is the administrator. Here, customer-managed keys often break “search” and “discovery” features in SaaS. So, if a customer wants to search their emails in M365, the data must be decrypted by Microsoft’s service.
Is it sovereign? Of course; it’s in the EU. In some cases, hyperscalers responded by pointing to European sovereign solutions. AWS, for example, points to its European Sovereign Cloud service, which doesn’t locate data in the UK and is not technically sovereign anyway, given the EU is not a sovereign state.
Meanwhile, if AWS Seattle has “control” over the AWS Germany subsidiary, which it does, financially and technically, a US court doesn’t care about the EU’s “Sovereign Cloud” label.
“Trust Me, Bro,” as a legal pledge. Microsoft majored on this one in its responses. It switches out technical proof of impossibility for corporate pledges to “challenge every government request” in court. This asks the customer to trust a legal process rather than a technical lock.
Spoiler alert: There are zero known instances where a hyperscaler has successfully and permanently defied a final, non-appealable US court order to protect a non-US citizen’s data stored abroad.
To sum all this up, the hyperscalers are essentially saying that standard cloud is not sovereign. To achieve a level of protection that would allow them to answer these questions with any level of integrity, a customer must move to isolated, air-gapped, or hardware-encrypted tiers that are significantly more expensive, regionally limited and functionally constrained. And would that be cloud?
The paradox of data sovereignty in the cloud
At the end of the day, hyperscaler cloud is caught in a paradox when it comes to data sovereignty. If a cloud were truly sovereign – disconnected, local-only, human-managed – it would lose the cloud economics that make it attractive due to its global scale, automation and the accompanying economies. And so, “sovereign cloud” is really often a marketing term that means standard cloud with extra paperwork.