For thirty years, the security industry has been working on the same problem from the same angle. Data exists somewhere — on a disk, in a database, inside a snapshot, on a backup tape — and the job is to keep attackers out of that somewhere. We build fences around it. We encrypt it. We segment the network around it. We add zero-trust controls in front of it. We audit who read it.
And every year, we watch breaches happen anyway. Credentials leak. An insider copies a table. A backup gets mis-scoped. A snapshot ends up in the wrong region. A forgotten RDS cluster gets indexed. The fences get better, the fences still fail, and the losses compound.
The reason is hidden in plain sight. Every one of those controls starts from the same unexamined assumption: that the data needs to be sitting somewhere reconstructible to be available. Once you accept that premise, breach is a matter of time. Every year the surface grows. Every new system inherits the same fundamental liability.
A different starting point
What if the data didn’t sit anywhere?
Not “encrypted at rest,” which still leaves a ciphertext blob adjacent to a key somewhere in the same trust boundary. Not “stored in a vault,” which is a smaller fence around the same object. Not “end-to-end encrypted,” which still leaves reconstructible plaintext sitting in an endpoint’s memory for arbitrary durations.
We mean: the reconstructible form of the data exists only in volatile memory, only while it is moving, and only long enough for the intended recipient to consume it. Before that moment, it doesn’t exist. After that moment, it doesn’t exist. There is no snapshot. There is no backup. There is no forensic recovery path.
This is what we call zero residency, and it is the foundation of the Zero-Residency Data Architecture (ZeRDA) we’re building at BHTN.
Four properties that change the threat model
Zero residency is not a slogan. It is four properties, each one enforced by architecture rather than by policy or operator discipline.
One: reconstructible form is memory-only, motion-only. A transfer in ZeRDA never touches persistent storage in a form anyone can reassemble. Fragments live in volatile memory on a small set of service instances, for seconds at a time. The moment the intended recipient decrypts, every intermediate buffer is byte-wiped.
Two: authority is structurally split. No single component in the pipeline can reconstruct anything. The bulk plane carries payload ciphertext and never sees keys. The critical-redundancy plane carries erasure-coded shards and never sees keys. The metadata plane carries the encrypted reassembly layout and gates reassembly with intent tokens. The key-custody plane holds a wrapped key envelope released only on a single-use redemption token, and never sees payload. Compromising one plane, or even two, yields material that cannot be turned into plaintext.
Three: expiration is terminal. Every transfer has a short time-to-live. After that window closes, the keys no longer exist, the fragments have evicted from memory, and the data is architecturally unrecoverable. There is no admin override. There is no grace period. There is no vault to restore from. Expiration is permanent destruction, and it is enforced cryptographically rather than procedurally.
Four: security is bound to the artifact, not the channel. Integrity checks, lifetime, and authorization ride with the fragments themselves. A stolen fragment, a replayed request, or a token presented outside its window is rejected at the artifact level. There is no session to ride, no TLS tunnel to piggyback on, no long-lived grant to inherit.
These four together produce something the industry hasn’t really seen before: a data pipeline where compromise of individual components cannot be chained into a breach.
Where existing approaches fall short
It’s worth being specific about what zero residency addresses that other architectures don’t.
Encryption at rest moves the blast radius from “disk compromise” to “disk-plus-KMS compromise.” Both are eventually reachable — often by the same attacker, on the same day. The data still exists, in reconstructible form, somewhere a motivated adversary can get to.
End-to-end encrypted messaging protects the wire and the servers in the middle, but leaves plaintext and long-lived identity keys on the endpoints. An endpoint compromise — or a lawful-access order, or a device seizure — recovers everything. The encryption is good; the retention is the problem.
Zero trust assumes hostile networks and requires continuous verification of every access. It is a genuine improvement. But zero trust still assumes the data exists somewhere to be accessed. It shrinks the footprint of trust; it doesn’t remove the target.
Homomorphic encryption and TEEs let computation happen on data without exposing plaintext to the operator. They are powerful, expensive, and still assume the encrypted object is sitting somewhere. Key exposure still means data exposure.
In every case, the reconstructible object exists in some reachable place for some arbitrary duration. The fences have gotten higher; the target hasn’t moved.
What the threat model looks like when you remove the target
Zero residency assumes the worst conditions by default. The network is hostile. Nodes may be compromised. Operators may be malicious. Containers may be killed mid-flight. Memory may be inspected post-mortem. Subpoenas may demand data that no longer exists.
That last one is not a joke. When a regulator or a court asks for data that expired forty seconds ago, the honest answer is that the data is gone — not gone from a specific system, but gone in the cryptographic sense. The keys no longer exist. The fragments have evicted. There is no query to run against a shadow copy, because there is no shadow copy.
This has consequences that are obvious once you sit with them. Whole classes of breach scenarios simply stop applying. Ransomware against stored data plaintext is uninteresting when there is no stored plaintext. Exfiltration from a compromised relay produces fragments that cannot be decrypted without a key that was destroyed. Insider abuse of a “just copy the table” kind has no table to copy. Backup leakage becomes a non-event because the backup never contained anything reconstructible.
The argument is not that ZeRDA makes every attack impossible. It is that ZeRDA removes a specific class of attack that dominates the breach statistics — the reach a persistent copy of the data class — and replaces it with a much narrower, much harder attack that has to compromise all four structurally-separated planes inside a time window measured in seconds.
Why this matters now
Regulated industries are under compounding pressure. Data-residency laws, sector-specific compliance regimes, and a steady drumbeat of breach disclosures all point at the same thing: retention of sensitive data is a growing liability, not an asset. Every stored byte is a future incident, a future audit line, a future subpoena.
Meanwhile, the operational reality inside most organizations is that sensitive data needs to move — between partners, between business units, between a bank and its regulator, between a hospital and a specialist. That movement has never had a good answer. Secure file transfer products bolt encryption on top of storage. Messaging apps compromise on retention. Enterprise data-transfer platforms rely on the same at-rest primitives they were supposed to improve on.
Zero residency is the answer to that problem shape. Data moves, gets used, and disappears — by design, by architecture, not by operator promise.
We think this is the direction the industry eventually has to go. The fences can only get so high. The data itself has to stop being there.
That is the problem ZeRDA is built to solve.