For the past six weeks, Gulf and European banks have been war-gaming datacentre relocations.
Iranian drone and missile strikes on AWS facilities in the United Arab Emirates and Bahrain in March caused damage that AWS itself now says could take several months to fully restore. UAE banks – including Abu Dhabi Commercial Bank, Emirates NBD and First Abu Dhabi Bank – are operating under weekly regulatory dispensations to use offshore datacentres because their primary cloud infrastructure cannot reliably serve them.
Meanwhile, 94% of IT leaders say they are seriously concerned about vendor lock-in, and many are actively exploring exits.
The hyperscalers have responded. IBM launched Sovereign Core in May. Microsoft has just scaled Azure Local to thousands of servers as a Sovereign Private Cloud configuration.
Both products are pitched as the answer to the sovereignty question. They are not. They are a marketing fix to an architectural problem.
The reason European governments keep ending up with these products is not that the underlying problem is unknown. It is that the psychology of large-scale IT procurement has not adjusted to the reality of geopolitical exposure.
European politicians, in my experience working with them, are resolutely untechnical. The default psychology of public-sector cloud buying remains, “no one got fired for buying IBM”. So you get European ministers signing Google sovereign cloud contracts with clauses in them that are legally invalid against US law. And you get national sovereign cloud projects that are, when you look at the underlying stack, rebadged hyperscaler products.
The Swiss federal sovereign cloud is the cleanest example. The product being marketed as Switzerland’s sovereign cloud is essentially rebranded Microsoft Azure. The Swiss military is refusing to use it. If you cannot get your own country’s armed forces to deploy on the sovereign cloud you are pitching to your enterprises, you do not have a sovereignty product. You have a procurement artefact.
But even where the underlying cloud is genuinely under your control, there is a second problem most of these procurement conversations have not caught up with yet. It is no good having a sovereign cloud running in your country that is open source and governed by you, but then using it to run American cloud software that has backdoors.
So, if you create a sovereign Salesforce, take Salesforce as software, run it on your sovereign cloud, pay a licence fee, and call it air-gapped, you have the same problem one layer up. The application has backdoors.
It probably also has kill switches. And kill switches stopped being hypothetical a long time ago. We got close to that with the Trump-Greenland episode last year, it is not inconceivable that an American administration would, under sufficient political pressure, start switching foreign deployments off.
A sovereignty wrapper around hyperscaler infrastructure does not change where the underlying technology originates. It does not change the fact that the cloud software was written by an American or Chinese company, with whatever hidden backdoors and kill switches that come with that.
And it does not change the calculus when the underlying infrastructure goes down. The UAE banks operating under weekly dispensations are not in that position because their sovereignty contracts failed. They are in that position because contracts cannot be invoked fast enough to move a banking workload off a damaged datacentre and onto another one in days, let alone hours.
You can fund models, buy GPUs and launch national cloud initiatives. But if the infrastructure those systems run on is owned by foreign providers, you have not achieved sovereignty. You have created a dependency with better branding.
The architectural fix looks different.
Instead of putting a sovereign wrapper around someone else’s stack, you build a cloud that is created by a mathematical network, combining compute nodes from independent parties, in different jurisdictions, governed by a protocol rather than a vendor. Your software then becomes immune to traditional infrastructure hacks, and you can change which providers run those nodes without interrupting your hosted software at all.
The mechanism is straightforward. Say you have spread your cloud across Amazon datacentres, and you decide you want to move to Google. You add new Google nodes. Once they are synced into your subnet, you delete the Amazon nodes. Your apps and services continue running without a hitch. Your users do not notice anything. The cloud walks across the underlying compute. Your hosted software is completely independent of the underlying compute provider.
The portability is mathematical. It is enforced at the protocol level using Byzantine fault tolerance, meaning a sufficient number of nodes have to agree on every state change for any state change to occur. If a hacker tries to move a workload, they cannot, because two plus two cannot equal five. Two plus two always equals four, and that is why it is hack-proof. You cannot have a Sybil-type attack on it either, because nodes have to submit to the governance system that runs on the network.
That mathematical guarantee starts to look more attractive when the question shifts from regulatory exposure to kinetic risk. I have been showing the multi-provider, multi-jurisdiction model to Middle East clients specifically because of the drone attacks on datacentres.
The traditional cloud resilience playbook, with multi-region failover and backup zones within the same provider, does not solve this problem. If a drone hits the datacentre your primary region is in, your failover region is statistically also at risk. The point of running the cloud as a mathematical network is that, even when the Iranians turn drones onto the datacentres, your stuff is still running on Amazon. It just does not go down.
There is a reasonable counterargument that this architecture is hard. It is. It requires institutions to think differently about how compute is provisioned, governed and audited. It requires governments to accept that sovereignty is a property of the architecture, not of the contract. And it requires the wider industry to acknowledge that the hyperscaler-wrapper era, sovereign cloud branded by AWS, Azure or Google, sold as the answer to digital sovereignty, is a transition state, not a destination.
But that transition is happening anyway. The next major outage at a hyperscaler datacentre, kinetic or otherwise, will force the conversation into a new register. The next signed-but-legally-invalid sovereign cloud contract will force a procurement reckoning. The institutions that survive both, and they are coming, on a timeline measured in months not years, will be the ones that designed for the architectural reality of multi-provider, multi-jurisdiction, mathematically-enforced portability long before they were asked to.
Sovereignty is not a sticker you put on someone else’s cloud. It is a property of how the system is built.
Dominic Williams is founder of Dfinity Foundation, the not-for-profit research and development organisation behind the Internet Computer protocol.
