Zero Trust Architecture for Trusted Research Environments
Zero trust architecture for a Trusted Research Environment (TRE) means that no user, device, network, workload, or output is trusted by default, even after login: every request to reach data is authenticated, authorized against current policy, and logged, and every result that leaves the environment is checked. Applied to health research, zero trust replaces the idea of a secure perimeter around a shared data lake with continuous, per-request verification, and it fits most naturally with a federated TRE where data stays at the source.
Why zero trust matters for TREs now
The traditional security model for research data was a perimeter: build a secure enclave, vet the people who enter, and trust what happens inside. That model assumes the threat is outside. Health research has shown repeatedly that the more common risk is inside: approved users, with valid credentials, doing something the governance never intended. In May 2026, approved researchers walked UK Biobank data out of a centralized platform through its normal workflow. No perimeter was breached, which is precisely the problem. A perimeter model had nothing to say about an authorized user exporting data they were entitled to see.
Zero trust was designed for exactly this situation. The US National Institute of Standards and Technology published NIST Special Publication 800-207, “Zero Trust Architecture,” in 2020, defining zero trust as a set of principles that move defenses from static, network-based perimeters to a focus on users, assets, and resources. The US Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model organizes the approach into five pillars: identity, devices, networks, applications and workloads, and data. The UK National Cyber Security Centre (NCSC) publishes zero trust architecture design principles as well. None of these documents were written specifically for research, but each maps cleanly onto the components of a TRE.
Mapping the zero trust pillars to a TRE
Identity
Every researcher, administrator, and service account needs a strong, verified identity, with multi-factor authentication and short-lived sessions. Access should be granted against attributes such as approved project, role, training status, and data use permissions, rather than broad group membership. The GA4GH Passport standard, which expresses a researcher’s data access permissions as signed, machine-readable claims called visas, is a good fit for research identity because permissions can be checked at each request and expire when a project ends.
Devices
Researchers should reach the TRE through controlled endpoints, typically a browser-based virtual desktop, with copy, paste, printing, and file transfer to the local device disabled. The device a researcher uses at home should never hold research data.
Networks
Inside the environment, workspaces should be segmented from each other and from the internet. Outbound connections should be blocked by default, with package repositories and tools provided through controlled mirrors. A compromised workspace should not be able to reach another project’s data or an external server.
Applications and workloads
Analysis code, containers, and workflows should come from approved, versioned sources, and each workload should run with the minimum permissions it needs for the duration it needs them. Administrative access should be just in time and fully recorded.
Data
This is where research differs most from general IT. Protecting data at rest and in transit with encryption is necessary but not sufficient. In a TRE the most important control is on outputs: every result a researcher wants to take out must be checked for disclosure risk before release. An automated airlock applies statistical disclosure control rules consistently, escalating edge cases to human reviewers. Our guide to output checking and statistical disclosure control covers the rules in detail.
Continuous monitoring
Zero trust also assumes that controls will sometimes fail, so it treats monitoring as a control in its own right. In a TRE, that means watching for patterns that no single request reveals: a user submitting many outputs that sit just above disclosure thresholds, differencing queries that could isolate an individual when results are compared, unusual volumes of activity outside a project’s normal hours, or an administrator account used from an unexpected location. These signals should feed a review process with clear authority to pause a project or revoke access while an issue is investigated.
AI and machine learning workloads
Model training raises a specific data-pillar question: a trained model can memorize and leak information about the records it learned from. Under zero trust, model weights leaving the environment are outputs like any other and should be reviewed against a policy before release, with aggregate evaluation metrics preferred where they answer the research question.
The Federated TRE angle: zero trust between organizations, not just users
Most zero trust guidance assumes one organization protecting its own resources. Health research is different: the most valuable analyses span hospitals, biobanks, national programs, and pharma partners. A centralized TRE handles this by copying everyone’s data into one environment and then trusting that environment’s operator and every user inside it. That concentrates both the data and the trust, which is the opposite of zero trust.
A federated TRE applies zero trust at the level of the organization, and the starting point is that data never leaves the source. Each custodian runs its own node inside its own security boundary. The coordinating layer sends analysis requests; it does not hold data, and each node does not implicitly trust it. Every request is verified at the node against local policy, the approved project, and the researcher’s permissions before any computation runs, and only results that pass the node’s airlock are returned. If the coordinating layer were compromised, an attacker would gain the ability to request analyses, which each node would still evaluate on its own terms, not a copy of the data.
Lifebit builds federated TREs on this model, with an automated Airlock controlling every output and security monitoring across the environment. Our federated TRE reference architecture describes the components, and the Lifebit Federated Trusted Research Environment page covers the platform.
Perimeter security versus zero trust in a TRE
| Dimension | Perimeter model (centralized TRE) | Zero trust (federated TRE) |
|---|---|---|
| Core assumption | Inside the enclave is trusted | Nothing is trusted by default, inside or out |
| Where data lives | Copied into one central environment | Stays at each custodian |
| Access decision | Made once at login or project approval | Made at every request against current policy |
| Insider with valid credentials | Can often export what they can see | Can only release outputs that pass the airlock |
| Compromise of the operator | Exposes all pooled data | Exposes the ability to request analyses, which nodes still verify |
| Network posture | Firewall at the edge, flat inside | Segmented workspaces, outbound blocked by default |
| Evidence for auditors | Logs from one operator | Per-request logs at each node, under each custodian’s control |
A practical framework for zero trust in a TRE
- Inventory resources and flows. List every dataset, workspace, service, and administrative path, and every way data or results can leave. You cannot verify flows you have not mapped.
- Make identity the control point. Enforce multi-factor authentication for everyone, including administrators, and express data access permissions as attributes tied to approved projects so that they expire automatically.
- Remove the local device from the trust chain. Deliver the environment through a controlled virtual desktop with no data transfer to the endpoint.
- Segment and deny outbound by default. Isolate each project workspace and allow only the specific connections analysis requires.
- Control outputs as rigorously as inputs. Route every release through an airlock with automated disclosure checks and human escalation.
- Keep data at source wherever possible. For multi-organization studies, prefer federated analysis over pooling, so that each custodian verifies each request and trust is never concentrated in one place.
- Log everything and review it. Record access, commands, and releases, and feed them into monitoring that can detect unusual patterns, such as repeated near-threshold outputs that might indicate a reconstruction attempt.
Real-world context
Zero trust has moved from guidance into policy. The US Office of Management and Budget memorandum M-22-09, issued in 2022, set a federal strategy for moving government systems toward zero trust, and the CISA maturity model gives organizations a way to measure progress. In the UK, the NCSC design principles are widely referenced by public sector bodies. For health research specifically, the ONS Five Safes framework already reflects zero trust thinking: it does not assume that safe people alone are enough, and it adds safe settings and safe outputs as independent controls. A TRE that implements all five safes technically, rather than relying on user agreements, is most of the way to zero trust. See what a Trusted Research Environment is for background.
Common pitfalls and objections
“We have a secure enclave, so we are already zero trust”
An enclave with strong login controls is a perimeter. If a logged-in user can export data they can see, the model trusts insiders by default.
Treating zero trust as a product
No single tool delivers zero trust. It is an architecture: identity, device, network, workload, and data controls working together, with continuous verification.
Ignoring outputs
Many security programs focus on who can get in and neglect what can get out. For research data, outputs are the main exfiltration path.
“Zero trust will make research impossibly slow”
Continuous verification should be invisible for routine work. Automated airlock checks release most compliant outputs quickly, and human reviewers handle only edge cases.
What to do next
Map your TRE against the five CISA pillars and ask one question for each: what happens if this component is compromised or misused by someone with valid credentials? Wherever the answer is “they get the data,” you have implicit trust to remove. For multi-organization research, the largest step is architectural: keep data with each custodian and verify every request where the data lives.
Frequently asked questions
What is zero trust architecture?
Zero trust is a security model, defined in NIST SP 800-207, in which no user, device, or network is trusted by default. Every access request is authenticated, authorized against current policy, and logged, regardless of where it comes from.
How does zero trust apply to a Trusted Research Environment?
In a TRE, zero trust means strong identity with project-based permissions, controlled virtual desktops, segmented workspaces with outbound traffic blocked, approved workloads, and checking of every output before it leaves the environment.
Is a secure enclave the same as zero trust?
No. A secure enclave is usually a perimeter model that trusts users once they are inside. Zero trust continues to verify requests and controls outputs, so an authorized user cannot simply export data.
Why is federation important for zero trust?
Federation keeps data at each custodian and has each node verify every request locally. That avoids concentrating data and trust in one central operator, which is the opposite of zero trust.
What role does the airlock play in zero trust?
The airlock is the data-pillar control on outputs. It checks every result for disclosure risk before release, so even a legitimate user with valid credentials cannot remove individual-level data.
Which frameworks should a TRE use for zero trust?
NIST SP 800-207, the CISA Zero Trust Maturity Model, and the UK NCSC zero trust design principles are the most widely used references. The ONS Five Safes framework complements them with research-specific controls.