If someone steals your credit card number, it is an afternoon of annoyance. You call the bank, the card is cancelled, a new one arrives, and the old number is worthless. The system is designed so that a compromised credential can be revoked and replaced.
A genome has no such feature. If a patient’s genomic data is exfiltrated, there is no reissue. It cannot be cancelled, rotated, or reset. It identifies not only that patient but, in part, their children, their siblings, and their parents — people who never consented to anything. It is as permanent as a fingerprint and far more revealing. That permanence is the whole point: unlike almost any other data we handle, a genome that leaks stays leaked, and it can be misused for decades.
I want to use this space to think through what that permanence should mean for how a clinical genomics lab answers a question that sounds like plumbing but is really strategy: where does your data actually live, and what can reach it?
The stakes are specific to our field
This is not a hypothetical for the genomics community. Large, well-resourced genomic repositories have already been targeted. In 2026, UK Biobank, one of the most significant research resources in the world, was reported to have had genetic, biological, and health information on roughly half a million participants offered for sale online. The details will keep being debated, but the lesson does not depend on the details: when a repository of DNA is compromised, the harm is not a stolen number that can be reissued. It is permanent, and it radiates outward to entire families.
It is worth noting the counter-example too, because it points at the answer. Genomics England, running the national-scale sequencing that many countries now aspire to, made a deliberate choice from the outset to hold its data inside a secure, controlled, government-owned environment rather than pushing it out to commercial infrastructure. When reports circulated years ago that it had scrambled to relocate data after attacks, the organization was clear that its data had always resided in that controlled facility. That is not luck. That is architecture a decision made before the threat arrived rather than after.
Why the threat model changed
For years, the honest answer to “how safe is our data in the cloud?” was: safe enough, if the guardrails hold. That bargain is now under real pressure, and the reason is the same technology reshaping the rest of our industry.
The newest frontier AI models are remarkably good at reading code and finding the flaws in it. This is not marketing language; it is the consensus of the people who defend networks for a living. The capability is significant enough that the most advanced security-focused models have been held back from open release and routed instead to defenders under controlled programs, precisely to buy time to fix vulnerabilities before they are exploited at scale. Independent forecasts now expect the number of disclosed software vulnerabilities in 2026 to surge, driven largely by AI systems that hunt for flaws autonomously.
Here is the part worth sitting with. This capability is genuinely good news for defenders — find and fix a weakness before anyone can use it. But the same capability lowers the cost for attackers. The economics of finding a way in are collapsing on both sides of the fence at once. What used to take a skilled researcher weeks can increasingly be attempted at machine speed and machine scale, against every internet-facing system at once.
When the cost of discovering an exploitable weakness in a connected system trends toward zero, “we have strong guardrails” stops being a complete answer. Every external connection is a door. Every cloud dependency and third-party integration is part of your attack surface, whether or not it sits inside your own walls. The tools for testing every door in the world simultaneously are getting cheaper by the month.
You cannot exploit an attack surface that does not exist
Put the two together, irreplaceable data on one side, automated vulnerability discovery aimed at connected systems on the other, and a design principle that used to look merely conservative starts to look like plain common sense.
If a system has no external network connection, it has no external attack surface. There is nothing for a remote adversary, human or automated, to scan, probe, or reach. The mass-exploitation model that AI is accelerating has no place to land. That is the logic of the air gap. It is not a new idea. What is new is how much stronger the case for it has become in the span of about a year.
What our experience has taught us
This is not a position we adopted in response to recent headlines. For more than two decades, and across more than 400 institutions in over 50 countries, we have built the VarSeq Suite to give the laboratory, not the vendor, control over where genomic data lives. Our software is designed from the ground up to run behind institutional firewalls, on any operating system, and with no internet access at all.
In a fully air-gapped deployment, everything operates inside the isolated network: the analysis software, the annotation databases, the licensing. Nothing needs to reach out, so nothing can be reached. Golden Helix never touches the patient data, it stays inside the institution’s own infrastructure from raw reads through annotation, classification, and signed clinical report. We build and release that software under an ISO 13485 certified quality management system, with full audit trails that attribute every action to an authenticated user and integrate with an institution’s existing identity controls. And it is not a toy configuration reserved for small cases: the same single-tenant architecture scales from an individual clinical sample to population-scale cohorts of tens of thousands of genomes on local high-performance infrastructure. National genome programs, including a multi-year, national-scale partnership with the Danish healthcare regions, have trusted this model to do exactly that.
What has changed lately is not our methodology. It is that a much broader set of laboratories are now arriving, independently, at the same conclusion we reached years ago.
Being precise about what an air gap does
Let me be exact, because the goal here is to inform rather than to reassure. An air gap is not a magic wall, and no one in this field should sell it as one. It removes an entire class of remote risk — the automated, at-scale, internet-borne attacks that are becoming cheaper, but it does not remove every risk. Physical media, the software supply chain, and insider access still demand real discipline, and a poorly governed air-gapped system is not automatically a safe one. What air-gapping does is change the game from “defend every door against the whole internet, forever” to “control a bounded, physical perimeter you actually own.” For most data, that trade is not worth the loss of convenience. For a patient’s genome, I would argue it increasingly is.
The cloud is the right home for an enormous amount of what our field does, and it is not going anywhere. But “everything to the cloud, always, by default” was a habit formed in a gentler threat environment. That environment has changed. The most sensitive data we handle deserves a deliberate answer to the question of what can reach it, and for genomic data, sometimes the safest answer is nothing at all.
Andreas
Golden Helix builds clinical genomics software used in laboratories across more than 50 countries. The VarSeq Suite supports on-premises, private-cloud, and fully air-gapped deployment so that patient data never leaves the institution’s control. Learn more at goldenhelix.com.
