Data-Centric Zero Trust: Policy That Travels With the Data

Data-centric zero trust is an architectural model in which security policy—authorization rules, encryption parameters, provenance requirements, revocation conditions, and contextual attributes—is cryptographically bound to the data object itself, so that enforcement travels with the data and evaluates independently of the infrastructure it traverses.

Conventional zero trust authenticates a principal at a network edge, validates a device at attachment, or authorizes a session at an application gateway. In each case, the enforcement point is infrastructure: a firewall, an identity provider, an endpoint agent, a ZTNA broker. Once the data crosses that enforcement point, copied to a USB drive, emailed to a partner, uploaded to a SaaS application, synced to a personal device, the infrastructure that enforced the policy is no longer in the path. The data is on its own.

Data-centric zero trust changes the enforcement surface from the infrastructure to the object. The policy becomes an inseparable property of the data, evaluated by or on behalf of the data wherever it resides.

---

What "Policy That Travels" Actually Means

When we say policy travels with the data, we mean five concrete capabilities are embedded in or cryptographically anchored to the protected object:

These five capabilities are not a checklist of features; they are the minimal set required for policy to mean something after the data leaves the infrastructure that created it.

---

How Persistent Policy Enforcement Works

The Envelope Model

The canonical implementation wraps the data in an envelope (often following the Zero Trust Data Format, ZTDF, or the Trusted Data Format, TDF) that contains:

1. Encrypted payload, the actual data, encrypted with a unique DEK per object or per version.
2. Policy bundle, machine-readable ABAC rules expressing the authorization logic (e.g., "principal must have attribute clearance:top-secret AND purpose:project-alpha AND device.posture:compliant").
3. Key binding, the DEK encrypted to a KEK that is only released when the policy evaluates to permit against the requester's presented attributes and contextual evidence.
4. Provenance anchor, a cryptographic commitment to an audit ledger (often a distributed ledger or immutable log) that records the object's creation, every policy evaluation, every decryption, and every sharing event.

When a requester attempts to access the object:

1. The requester presents their identity attributes and contextual evidence (device attestation, purpose token, risk score).
2. A policy decision point (PDP), which may be embedded in a client SDK, a gateway, or a dedicated service, reads the policy from the envelope.
3. The PDP evaluates the policy against the presented attributes and context.
4. If permit, the PDP facilitates release of the KEK (or a wrapped DEK) so the requester can decrypt the payload.
5. The access event, including the requester's attributes, the policy version, the decision, and the outcome, is appended to the provenance ledger anchored to the object.

The critical property: the policy travels inside the envelope. The PDP does not need to query a central policy store to know what the rules are; the rules are in the object. The PDP only needs to evaluate them against the current context.

Revocation Without Recall

Because the DEK is encrypted to a KEK reference, not directly to each recipient's public key, revocation operates at the KEK layer. The data owner can:

• Rotate the KEK, existing wrapped DEKs become unresolvable; new shares use the new KEK.
• Update the policy bundle, a new policy version is cryptographically bound to the object; subsequent evaluations use the updated rules.
• Publish a revocation status, the ledger anchor records a revocation event; PDPs that check ledger status will deny even if the policy would otherwise permit.

None of these actions require the data owner to locate, retrieve, or re-encrypt every copy of the object. The enforcement logic is in the policy evaluation; the cryptographic binding ensures the evaluation result is meaningful.

---

Contrast: Data-Centric vs. Infrastructure-Centric Zero Trust

None of these approaches is wrong. Each solves a real problem at its layer. The architectural distinction is where the enforcement decision is bound:

• Infrastructure-centric models bind enforcement to a control point (IdP, agent, gateway, scanner).
• Data-centric zero trust binds enforcement to the asset.

When the asset moves beyond the control point, infrastructure-centric enforcement ends. Data-centric enforcement continues.

---

When Infrastructure Controls Are Necessary But Insufficient

Infrastructure controls remain necessary. You still need:

• Strong identity to establish who is requesting (the policy evaluates against identity attributes).
• Healthy endpoints to trust the attestation evidence the requester presents.
• Segmented networks to reduce blast radius and constrain lateral movement.
• DSPM to discover, classify, and prioritize which data objects need object-level enforcement. Posture tooling maps the estate; it does not stand between a request and the data.

But each has a boundary beyond which it cannot enforce:

In every case, the data has crossed a trust boundary where the originating organization's infrastructure controls no longer apply. Data-centric zero trust is the only model that addresses this gap architecturally, by making the data itself the enforcement surface.

---

Concrete Example: Sharing a Regulated Dataset Across Organizations

The Setup

Organization A (a healthcare provider) needs to share a de-identified patient cohort dataset with Organization B (a research institute) for a joint study. The dataset is subject to HIPAA, the 21st Century Cures Act, and a data use agreement (DUA) that specifies:

• Only named researchers on the approved protocol may access.
• Access requires MFA, a compliant device, and a purpose code study:cardio-2026.
• All access must be auditable and producible for compliance review.
• Organization A retains the right to revoke access immediately if the DUA is violated or the study concludes.

Without Data-Centric Controls (Infrastructure-Only)

1. Org A places the dataset in a secured S3 bucket with a bucket policy allowing Org B's AWS account.
2. Org B's researchers access via a ZTNA tunnel that validates device posture and MFA.
3. Gap 1: Once a researcher downloads the CSV to their laptop, Org A's bucket policy, ZTNA tunnel, and Org B's MDM no longer enforce. The file is a plain CSV.
4. Gap 2: If a researcher shares the CSV with a colleague not on the protocol (email, USB, Slack), no control prevents it.
5. Gap 3: If the DUA is terminated, Org A can revoke bucket access and ZTNA credentials, but cannot revoke the CSV copies already on laptops.
6. Gap 4: Audit logs show who accessed the bucket and when the tunnel was active, not who decrypted the file, when, or on what device.

With Data-Centric Zero Trust (Policy-Bound Object)

1. Org A wraps the dataset in a ZTDF/TDF envelope with:

   • Policy: principal.org == "Org B" AND principal.role == "researcher" AND principal.protocol == "cardio-2026" AND device.posture == "compliant" AND purpose == "study:cardio-2026"
   • Encryption: AES-256-GCM payload, DEK wrapped to Org A's KEK (managed in Org A's HSM / KMS).
   • Provenance: Anchor to a distributed ledger (e.g., Lattix Immutable Ledger) recording every policy evaluation and decryption.
   • Revocation: KEK rotation capability; ledger revocation status.

2. Org A transmits the envelope (single file, ~same size as encrypted CSV) to Org B via any channel: email, SFTP, shared drive, USB. The channel does not provide security; the envelope does.

3. Access attempt by approved researcher:

   • Researcher's Lattix-enabled client (or gateway) presents: X.509 cert / OIDC token with protocol attribute, device attestation (TPM quote), purpose token study:cardio-2026.
   • Client PDP reads policy from envelope, evaluates against presented attributes + live device attestation.
   • Permit → PDP requests KEK unwrap from Org A's KMS (policy-gated release) → DEK released → payload decrypted in memory.
   • Event logged to ledger: {objectId, researcherId, timestamp, policyVersion, decision:permit, deviceAttestationHash}.

4. Access attempt by unapproved colleague (forwarded file):

   • Colleague lacks protocol:cardio-2026 attribute and purpose token.
   • PDP evaluates policy → Deny → KEK not released → payload remains encrypted.
   • Event logged to ledger: {objectId, colleagueId, timestamp, policyVersion, decision:deny, reason:missing-attributes}.

5. DUA termination / study conclusion:

   • Org A rotates KEK or publishes revocation status to ledger.
   • All existing envelopes: on laptops, in emails, on USBs, in Org B's storage, now evaluate to Deny on next access attempt.
   • No recall, no re-encryption, no dependency on Org B's cooperation.

6. Compliance audit:

   • Org A exports ledger anchor for the object: complete, tamper-evident chain of every access decision, with cryptographic proof of policy version at time of evaluation.
   • Auditor verifies: policy matched DUA requirements; all accesses were by approved researchers; no unauthorized decrypts occurred; revocation was effective.

The Difference

---

Data-Centric Controls Complement Infrastructure Controls, They Do Not Replace Them

A common misconception is that data-centric zero trust is a replacement for identity, endpoint, network, and posture controls. It is not. It is a complement that closes the gap those controls cannot reach.

Layered Enforcement Model

+---------------------------------------------------------------+
|                    DATA OBJECT (envelope)                     |
|  +---------------------------------------------------------+   |
|  | Policy: ABAC rules + KEK binding + Provenance anchor    |   |
|  | Encrypted payload                                       |   |
|  +---------------------------------------------------------+   |
+---------------------------------------------------------------+
                              ^
                              | Evaluates policy against context
                              |
              +---------------+---------------+
              |                               |
    +---------------------+         +---------------------+
    |  REQUESTER CONTEXT  |-------->|   POLICY DECISION   |
    |  (attributes,       |         |   POINT (PDP)       |
    |   device attest,    |         |  (embedded/client/  |
    |   purpose token,    |         |   gateway/service)  |
    |   risk score)       |         +---------------------+
    +---------------------+                    ^
              ^                               | KEK release (if permit)
              |                               |
    +---------+---------+         +-----------+-----------+
    |                   |         |                       |
+-----------+       +-----------+ +-----------+           +-----------+
|Identity   |       |Endpoint   | | Network   |           |  KMS /    |
|  (IdP)    |       | (EDR/     | | (ZTNA/    |           |  KEK      |
|           |       |  MDM)     | |  Seg)     |           |  Store    |
+-----------+       +-----------+ +-----------+           +-----------+
   Provides        Provides      Provides              Provides
   identity        device        network               key release
   attributes      attestation   path trust            gated by
                                                          PDP

Each layer contributes evidence to the PDP's evaluation:

• Identity (IdP/IAM): Provides verified attributes: role, clearance, group membership, protocol assignment. Without this, the PDP has no who to evaluate.
• Endpoint (EDR/MDM): Provides device health attestation: patch level, EDR status, disk encryption, jailbreak detection. Without this, the PDP cannot trust the device presenting the request.
• Network (ZTNA/Segmentation): Provides path assurance, the request traversed a verified, encrypted, segmented path. Reduces risk of machine-in-the-middle on the request channel.
• DSPM: Identifies which objects require envelope protection, classifies sensitivity, and triggers initial wrapping.

Data-centric enforcement is the final arbiter. It consumes evidence from all layers, evaluates the policy bound to the object, and produces a cryptographically enforceable decision (KEK release or denial) that persists beyond any single layer's control surface.

Practical Implication

You do not deploy data-centric zero trust instead of ZTNA, IAM, EDR, or DSPM. You deploy it in addition to them, specifically for the data assets that:

• Cross organizational trust boundaries (partners, suppliers, regulators, customers).
• Persist in environments you do not control (cloud providers, SaaS, personal devices, archives).
• Require cryptographic proof of compliance (audit, regulatory, legal hold).
• Have sensitivity that outlives the infrastructure lifecycle (intellectual property, classified data, long-term healthcare/financial records).

For data that never leaves your controlled infrastructure, infrastructure-centric controls may be sufficient. For data that does, or might: leave, data-centric controls are the only architectural answer.

---

General Architecture vs. Lattix Implementation

The preceding sections describe general architectural principles of data-centric zero trust. These principles are implementable with multiple technology stacks: ZTDF (OASIS standard), TDF (ODNI/NSA heritage), custom envelope formats, or proprietary approaches. The architectural properties: policy binding, envelope encryption, provenance anchoring, KEK-gated revocation, request-scoped evaluation, are the defining characteristics.

Lattix-specific capabilities (verified, shipping, documented) include:

• Lattix Security Fabric, a decentralized enforcement layer that runs PDPs at the edge (client SDK, gateway, sidecar) and coordinates KEK release via policy-gated key management. /products/zero-trust-fabric
• Lattix Passport: policy-bound sharing and recovery workflows that let data owners define, delegate, and revoke access to protected objects with cryptographic provenance. /products/lattix-passport
• Immutable Ledger: tamper-evident audit and governance infrastructure that anchors provenance chains for every protected object, enabling compliance-grade evidence. /solutions/immutable-ledger
• PQE Encryption, post-quantum envelope encryption (ML-KEM-1024 + ML-DSA-87) for data whose sensitivity outlives classical cryptography. /products/pqe-encryption
• TDF/ZTDF SDKs: open-standard envelope libraries (Rust, TypeScript, Python, Go) for embedding policy-bound encryption in applications, pipelines, and AI workflows. /developers

Claims not made here (and requiring separate validation):

• Specific certification status (FIPS 140-3, Common Criteria, CNSA 2.0), verify current certifications at docs.lattix.io.
• Performance benchmarks (throughput, latency, scale), context-dependent; run your own evaluation.
• Interoperability guarantees with specific third-party TDF/ZTDF implementations, test against your target ecosystem.
• Deployment topology mandates: Lattix supports cloud, hybrid, air-gapped, and edge; architecture is topology-agnostic.

---

Direct Answer Summary

Data-centric zero trust binds authorization, encryption, provenance, revocation, and contextual evaluation directly to the data object. The policy travels with the data. Enforcement occurs at every access attempt, independent of infrastructure trust boundaries. Infrastructure controls (identity, endpoint, network, DSPM) remain necessary, they supply the evidence the object's policy evaluates against, but they are insufficient once data crosses their control surfaces. Data-centric controls close that gap.

---

Further Reading

• Why Network Zero Trust Stops at the Data Boundary, pillar-by-pillar analysis of the CISA/DoD/NSA zero trust models.
• What Is Zero Trust Data Format (ZTDF) and Why Does It Matter?, technical deep dive on the OASIS standard envelope format.
• Classified Data Sharing With Coalition Partners, operational case study of policy-bound data exchange across classification domains.
• NIST SP 800-207, Zero Trust Architecture (authoritative source for pillar model).
• CISA Zero Trust Maturity Model 2.0, Five-pillar maturity framework.
• OpenTDF Specification, Standard envelope format for policy-bound data.