Zero Trust Data Security: What Regulated Industries Must Know

The network perimeter used to be the line that mattered. Build a strong enough wall, the thinking went, and everything inside it could be trusted. That model has quietly collapsed, and zero trust data security is the framework most regulated organizations are now adopting to replace it. Data lives across cloud regions, SaaS platforms, partner environments, and remote endpoints, and the most damaging breaches increasingly begin with credentials or access that were already considered legitimate. Stolen credentials have been a factor in roughly one in three breaches over the past decade, according to Verizon’s 2024 Data Breach Investigations Report. Once an attacker is inside a flat, trusted network, lateral movement toward the most sensitive records is often the easy part.

For organizations in healthcare, financial services, and government, that shift is not an abstract security-team concern. It changes what regulators, auditors, and partners expect you to be able to prove about how protected data is accessed and used. This guide covers what zero trust data security is, the pillars it rests on, how regulated industries implement it, and the one gap it consistently leaves open: protecting data while it is being processed.

TL;DR

• Zero trust data security applies the principle “never trust, always verify,” formalized in NIST SP 800-207, to data itself: every access request is authenticated, authorized, and continuously evaluated, and access is granted at the narrowest scope needed.
• Mature programs map to the five pillars of the CISA Zero Trust Maturity Model (Identity, Devices, Networks, Applications and Workloads, Data) plus three cross-cutting capabilities: visibility and analytics, automation and orchestration, and governance.
• Healthcare, financial services, and government share the same wall: controlling access is solvable, but using sensitive data across organizational boundaries is not solved by access control alone.
• Zero trust protects data at rest and in transit well, but data in use has traditionally required decryption into plaintext, which leaves an exposure window at the moment of computation.
• Privacy-enhancing technologies (PETs) such as fully homomorphic encryption, trusted execution environments, secure multi-party computation, and federated learning close that gap by protecting data during processing itself.

What Is Zero Trust Data Security and How Does It Work?

Zero trust data security is the application of zero trust principles specifically to the protection of data, wherever that data lives and however it is accessed. The foundational idea, formalized in NIST Special Publication 800-207, is simple to state and demanding to implement: never trust, always verify. No user, device, application, or network location is trusted by default. Every request for access is authenticated, authorized, and continuously evaluated against policy before it is granted, and access is granted at the narrowest scope needed to do the job.

Applied to data, this means access decisions are not made once at the edge of the network. They are made continuously, per request, based on the identity making the request, the security posture of the device, the sensitivity of the data being requested, and the context of the request itself. A request that looks anomalous, such as an account reaching for records it has never touched from an unmanaged device, can be challenged or denied even if the credentials are valid. That matters because credential-based intrusions are both common and slow to catch: breaches involving stolen or compromised credentials took the longest to identify and contain of any attack vector in the IBM Cost of a Data Breach Report 2024, averaging 292 days.

In practice, zero trust data security works through a few reinforcing mechanisms. Strong identity and access management establishes who is asking. Least-privilege access ensures they can only reach what they genuinely need. Microsegmentation breaks the network and data estate into small, independently governed zones so that a compromise in one area does not grant free movement to another. Encryption protects data at rest and in transit. And continuous monitoring feeds every access event into analytics that can detect and respond to abnormal behavior.

The result is an architecture that assumes breach and works to contain its impact, rather than assuming safety and hoping the wall holds. This is the same shift in mindset that underpins broader AI data security practice, where the environment can never be assumed clean. For a broader treatment of these controls, see Duality’s guide to zero trust data protection.

What Are the Five Pillars of a Zero Trust Data Security Model?

Most mature zero trust programs, particularly those in government and regulated sectors, map their architecture to the five pillars defined in the CISA Zero Trust Maturity Model. Each pillar is a domain that must be secured and verified independently, rather than being covered by a single perimeter control.

• Identity. Every user and service account must be authenticated with strong, phishing-resistant methods, and access must be tied to verified identity rather than network location. This is the anchor of the entire model, because access decisions begin with knowing who or what is asking.
• Devices. Every device requesting access is inventoried and continuously assessed for security posture. A device that is unpatched, unmanaged, or showing signs of compromise should not be granted the same access as a healthy, managed one.
• Networks. Networks are segmented into small zones with controls between them. Microsegmentation limits lateral movement, so that gaining a foothold in one segment does not translate into access across the environment.
• Applications and workloads. Applications, APIs, and workloads are treated as resources that must be protected and accessed under policy, including workloads running in the cloud and across hybrid environments. Access between services is authenticated and authorized, not assumed.
• Data. Data is discovered, classified, and protected according to its sensitivity, with access governed by policy and encryption applied at rest and in transit. This pillar is where the other four ultimately point, because protecting data is the objective the whole model exists to serve.

Running across all five pillars are three cross-cutting capabilities that CISA identifies as essential: visibility and analytics, automation and orchestration, and governance. These are what turn a set of controls into a living program. Visibility gives you the telemetry to detect anomalies, automation lets policy respond at machine speed, and governance ensures the whole system remains auditable and aligned to regulatory obligations. For a regulated organization, that governance layer is often the difference between a control that exists and a control you can prove to an auditor.

How Do Regulated Industries Implement Zero Trust Data Security?

The principles are consistent across sectors, but the constraints, the regulatory drivers, and the highest-risk data differ significantly. Implementation of zero trust data security looks different depending on who is doing it.

Healthcare and life sciences

In healthcare, the sensitive asset is protected health information, and the governing pressures include HIPAA in the United States and GDPR for any handling of EU patient data. Zero trust here focuses on ensuring that clinicians, researchers, and applications can reach only the patient records their role and context justify, with every access logged for audit. The complication is collaboration. No single hospital or research institution holds enough data to train a robust diagnostic model, so the sector depends on multi-institution research.

That forces a harder question than internal access control: how do you let multiple organizations derive insight from combined datasets without any of them exposing raw patient data to the others? Standard zero trust controls govern access within an institution well, but they were not designed to answer that cross-organizational question on their own, which is why healthcare AI collaboration has become a distinct technical problem.

Financial services

For banks, asset managers, and fintechs, the sensitive assets include client portfolios, transaction data, and proprietary strategy. The regulatory environment includes GLBA in the United States and DORA in the EU, and the commercial risk is acute: trading activity can reveal intent, and shared data products can leak information about positions or clients. Zero trust data security in financial services emphasizes tightly scoped access to client and market data, strong segmentation between business functions, and detailed audit trails. As in healthcare, the frontier challenge is collaboration, whether that means matching trades, building privacy-safe data products, or optimizing portfolios across parties, all without any party exposing the underlying data that carries its competitive edge. This is the core of practical secure financial analytics.

Government and defense

Government and defense operate under the most stringent constraints. Data is often classified, environments are segmented across high-side and low-side networks, and collaboration must span agencies, contractors, and coalition partners. Frameworks such as FedRAMP and CMMC set the compliance bar, and the driver is not only privacy but national security and sovereignty. Zero trust is now federal policy in the United States: OMB Memorandum M-22-09 directed federal agencies to meet specific zero trust architecture goals, with a target timeline running through the end of fiscal year 2024, and agencies map their architectures directly to the CISA pillars. The recurring mission problem is that agencies and allies need cross-domain collaboration across domains and jurisdictions without exposing classified or otherwise protected data, which is precisely where conventional access controls reach their limit.

Across all three sectors, a pattern emerges. Zero trust data security is very good at controlling who can access data and containing the blast radius when something goes wrong. Where it runs into a wall is the moment sensitive data actually needs to be used, especially across organizational boundaries.

Why Is Zero Trust Data Security Not Enough to Protect Data During Processing?

Here is the uncomfortable truth that a rigorous security architect will already be anticipating. Zero trust data security protects data in two of its three states extremely well. Data at rest is encrypted in storage. Data in transit is encrypted as it moves. But data in use, the state in which data is actively being processed, analyzed, or fed into a model, has traditionally required decryption. To compute on data, systems have historically had to decrypt it into plaintext in memory first.

That decryption is the gap. For the window in which data is decrypted for processing, it is exposed to the compute environment, to privileged administrators, to the underlying infrastructure, and to any attacker who has reached that layer. Zero trust reduces the probability that an attacker gets there and limits how far they can move, but it does not change the underlying fact that the data is in plaintext at the moment of computation. Least privilege, microsegmentation, and continuous verification are controls around the processing environment. They are not protection of the data during the computation itself.

For most internal workloads, careful architecture keeps that exposure window acceptably small. The problem becomes far harder when the whole point of the exercise is to compute across organizational boundaries. When a hospital wants to train a model on data held by four other hospitals, or a bank wants to run analytics jointly with a counterparty, or agencies want to find the intersection of two classified datasets, someone has to decide whose environment the data gets decrypted in and who is trusted to see it. Access control alone cannot resolve that, because the requirement is to use the data without any party exposing it. This is the point at which zero trust needs reinforcement rather than more of the same, and it is why secure data sharing strategies have moved up the priority list.

What Do Most Zero Trust Programs Get Wrong?

The most common shortcoming in real zero trust programs is not weak identity or poor segmentation. It is treating zero trust as an access-control project and stopping there. Three things tend to get missed.

The first is data in use, described above. Roadmaps invest heavily in identity, devices, and network segmentation, and then implicitly assume the data pillar is handled once storage and transit are encrypted. The moment of computation is left as an accepted risk rather than a solved problem.

The second is cross-organizational collaboration. Zero trust models are written from the perspective of one organization protecting its own resources. They have little to say about how two or more mutually distrusting organizations compute over combined data. Yet that is exactly the use case driving the most valuable work in healthcare research, financial services, and defense.

The third is operational auditability of the computation itself. Regulated buyers do not just need the data protected. They need to prove, to an auditor or a regulator, what was computed, by whom, under what governance, and that no raw data was exposed in the process. That requires governance and cryptographic auditability at the level of the computation, not only at the level of access. Technology supports compliance obligations, it does not confer compliance on its own, and closing this gap is part of what makes a control defensible under audit.

How Do Privacy-Enhancing Technologies Complement Zero Trust Data Security?

Privacy-enhancing technologies, often abbreviated as PETs, are the class of techniques that close the data-in-use gap. Rather than protecting the environment around the data, they protect the data during computation itself, which lets zero trust extend to the one state it could not previously cover. They are complementary to zero trust, not a replacement for it. Zero trust decides who is allowed to compute. PETs govern what is exposed when they do.

Several PETs matter here, and their differences are worth getting right because their trust models are not the same.

Fully homomorphic encryption (FHE) allows computation to be performed directly on encrypted data. The data stays encrypted throughout the computation and is never decrypted mid-processing. When the encrypted result is decrypted by the key holder, it matches what you would have gotten by computing on the plaintext. The trust rests on the mathematics rather than on any hardware or operator. Fully homomorphic encryption carries real computational overhead compared with computing on plaintext, though that overhead continues to improve, and its schemes based on lattice problems are generally considered post-quantum candidates.

Trusted execution environments (TEEs), also called secure enclaves, take a hardware-based approach. Data is decrypted and processed in plaintext, but inside an isolated enclave protected by the processor, with remote attestation to verify the enclave integrity. The distinction from FHE is important and often misstated: in a trusted execution environment the data is decrypted inside the enclave and protection comes from hardware isolation and trust in the hardware vendor, whereas with FHE the data stays encrypted and the trust is in the math. They are not interchangeable, and a serious program chooses between or combines them based on its threat model.

Secure multi-party computation (MPC) lets multiple parties jointly compute a function over their combined inputs while each keeps its own input private, distributing trust across the participants so no single party sees another raw data. Federated learning (FL) trains a model across decentralized data sources, sending only model updates rather than raw data. On its own, federated learning is not a complete privacy guarantee, because raw model updates can leak information about the training data, so in production it is paired with differential privacy, which adds calibrated noise to bound what any output reveals about an individual record, and with secure aggregation using TEEs or cryptographic techniques.

How the main PETs compare

Used together with zero trust, these technologies change what is possible. Zero trust governs access to the collaboration. PETs ensure that when the computation runs, no party has to expose its raw data to any other party or to the infrastructure. For regulated industries, that is the missing piece: the ability to collaborate on and analyze sensitive data across institutional boundaries while it remains protected the entire time. For organizations that need to operationalize these capabilities, the Duality Platform brings secure query, collaborative AI, federated analytics, governance, and multiple PETs into one environment.

Zero Trust vs. Confidential Computing vs. Duality: What’s the Difference?

These approaches address different layers of the problem. Zero trust governs who and what may access a resource. Confidential computing protects data while it is processed inside a hardware-isolated enclave. Duality adds a secure computation and collaboration layer that combines multiple privacy-enhancing technologies so organizations can work across trust boundaries without exposing raw data.

• Zero trust: controls identity, device, network, application, and data access; best for continuously verifying access and limiting blast radius.
• Confidential computing: protects data in use inside a trusted execution environment; best when hardware-isolated processing fits the threat model and performance requirements.
• Duality: combines FHE, TEEs, federated learning, differential privacy, governance, and auditability; best when analytics or AI must run across sensitive data held by different organizations, environments, or jurisdictions.

The practical distinction is simple: zero trust decides who may compute, confidential computing protects one type of compute environment, and Duality orchestrates multiple privacy-enhancing approaches so the computation itself can remain protected and governed across organizational boundaries.

How Does Duality Extend Zero Trust to Data in Use?

Duality is a Secure AI Collaboration Platform. It provides the secure computation layer that lets organizations run AI and analytics on sensitive data across institutions without exposing it. In zero trust terms, Duality addresses the pillar that access controls alone cannot fully protect: data in use, especially when the work spans trust boundaries. Data never moves. The insights do. Learn more about Secure Collaborative AI.

The architectural difference is worth being precise about. A confidential computing approach that relies solely on hardware enclaves protects data in use by decrypting it inside a TEE, which means trust ultimately rests on the hardware vendor and the attestation chain. Duality instead combines multiple privacy-enhancing technologies rather than betting on one. Zero Footprint Query, powered by fully homomorphic encryption, lets an organization search and query data held by another party without revealing the search terms or results to the data provider, and without the data provider exposing its underlying data, so no plaintext is created for a vendor to protect in the first place. 

Secure Collaborative AI uses trusted execution environments, federated learning, and differential privacy to train and deploy models across decentralized data with no data movement. Governance, access control, and cryptographic auditability run through the platform, so the computation itself, not just access to it, can be governed and evidenced for regulators and auditors. The cryptographic foundation is built on lattice-based schemes considered post-quantum secure and traces to OpenFHE, the DoD-funded open-source library, which is the same base underpinning much of the broader secure AI ecosystem.

This is not theoretical. In healthcare, Duality powered secure federated AI model development across multiple US and UK universities enabling collaboration without exposing patient data and reducing data-use agreement timelines from months to weeks. In government, the platform is deployed for encrypted cross-domain analysis and coalition collaboration where classified data cannot be exposed. In financial services, it supports secure computation on data that carries competitive and client-confidentiality risk. In each case, the organization keeps its zero trust access controls and adds the ability to actually use protected data without exposing it.

The practical way to think about it: zero trust tells you who is allowed in the room. Duality lets the people in that room work on each other’s most sensitive data without any of them ever seeing it in the clear.

How Should You Decide Where PETs Fit Into Zero Trust?

If you are evaluating where PETs fit into an existing zero trust data security program, a few questions clarify priorities quickly:

• Do any of your highest-value initiatives require computing on data you cannot move, cannot centralize, or cannot legally share? If yes, data-in-use protection is on your critical path, not your backlog.
• When sensitive data is processed today, in whose environment is it decrypted, and who can see it in that window? If the honest answer includes parties you would rather not fully trust, that is your exposure.
• Can you prove to an auditor what was computed on protected data and that no raw data was exposed? If not, you have a governance and auditability gap, not just a technical one.
• Are your collaboration bottlenecks technical, or are they legal and trust-based delays caused by the need to share raw data? PETs often remove the reason those legal delays exist.

If several of these land, the next step is not more access control. It is extending protection to the moment of computation. The organizations pulling ahead are the ones that stopped treating data in use as an accepted risk and started treating it as a solvable engineering problem, because the collaborations that create the most value are precisely the ones conventional zero trust cannot reach on its own.