At 1 a.m. on June 3, 1944 — her 21st birthday — Maureen Flavin phoned in her usual hourly reading of the barometer at Blacksod Point lighthouse on Ireland's westernmost peninsula. The pressure was dropping fast. A deep Atlantic low was racing toward the English Channel.
Group Captain James Stagg at Supreme Headquarters Allied Expeditionary Force used that data, ship reports from the mid-Atlantic, and observations from Iceland to produce the forecast that convinced Eisenhower to postpone the D-Day invasion by 24 hours. Had the landings gone ahead on June 5th, low clouds would have grounded air cover, paratroopers would have scattered into storms, and landing craft would have swamped in six-foot seas, killing thousands.
Sweeney's continuing reports the next day confirmed that the weather on June 6 would be much improved. Those readings were also critical: if Eisenhower had not been given confidence in the 6th, the next viable tide-and-moon window was June 19, and that week the invasion force would have sailed into the worst Channel storm in forty years. The week of June 19, the Mulberry harbors were destroyed even in port; 1000-ton concrete caissons in protected anchorage were torn apart by gale-force winds and waves reaching five meters. Landing craft on open water would not have survived.
What's striking about this story isn't the luck of the moment. It's the arrangement. Ireland was officially neutral, the flow of meteorological data kept very quiet. Sweeney had no idea, nor did Germany, that Ireland was sharing the data. If Berlin had learned that Irish observations were being routed to Allied invasion planners, Germany would have likely viewed Ireland as an enemy state. Ireland's decision to share data put the nation at risk, protected only by institutional discretion and luck.
Ireland in 1944 faced what is now a main dilemma of data sovereignty: how to contribute to a computation whose value depends on cross-border sharing of sensitive data, without taking on an untenable risk. Ireland's solution was political at the time, because there was no other option. The mathematics did not yet exist.
The Modern Parallel: The Cross-Border Data Sharing Problem
Eighty years later, organizations face structurally identical problems. A pharmaceutical company in Frankfurt holds a rare-disease cohort whose value multiplies when combined with cohorts in Boston and Tel Aviv — but the GDPR transfer mechanism is a thicket and the disclosure risk is the Frankfurt company's alone. A bank in Singapore has fraud signals that would strengthen a coalition model, but sharing the underlying transactions with its peer institutions means potentially violating local law. A national statistics office (NSO) could contribute to cross-border economic models that benefit its own forecasting, but sovereignty regulations forbid the underlying microdata provided by its citizens from leaving home.
In every case, the structure of the problem is Blacksod's:
- The data is valuable in combination
- The disclosure risk is concentrated on the provider
- And the only available solutions are either political (data-sharing agreements, adequacy decisions, contractual safeguards) or simply not sharing.
The result today is balkanization. The EU Data Act extends sovereignty protections beyond personal data to industrial data. Countries from India to Brazil to Saudi Arabia have tightened data localization. The combinatorial value sits there, unrealized, because the only mechanisms for unlocking it require the data provider to swallow the disclosure risk.
How FHE Enables Computation on Encrypted Data
Fully homomorphic encryption is the foundational layer in closing that gap. Ordinary encryption protects data at rest and in transit. It cannot protect data being computed on. FHE allows computation on encrypted data without ever being able to decrypt it. With FHE, the Frankfurt pharma company can send encrypted data to be jointly analyzed with data from Boston and Tel Aviv at a research compute cluster in Virginia, run the analysis on the encrypted data, and receive encrypted results, all without the Virginia operator ever seeing the data. The bits cross the border, but the information doesn't. This is confidential computing achieved mathematically, without the hardware enclave that most approaches depend on, which have repeatedly been shown to be insecure.
The Singapore bank's problem resolves through encrypted federated learning. The institutions pool their fraud data to train a shared coalition model while the data stays encrypted, so the model reflects every bank's transactions without any bank revealing its records to the others. New encrypted transactions are then scored against that model for fraud signals. The result is financial analytics on encrypted data: the combined view that makes the model worth building, with no institution exposing its customers.
Through privacy-preserving computation, the NSO can contribute its citizens' microdata to a cross-border economic model, keep that data encrypted throughout, hold the keys within its own borders, and still receive the forecasting benefit, all without a single record leaving home in the clear. Data sovereignty is preserved, and the model still gets built.
This is a genuine breakthrough, and it falsifies the dichotomy from 1944 Ireland: the data provider can contribute to the joint computation without the counterparty ever holding the means to read the data: Data sovereignty not by political discretion but by mathematical guarantee.
But the value of FHE for data sovereignty doesn’t stand alone. It’s the first of three layers, each of which must hold before the next one matters. First, the technical gate: can FHE actually protect data confidentiality during cross-border computation? That answer is a strongly proven Yes. Second, the regulatory gate: will regulators accept that protection as legally sufficient? And third, the rest of the story: even with regulatory acceptance, what sovereignty risks remain that encryption alone can't mitigate?
FHE and GDPR Cross-Border Transfers
Under GDPR, encrypted data is still personal data. Encryption does not take data out of regulatory scope. This means FHE alone doesn't exempt an organization from GDPR's cross-border transfer rules. What FHE can do is satisfy the regulatory framework as a "supplementary measure", as the European Data Protection Board provided for in its recommendations for technical measures that can legitimize cross-border transfers.
But the conditions are strict. The encryption must be state-of-the-art and implemented flawlessly. And critically, the encryption keys must be retained solely by the data exporter or an entity within the EEA. FHE is uniquely suited to this requirement, since computation proceeds without decryption by design. But the regulatory recognition depends entirely on getting the key management architecture right.
The Rest of the Story
Blacksod's contribution worked not just because the readings flowed quietly to London, but because of an entire scaffold of controls built around them. Similarly, FHE protects the payload, but metadata about who queried what, when, how often, and from which IP range remains fully visible and subject to subpoena.
There's also the question of legal jurisdiction. If your encrypted data sits on servers subject to a foreign government's national security orders, whether that government can compel key disclosure by the EEA data exporter is orthogonal to the encryption. Ireland's arrangement worked because Britain was an ally with aligned interests, not because the data flow itself was tamper-proof. Data sovereignty concerns in commerce often arise precisely where interests diverge.
The Honest Position
FHE is transformative, and the EDPB has recognized it as a legitimate supplementary measure for cross-border transfers, provided the key architecture keeps decryption capability within the EEA. For organizations whose primary concern is lawfully processing data across borders while preventing unauthorized access to content, FHE is a critical part of a complete answer.
But data sovereignty, fully understood, encompasses content exposure, regulatory compliance, metadata visibility, legal jurisdiction, and operational control. FHE addresses the first two. It does little about the rest. It needs to be embedded in a broader architecture.
The lighthouse keepers of 1944 didn't have a choice. We do. The place you can begin is at the foundational layer: understand what FHE can and cannot do for assured privacy of your data in cross-border computation. With that knowledge, you can confidently approach the rest: key architecture, metadata governance, jurisdictional strategy. The outcome: an 80-year step forward in turning data into business value.
If you’re interested in learning about the basics of FHE before reading this article, take a look at our FHE 101 series.
To learn more about FHE, hardware acceleration, and Niobium’s encrypted cloud platform, The Fog™, contact us or sign up to join our Partner Developer Program!
