Why Network Zero Trust Stops at the Data Boundary

The federal zero trust framework is settled. NIST SP 800-207 defines the abstract architecture. The CISA Zero Trust Maturity Model 2.0 organizes the architecture into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. The DoD Zero Trust Reference Architecture maps the same model into seven pillars by splitting Networks and adding Visibility and Automation. Every framework names Data. Most enterprise deployments stop short of it.

The reason is architectural, not budgetary. Network zero trust resolves to controls that enforce at the moment of transit. Identity zero trust resolves to controls that enforce at the moment of authentication. Device zero trust resolves to controls that enforce at the moment of attachment. Each of these has an established enforcement surface, an established vendor market, and an established procurement vocabulary. The data pillar does not, until the enforcement moves onto the object itself.

What the first four pillars actually enforce

The Identity pillar evaluates a claim at the moment a session begins. It authenticates a principal, validates an attribute set, and produces a session token. The token represents an authorization grant that the application layer is expected to honor for the duration of the session. The token does not travel with the data the session reads, and it does not constrain the data after the session ends.

The Devices pillar evaluates an attestation at the moment a device joins the network or initiates a request. It produces a posture assessment that gates access to downstream resources. The posture assessment lives in the network and identity infrastructure. It does not bind to the data the device retrieves.

The Networks pillar evaluates a flow at the moment traffic crosses a control boundary. It enforces encryption in transit, segments traffic into trust domains, and applies inspection or rate-limiting at the boundary. The enforcement ends when the traffic terminates inside the trusted segment.

The Applications and Workloads pillar evaluates an authorization decision at the moment the application receives a request. It checks the session token against an internal authorization model, and it returns a permitted or denied response. The enforcement ends when the response is rendered or written.

In all four pillars, enforcement is bounded to the moment of an event. The session, the attachment, the flow, the request. Once the moment passes, the artifact, the connection, the cached payload, the response body lives outside the enforcement boundary.

What the data pillar requires

The data pillar evaluates an authorization decision at the moment a data object is read, written, or shared, regardless of where the object is or which session is doing the work. The evaluation does not depend on the network the request traverses, the identity infrastructure that issued the session token, or the application that holds the access path. It depends on the policy bound to the object and the attribute set the request can prove at the moment of access.

This is not the same control class as the first four pillars. The enforcement surface is the data, not the session. The attribute set must be presented and evaluated against a policy that travels with the object. The cryptographic envelope must release the wrapping key only when the policy evaluates to permit. Without this binding, the data is protected only by the upstream controls, and the upstream controls all ended at the boundary of the moment they enforced.

NIST SP 800-207 names the architectural component for this. The policy enforcement point sits in front of the data, the policy decision point evaluates the attribute set against the policy, and the cryptographic enforcement is part of the policy enforcement point itself. NIST SP 800-162 and SP 800-205 define attribute-based access control as the policy model. The NSA Zero Trust Implementation Guideline Phase Two names ZTDF and IC-TDF as the schemas for cross-component data rights enforcement.

Every reference architecture describes the same architecture. The implementation gap is the one between perimeter-attribution enforcement and object-level enforcement.

Why most programs stop at networks

Three operational realities push enterprise zero trust programs to stop at networks.

First, the budget cycle is friendlier. Identity-aware proxies, microsegmentation tools, continuous authentication services, and encrypted DNS deployments map to existing CapEx categories. Object-level cryptographic enforcement maps to a category most program offices have not stood up. The procurement vocabulary is still maturing, and the FY budget defenses are easier for products that look like network equipment.

Second, the audit story is friendlier. A network or identity control produces an audit log of sessions and flows. The auditor reads the log and confirms enforcement happened. An object-level control produces a cryptographically anchored lineage of read and write events. The auditor reads a Merkle tree. The audit story is more rigorous, and it is less familiar.

Third, the deployment pattern is friendlier. A network or identity control deploys in front of the application. An object-level control deploys around the data. The first leaves the application unchanged. The second requires the application to use a policy-bound representation of the data. The integration burden is higher in the short term, and the strategic payoff is harder for a single program office to defend against a multi-year migration calendar.

Each of these is a real obstacle. None of them is a reason the data pillar does not need enforcement.

What closes the gap

Lattix Technologies binds policy to the data object through attribute-based access control at the policy enforcement point, post-quantum key encapsulation using ML-KEM-768 and ML-KEM-1024, and Merkle-tree lineage in content-addressed storage. The cryptographic envelope is ZTDF. The policy decision point evaluates the attribute set against the policy at every access. The release of the wrapping key is fail-closed against any request whose attribute set does not satisfy the policy.

The architecture closes the gap by construction. A compromised session that successfully crosses the first four pillars still encounters the data pillar enforcement on every object it touches. A network exfiltration of wrapped objects produces ciphertext that the operator's key rotation can revoke against future reads. A perimeter compromise that opens an access path produces no plaintext to exfiltrate, because the plaintext never sat outside the policy boundary in the first place.

The five-pillar framework is not finished at four. The fifth pillar is the one that makes the first four mean what they were always supposed to mean.

References

• NIST SP 800-207, Zero Trust Architecture, August 2020.
• NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations.
• NIST SP 800-205, Attribute Considerations for Access Control Systems.
• CISA, Zero Trust Maturity Model Version 2.0, April 2023. https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf
• NSA, Zero Trust Implementation Guideline Phase Two, January 30, 2026.
• DoD, Zero Trust Reference Architecture v2.0, September 2022.
• DoD, Zero Trust Overlays, September 2024.