Data-Centric Security vs Zero Trust: How the Two Relate
Zero trust is an architectural framework that removes implicit trust from every access decision, and data-centric security is the control model that places one of those decisions at the data object. The two are not alternatives. Zero trust is the superset, and data-centric security is how its data pillar gets built. The difference that matters is scope: zero trust governs identity, devices, networks, applications and data, while data-centric security governs only the last of those, and does so at the object rather than at the path that reaches it.
Zero trust and data-centric security compared
| Property | Zero trust | Data-centric security |
|---|---|---|
| What it is | An architectural framework and a set of principles | A control model that implements one part of that framework |
| Canonical references | NIST SP 800-207 (August 2020), CISA Zero Trust Maturity Model v2.0 (April 2023), DoD Zero Trust Strategy (November 2022) | Object-level encryption formats, ABAC decision services, key access services |
| Scope | Identity, devices, networks, applications and workloads, data | Data objects |
| Unit of decision | A request for a resource | A request to decrypt a specific object |
| Where enforcement sits | Policy enforcement points distributed across the estate | The decrypt path for the object |
| Prescriptive about mechanism | No; NIST SP 800-207 is deliberately technology neutral | Yes; the mechanism is a policy bound to the object and evaluated per request |
| What survives outside the estate | Nothing, unless the data layer has been built | The object's bound policy |
| Measurable as | Maturity across pillars and cross-cutting capabilities | Decisions per object, with reasons and policy version |
| Relationship | Superset framework | Implementation of the data pillar |
Why four zero trust pillars are instrumental and one is terminal
The CISA Zero Trust Maturity Model version 2.0, published in April 2023, names five pillars: Identity, Devices, Networks, Applications and Workloads, and Data, supported by three cross-cutting capabilities covering visibility and analytics, automation and orchestration, and governance.
Four of those five pillars govern enumerable populations with owners. An organization can list its identities, its devices, its network segments and its applications. Each entry has a record, a lifecycle, a provisioning event and an accountable owner. Enumeration is what makes those pillars tractable, because maturity can be stated as coverage of a known set: accounts with phishing-resistant authentication, devices reporting posture, segments with explicit policy.
Data is not a population. Data is a flow. One sensitive record exists simultaneously as a table row, a cached query result, a spreadsheet export, an email attachment, a backup, a log line, an index entry and a model context window, and most of those copies came into existence without a provisioning event that anyone owns. There is no denominator, so data coverage cannot be counted the way device enrollment is counted.
The asymmetry becomes clearer under a chain-of-justification test. Ask why any zero trust control exists and follow the answers. Why authenticate strongly? So that the wrong principal does not reach the resource. Why does that matter? Because the resource holds data that must not be disclosed, altered or destroyed. Run the same chain from device posture, from segmentation, from workload authorization. Every chain terminates in a statement about data. Identity, devices, networks and applications are instrumental, valuable because of what they protect. Data is terminal, because it is the thing being protected.
Instrumental does not mean secondary, and the argument fails if it is pushed further than that. A terminal pillar built without the instrumental four has nothing to evaluate. A policy that releases an object to cleared personnel on a compliant device from an approved jurisdiction is only as trustworthy as the identity, device and network signals feeding it. The instrumental pillars are what make the terminal pillar decidable. The claim is about ordering, not about importance: build the four so the fifth can be decided, and build the fifth so the four have a purpose that can be audited.
Network-centric zero trust and data-centric zero trust
Network-centric zero trust replaces the flat trusted network with per-session authorization. Micro-segmentation, identity-aware proxies, software-defined perimeter and continuous session verification all share one unit of control: the connection. The question asked is whether a principal may reach a resource right now.
Data-centric zero trust changes the unit of control to the object. An authorized session to an authorized application does not by itself release a protected object, because the decrypt request is a separate decision evaluated against the policy carried inside that object.
| Property | Network-centric zero trust | Data-centric zero trust |
|---|---|---|
| Unit of control | The session or connection | The data object |
| Question asked | May this principal reach this resource now | May this principal open this object now |
| Result of a successful decision | Access to a resource and whatever it serves | Release of one object under one policy version |
| State of data after legitimate access | Unconstrained once retrieved | Still bound by the policy inside the object |
| Blast radius of a compromised session | Everything reachable within that session | Only objects whose policies evaluate to allow |
| Coverage of unmanaged paths and copies | None | Retained, because the policy travels in the object |
Both are needed. Network controls limit reconnaissance and lateral movement, which reduces how often object-level decisions are asked under adversarial conditions. The handoff between them is examined in Why Network Zero Trust Stops at the Data Boundary.
What zero trust frameworks specify about the data pillar
NIST SP 800-207, published in August 2020, defines zero trust architecture in logical terms: a policy engine and policy administrator forming the decision function, and policy enforcement points mediating access, governed by seven tenets. The publication is deliberately technology neutral and does not prescribe how data objects should be protected.
The CISA Zero Trust Maturity Model version 2.0 describes progression for the data pillar across four stages, from manual inventory and static controls toward automated categorization and labeling with access decisions informed by continuous risk assessment. It states the destination without naming a product category.
The DoD Zero Trust Strategy, published on 22 November 2022, names Data as one of seven pillars alongside Users, Devices, Applications and Workloads, Network and Environment, Automation and Orchestration, and Visibility and Analytics. It directs components to reach Target Level as soon as possible and no later than fiscal year 2027.
All three converge on what the data pillar must achieve and leave the mechanism open. Data-centric security is one answer to that mechanism question, and the accurate way to state its position is that it implements a pillar rather than replacing a framework.
What data-centric security does not replace
Data-centric security does not replace identity infrastructure. Object policies reference subject attributes, and those attributes come from an identity provider and its governance processes. A weak identity layer produces confidently wrong object decisions.
Data-centric security does not replace device posture assessment. A policy condition naming a compliant device is only meaningful if some other system establishes compliance and attests to it.
Data-centric security does not replace network controls. Segmentation, egress filtering and monitoring reduce the frequency and quality of adversary attempts, and none of that value disappears when object-level control is added.
Data-centric security does not replace application authorization. An application still decides which operations a principal may invoke, which records a query may return, and which workflows a role may start.
Data-centric security changes what maturity in the data pillar looks like, from inventory coverage toward per-request decisions with recorded reasons. The attribute model that makes those decisions possible is compared with role-based approaches in ABAC vs RBAC as the Zero Trust Default.
Frequently asked questions
What is the difference between data-centric security and zero trust?
Zero trust is an architectural framework covering identity, devices, networks, applications and data, and it removes implicit trust from every access decision. Data-centric security is narrower: it is the control model that binds policy to a data object and evaluates that policy at every decrypt. Zero trust is the superset; data-centric security is how the data pillar of that superset gets built.
How does data-centric security differ from network security?
Network security decides which principals may reach which resources over which paths, and the decision covers everything reachable through the connection. Data-centric security decides whether a specific object may be opened, and the decision covers that object alone. Network security stops at the boundary of the network it controls; a bound object policy continues to apply after the object leaves that boundary.
What is the difference between network-centric and data-centric zero trust?
Network-centric zero trust authorizes sessions, so the unit of control is the connection and success grants access to a resource and whatever it serves. Data-centric zero trust authorizes decryption, so the unit of control is the object and success releases one object under one policy version. A compromised session exposes everything reachable; a compromised session under object-level control exposes only objects whose policies allow.
Is data-centric security a replacement for zero trust?
No. Data-centric security implements one of five zero trust pillars and depends on the other four for the attributes it evaluates. Identity supplies subject attributes, device management supplies posture, network controls supply environment signals, and application authorization governs operations. A data layer built without those inputs enforces policy faithfully against unreliable facts.
Which zero trust pillar does data-centric security implement?
Data-centric security implements the Data pillar, which appears in the CISA Zero Trust Maturity Model version 2.0 as one of five pillars and in the DoD Zero Trust Strategy as one of seven. Both frameworks describe the destination for that pillar, including automated categorization, labeling and dynamic access decisions, without prescribing the mechanism used to reach it.
How Lattix builds the data pillar
Lattix treats the data pillar as cryptographic enforcement at the object. The Lattix policy decision point (PDP) evaluates attribute-based access control (ABAC) across subject, device, environment and geography, purpose of use, network posture, risk and data-object attributes, and returns a signed, short-lived decision carrying allow or deny, the reasons, the policy version hash and the object identifier. The policy enforcement point (PEP) acts at decrypt time, so enforcement survives whatever service sits in the path. Defaults are fail-closed and revocation propagates to deny. Content identifiers and Merkle-tree lineage make decision history queryable across cloud, regional hub, tactical edge and air-gapped deployments. The category itself is defined in What Is Data-Centric Security: A Technical Reference, and the travelling-policy property is examined in Data-Centric Zero Trust: Policy Travels With the Data.