🎧 Prefer to listen? Audio version below — approximately 22 minutes.
On 19 May 2026, at approximately 22:00 UTC, Railway.com ceased to exist. Not metaphorically. Technically. The platform's infrastructure vanished. Resources became inaccessible. Users saw login failures, dashboard timeouts, "no healthy upstream" errors cascading through their deployment pipelines.
Google Cloud had suspended the company's account. Without warning. Without explanation. With an hour's delay before support would engage.
Railway is an eight-figure customer. They spend roughly £8 million annually on Google Cloud. They automated code deployment at scale. They had learned from prior incidents with Google—learned hard enough in 2024 that they shifted most of their infrastructure away from Google Cloud entirely, moving compute workloads to colocation and third-party datacenters. They had diversified. They had hedged. They had built what looked, on paper, like a defensible architecture.
Then they discovered they had built nothing of the kind.
Because they kept their control plane with Google.
Orchestration. Deployment automation. Identity and access control. The policy engine. The management layer that decides which services run where, how traffic flows, what gets deployed and when. All of it, still running through Google Cloud. All of it, still a single point of failure to a vendor they had already decided could not be trusted with their future.
This is not a technical failure. It is an architectural failure. It is the failure mode that NIST frameworks assume will not happen—because those frameworks are built on the assumption that vendors will follow due process, issue warnings, and respect the baseline expectations of enterprise service delivery. Railway's story is evidence that assumption is no longer reliable.
But it is worse than that. Because Railway's architecture is not an outlier. It is the template that European digital sovereignty policy is currently replicating.
The US National Institute of Standards and Technology's SP 800-53 catalogue is the foundational security control framework used across government, regulated industries, and enterprise architecture planning. It is not perfect. But it is comprehensive. And it contains a specific requirement that should have prevented what happened to Railway.
SC-2: Application Partitioning. The control reads: "The information system separates user functionality (including user interface services) from information system management functionality."
The intent is clear. Separate the workload from the control plane. Ensure that even if one is compromised or fails, the other remains available. Build architecture with layered resilience, not single points of failure.
Railway did exactly this. They moved their workloads—the actual running applications, the deployed services, the customer-facing infrastructure—to colocation and third-party providers. They had explicit resource separation. By the standard definition of SC-2, they had partitioned their application functionality from their management plane.
Except they had not. Because the management plane was still in the same vendor's ecosystem. The separation was horizontal—workload A is in Europe, workload B is in a datacenter, workload C is in a colo facility. But the vertical separation—the thing that controls which workload runs where—that was still upstream, still with Google, still subject to Google's unilateral enforcement of policies that nobody had explained to Railway until it was too late.
SC-6: Resource Availability. The control requires that "the organization prioritizes system processing such that processing is allocated in accordance with organizational priorities." SC-6 assumes the organization retains the ability to prioritise its own resources. It assumes meaningful control over which services are critical and allocate capacity accordingly. Railway could not. Google could, and did, simply delete the account. There was no prioritisation mechanism that mattered. There was only Google's enforcement decision.
SI-12: Information Handling and Retention. Implicit in retention is the assumption that the organization retains custody of its own systems. That the ability to keep, restore, or audit information flows remains with the organization. Railway lost that on 19 May at 22:00 UTC.
What NIST did not assume—and this is the critical gap—is that a vendor could unilaterally suspend an eight-figure customer without warning, without cause, with degraded support response. The frameworks assume this will not happen because they are built on the premise of vendor cooperation. They model the failure modes where the vendor is reliable but infrastructure fails. They do not model the failure mode where the vendor becomes the threat.
More precisely: NIST models the compromised vendor. It does not model the rogue landlord—the vendor that does not compromise your security but revokes your access entirely.
Railway's story—and the European strategies being built on the same architectural logic—is evidence that this assumption requires updating.
Here is what Railway actually built:
Compute workloads: Migrated to colocation and third-party infrastructure, explicitly decoupled from Google Cloud. Control plane: Orchestration, deployment automation, identity, policy enforcement—still running through Google Cloud. Databases: Enterprise-class instances running on Google Cloud. Support relationship: Eight-figure annual spend, presumably with escalation paths and SLAs.
This looks, on the surface, like textbook diversification. You have moved the actual application servers away from the single vendor. You have reduced dependency on Google's infrastructure for your day-to-day operations.
What you have actually done is create a situation where you are still, in the most critical sense, completely dependent on that vendor. Because the vendor controls the keys. The vendor controls which workloads can start. The vendor controls which deployments can proceed. The vendor controls whether your architecture is running or whether all of it—the colo boxes, the third-party datacenters, the carefully engineered separation—suddenly becomes inaccessible because the management layer went dark.
You have solved for geographic and infrastructure diversity. You have failed to solve for vendor diversity.
And the problem becomes acute when the vendor you did not trust enough to run your workloads on still owns the thing that orchestrates everything.
This is where the story stops being about Railway and starts being about what European digital sovereignty policy is currently building.
Multiple strategic initiatives—Gaia-X, EUCLID, the European Commission's sovereign cloud framework, national digital autonomy strategies—are built on a similar architectural logic. Move your workloads to European infrastructure. Use European providers. Ensure data residency inside the EU. Implement strong security controls and compliance frameworks. But keep your control planes, orchestration layers, identity systems, and management infrastructure with hyperscalers that are subject to US law, US jurisdiction, and the US CLOUD Act.
This is not speculative. It is documented in the Commission's own SEAL framework, which explicitly permits "non-European technologies, when operated within a strict and appropriate framework," to provide sovereign cloud services. S3NS—the Thales-Google joint venture that won sovereign cloud contracts—is the concrete example. European data, European operations, European staff. But Google as a minority shareholder and technology provider, with US legal exposure baked into the infrastructure.
It is also documented in national procurement decisions. The UK awarded HMRC a decade-long, single-bidder contract to migrate from Fujitsu datacenters to AWS—replacing one vendor lock-in with another, still with a US company, still with no visible exit strategy.
France, by contrast, has examined this architecture and concluded it is indefensible. In April 2026, the French Interministerial Digital Directorate formally committed to replacing Microsoft across the entire French state—not just migrating data, but migrating the control plane, the management infrastructure, the entire governance stack to open-source alternatives running on French-owned infrastructure. France understands something that much of the rest of Europe has not yet internalised. Partial sovereignty is not sovereignty. You cannot claim digital autonomy if the infrastructure that controls your digital systems answers to a foreign jurisdiction.
The distinction between data residency and governance control is not academic. It is the difference between compliance and capability.
Consider what a control plane actually does. It decides which workloads run. It enforces policy. It manages authentication and authorisation. It handles deployment orchestration. It defines what users can see and do. It is not the data. It is the rules that govern the data.
If you store your data in Europe but your control plane is in California, you have achieved data residency. You have not achieved sovereignty. Because the American control plane can, at any moment, decide that the European data is inaccessible. That the rules have changed. That the policies you thought were yours are no longer yours to enforce.
This is not theoretical. Microsoft's France director testified before the French Senate in June 2025 that he could not guarantee French citizen data would not be transmitted to US authorities. This is a company with years of "EU Data Boundary" work, with technical and contractual measures in place. And still—no guarantee. Why? Because the control plane—the thing that decides what gets transmitted and when—answers to Seattle, not to Paris.
S3NS frames this differently. S3NS management states that they would reject US legal orders. S3NS is a French legal entity. S3NS infrastructure is segregated from Google's public cloud. These statements are true. But they do not resolve the fundamental problem. Because S3NS does not operate independently. Google provides the underlying technology. Google holds a minority stake. Google's personnel have no unilateral access—but Google's legal exposure remains. If a US court issues a valid order to Google, Alphabet, or any entity with a cognisable relationship to the infrastructure, that order is enforceable under US law. S3NS management saying they would reject it is a statement of intent, not a legal shield. The French legal framework provides no protection against US extraterritorial authority.
This is what the SEAL framework failed to account for. It created a scoring system—five levels from zero sovereignty characteristics to full European supply chain. S3NS could only demonstrate SEAL-2, the "Data Sovereignty" level. Three of the four winning bids achieved SEAL-3, the "Digital Resilience" level—meaning immunity from supply chain disruption originating outside the EU. The Commission had created a framework with two different sovereignty outcomes, awarded contracts under both, and then described them both as sovereign.
The Commission stated explicitly that "non-European technologies, when operated within a strict and appropriate framework, can meet the minimum level of sovereignty required." That is not a qualification. It is a deliberate redefinition—drawing a line between sovereign operation and sovereign technology, and concluding that the former is sufficient.
Whether that conclusion holds under legal pressure is the question the framework does not answer.
There is a further problem, one that makes partial migrations worse than no migration at all.
If you build your entire infrastructure on a hyperscaler, you are locked in. Everyone acknowledges this. But the lock-in is visible. You know you are locked in. Every document, every RFP, every governance discussion acknowledges the dependency. The exit strategy is difficult, but at least it is explicit.
If you migrate some infrastructure away from a hyperscaler while keeping the control plane, you have created an illusion of independence. You have reduced the physical footprint of the vendor. You have moved workloads. You have done something. And in doing something, you have created the false impression that you have solved the problem.
You have not. You have relocated the lock-in. You have made it less visible. You have made it harder to recognise and therefore harder to break.
The UK's approach to HMRC—trading Fujitsu datacenters for a decade-long AWS contract—is instructive. The government called this "Data Centre Exit." They did not exit vendor dependency. They migrated it. They replaced one lock-in with another, more durable lock-in, obscured by the language of "modernisation" and "cloud migration."
France recognised this trap. Which is why, when the French Gendarmerie began its Linux migration in 2008, they did it systematically. Over sixteen years. They did not move some workloads and call it done. They trained staff. They solved operational problems. They built internal expertise. By June 2024, 103,164 workstations—97 percent of their computing estate—were running open-source operating systems. The total cost of ownership fell by an estimated 40 percent. They escaped the lock-in completely.
That is what genuine exit looks like. Not partial migration. Not moving compute while keeping control planes. Not creating the illusion of independence. But actually building capability inside the organisation to operate infrastructure without vendor dependency.
DINUM is now scaling that model to 2.5 million civil servants. Every ministry is required to submit an implementation plan by autumn 2026. Visio, a French open-source videoconferencing platform hosted on French infrastructure, will replace Zoom, Microsoft Teams, and Webex by 2027. The entire governance stack—not just the data, but the infrastructure that makes decisions about the data—will be French-owned and French-operated.
This is expensive. It takes time. It requires building expertise that the market is designed to discourage you from developing. It is also the only approach that produces the outcome the word "sovereignty" actually means.
This analysis is not abstract. It matters specifically to jurisdictions outside the EU regulatory framework—including the Isle of Man.
The EU is currently debating digital sovereignty from within a regulatory structure that incentivises "sovereignty washing." The SEAL framework is the product of that structure. Contracts with S3NS and other providers follow from that framework. National procurement decisions that replicate Railway's architecture are justified by the framework.
The Isle of Man operates outside this regulatory ecosystem. There is no Commission-mandated sovereign cloud procurement. There are no SEAL levels. There is no institutional pressure to accept "non-European technologies operating within strict frameworks" as adequate for digital autonomy. This jurisdictional agility is precisely the advantage. Because the Island is not bound by Brussels' compromise between genuine sovereignty and politically acceptable theatricality, local firms can leapfrog the SEAL framework entirely and implement the defensible alternative: true architectural independence.
This is not a weakness of the Island's regulatory position. It is a strength. It provides clarity. It removes the institutional incentive to accept half-measures.
For the Isle of Man's professional services firms—law firms, trust companies, financial services providers—this clarity is valuable. They operate under GDPR obligations. They operate under data protection frameworks that take jurisdiction seriously. They face regulatory scrutiny from the Isle of Man's financial regulator.
The question they face is the same question Railway faced, and the same question European governments are currently deciding to ignore. If a vendor subject to a foreign jurisdiction controls the infrastructure that governs your data, you have not solved the sovereignty problem. You have outsourced it.
The answer is not exotic. It requires infrastructure choices that are deliberate, documented, and defensible. It requires being able to tell a regulator "where does that data go, and who can see it?" and giving a precise response, not a plausible-sounding one.
For firms that operate on the Isle of Man, or for any jurisdiction thinking clearly about this problem, the choice is becoming visible. Either you build infrastructure where the legal jurisdiction and the control plane align. Or you accept that your sovereignty commitments are conditional on someone else's business decisions.
Railway learned this the hard way, at 22:00 UTC on 19 May 2026.
The rest of Europe is learning it more slowly, in procurement documents and regulatory frameworks.
The question is whether it learns the lesson before the lesson becomes expensive.
Control plane ownership is not a technical detail. It is the fundamental distinction between sovereignty and servitude.
You can own your data and still be governed by someone else's rules. You can have data residency and lose data autonomy. You can diversify your workloads and remain completely dependent on a single vendor's goodwill.
Railway diversified horizontally while remaining vertically dependent. The European Commission has codified this architecture as adequate for sovereignty. The UK has institutionalised it in decade-long procurement contracts. France has rejected it entirely, and is spending years and resources to prove that the alternative is possible.
The distinction will become sharper as geopolitical relationships continue to fracture. It will become sharper as hyperscalers grow more confident in their ability to enforce policy unilaterally. It will become sharper as regulatory bodies realise that data residency frameworks do not protect against extraterritorial legal compulsion.
Railway.com understood this on 20 May 2026 at 03:05 UTC, when more of their workloads came back online and the recovery began. By then, they had already spent hours learning the cost of sovereignty theatre.
The question is how many organisations will learn the same lesson before concluding, as France has, that the only adequate solution is to own the stack.
The Sovereign Auditor covers digital sovereignty, data governance, and infrastructure policy—with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
