The Federal Zero Trust Data Security Guide, published October 2024, revised May 2025, contains an acknowledgment that most Zero Trust vendors don't put in their marketing materials: the data pillar is explicitly identified as the least mature in most federal Zero Trust implementations. NIST SP 800-207, the foundational Zero Trust Architecture standard, states directly that Zero Trust Architecture does not protect data that has already left the system.
This is not a criticism buried in a footnote; it’s a design specification. Zero Trust was architected to control access events and network environments. The question of what happens to data after a legitimate access event — after the authenticated user downloads the file, forwards the attachment, or syncs the document to their device — was deliberately out of scope.
That scope limitation has been acceptable for years because the alternatives were operationally impractical. Persistent file-level controls required centralized rights servers, complex key management infrastructure, and end-user friction that killed adoption before it started.
That constraint no longer holds. File-centric Zero Trust — applying continuous contextual authorization at the file layer, not the network layer — is now the architecture that closes the gap NIST identified. And for defense contractors handling export-controlled technical data, it does something network Zero Trust cannot: it satisfies the EAR § 734.18(a)(5) encryption safe harbor, turning a security control into a legal protection.
🔌 See File-Centric Architecture in Action
Theodosian applies FIPS 140-3 validated per-file encryption with contextual access controls that persist through email, contractor devices, and offline environments; integrated with your existing Zero Trust infrastructure.
What Network Zero Trust Was Built to Protect
Zero Trust's core principle, "never trust, always verify," addresses the failure mode of implicit network trust. The castle-and-moat model assumed that anything inside the network perimeter was trustworthy. Zero Trust replaced that assumption with continuous verification: every access request, from any device, from any location, is authenticated and authorized before access is granted.
The controls that implement this are network and identity layer controls: identity verification through IdP integration, device posture assessment through endpoint management, microsegmentation to limit lateral movement, and least-privilege access to limit the scope of any single compromised credential.
These controls work. They have materially raised the cost of successful network-level attacks. But they share a common scope boundary: the access event.
Zero Trust verifies that the right person, on the right device, from the right location, is accessing the right resource. It does not, and was not designed to govern what that person does with the resource once access is granted. The file they download is theirs. Zero Trust's jurisdiction ended at the download event.
The Three Moments Zero Trust Loses Visibility
Moment 1: The Download to a Contractor Device
A subcontractor with legitimate authorization to a CUI repository downloads design files to work in a disconnected environment — standard practice for controlled program work. Zero Trust verified the access: right identity, compliant device, authorized network, and correct time window.
The file is now on the contractor's device. What Zero Trust cannot tell you: whether that device will remain compliant tomorrow, whether the file will be copied to a personal drive, or whether the contractor's authorization will remain valid when they attempt to open the file next week. The verification happened at download. The file's subsequent state is ungoverned.
Legitimate access today can become a security breach tomorrow if permissions aren't enforced at the file level. Ensure your exit process is airtight with our Contractor Offboarding File Security Checklist.
Moment 2: The Email Attachment
An engineer sends a technical specification to an approved subcontractor as an email attachment. Zero Trust controls on the email infrastructure verified the sender's identity and the recipient's domain. The attachment left the organizational boundary as an unprotected file.
From the moment it arrives in the recipient's inbox, the attachment is outside every Zero Trust control the sending organization can enforce. If the recipient's account is later compromised, if the attachment is forwarded to an unauthorized party, or if the file is opened on a device that's no longer compliant, Zero Trust has no mechanism to intervene. The access event it was responsible for was the email transmission, and that event was legitimate.
Moment 3: The Offline Work Session
A remote employee takes governed files offline to work during travel. The Zero Trust session has expired. The continuous verification that protects network access cannot operate without network connectivity.
The files are on a device, disconnected from every verification mechanism in the Zero Trust architecture, accessible to anyone who can unlock the device. Network Zero Trust has no answer for this scenario, because it requires a network to function.
The Data Pillar Gap
The Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications, and Data. Federal agencies and defense contractors have made substantial progress on the first four. The data pillar consistently lags — not because organizations are ignoring it, but because the tools available for the first four pillars don't extend to it.
A mature data pillar requires controls that operate at the data layer: encryption that travels with the file, an access policy that persists outside the network boundary, and authorization decisions made at the point of access — not at the point of login.
The controls most organizations apply to the data pillar today are container-level: folder permissions, application access controls, and network-level DLP. These are Identity and Network pillar controls applied to data containers — not data pillar controls applied to data. The distinction is the difference between governing who can reach the folder and governing what happens to the file once they do.
Most organizations struggle with the Data Pillar because they confuse container security with data security. Learn why this leads to Data Sprawl: The Compliance Risk Nobody Is Auditing.
What Does File-Centric Zero Trust Require?
File-centric Zero Trust applies the core principle — never trust, always verify — directly to the file layer. Every attempt to open a governed file triggers a real-time, contextual authorization decision. While the system can simultaneously evaluate these six key dimensions of trust, you define and configure the specific security parameters and permissions required to meet your organization's unique environment.
Identity and Role: Is this user authorized for this specific file? Evaluated against the IdP via RBAC/ABAC — not inherited from the folder's permission set.
Device Compliance: Is the device currently meeting the policy requirements? Evaluated at the moment of the open attempt — not cached from the last network authentication.
Geographic Restriction: Is this access attempt originating from within the permitted geographic boundary? Evaluated against the current location, not assumed from network access history.
Network and IP Context: Is the network environment consistent with authorized access? An access attempt from a coffee shop network, a foreign IP range, or an infrastructure provider not in the authorized list triggers a policy evaluation against explicit network parameters.
Time-Based Parameters: Is this access occurring within the authorized time window? Useful for contractor access, scoped to program duration or business hours requirements.
Behavioral Signals: Does this access pattern match the user's historical baseline? Bulk access across multiple files, access to repositories outside the normal scope, or access timing inconsistent with the user's pattern are evaluated against behavioral models, and anomalous patterns trigger an autonomous response.
When all six dimensions clear the policy check, access is granted. The file is decrypted in memory for the duration of the session. When the check fails on any dimension — expired authorization, non-compliant device, out-of-boundary location — access is denied. The file doesn't open. This is Zero Trust applied at the file layer: continuous, contextual, and enforced at the point of every access attempt rather than at network login.
When File-Centric Security Becomes a Legal Safe Harbor
For defense contractors managing ITAR or EAR-controlled technical data, file-centric Zero Trust delivers a legal protection that network-layer controls cannot.
Under 15 CFR § 734.18(a)(5), the Bureau of Industry and Security does not treat the sending, taking, or storing of technology as an export, reexport, or transfer when the technology is protected end-to-end using "FIPS 140-2 validated encryption or its successors." FIPS 140-3 is the current successor standard — meaning FIPS 140-3 validated encryption explicitly satisfies the EAR § 734.18(a)(5) requirement.
The operational implication: when a defense contractor shares ITAR or EAR-controlled design files with a domestic subcontractor using per-file FIPS 140-3 validated encryption, the file transfer does not constitute an export event under EAR. The controlled technical data is encrypted end-to-end with a CMVP-validated cryptographic module. BIS's position is that such transfers are outside the scope of the EAR's export controls.
This is file-centric Zero Trust operationalized as legal protection, not just security posture. The same per-file encryption that delivers continuous contextual authorization — preventing access from non-compliant devices, unauthorized locations, and expired credentials — simultaneously satisfies the encryption standard that triggers EAR's safe harbor.
Network-layer Zero Trust cannot deliver this protection. Encrypting the transmission channel (TLS) is not end-to-end file-level encryption under EAR § 734.18. The file must be encrypted at rest, in transit, and in use — with a FIPS 140-3 validated module — for the safe harbor to apply. That is a file-layer control, not a network-layer one.
File-centric Zero Trust doesn't just improve your posture; it satisfies federal encryption requirements for controlled data. See our full ITAR Encryption Compliance Guide for a breakdown of the § 734.18 safe harbor.
Anomalous Behavior and the Autonomous Response Layer
When behavioral signals deviate from baseline, file-centric Zero Trust doesn't wait for a human analyst to review a SIEM alert. Anomalous patterns — bulk file access across repositories, access to files outside the user's authorization scope, access from geographic or network contexts inconsistent with the user's baseline — trigger an autonomous response.
Access is suspended, and the security team is alerted. The response fires at the moment of detection, not when an analyst reviews the log.
This is the "assume breach" principle applied at the file layer. Network Zero Trust assumes that breaches will occur at the network layer and designs controls to limit lateral movement after initial access. File-centric Zero Trust assumes that breaches will occur at the file layer — that files will be accessed by unauthorized actors using valid credentials, or that authorized users will behave in ways inconsistent with their authorization — and responds autonomously when those patterns appear.
The behavioral layer is what converts file-centric Zero Trust from a passive access control architecture into an active threat response capability. The contextual checks evaluate every individual access attempt. The behavioral layer evaluates patterns across access attempts — and triggers an autonomous response when those patterns indicate a threat.
Implementing Without Re-architecting Your Zero Trust Architecture
File-centric Zero Trust integrates at the data layer, not the network layer. The existing Zero Trust architecture — identity provider, device management, network segmentation, SIEM — stays in place. File-level controls are additive, not replacements.
Integration works through existing IdP infrastructure: the same identity and device signals that inform network Zero Trust decisions are consumed by file-layer policy. A user who fails device compliance in your network Zero Trust architecture will also fail the device compliance check on governed files, because both are evaluating the same device posture signals from the same endpoint management system.
For contractors managing CMMC compliance alongside Zero Trust implementation, the file-layer controls that satisfy SC.3.177, SC.3.187, and MP.2.121 operate within the existing Zero Trust architecture. They extend the verification principle to the data pillar — the pillar NIST identified as least mature — without requiring a change to the network or identity layer controls that have already been deployed.
The implementation footprint for a proof of concept is a defined file population — a CUI repository, an ITAR design library, a contractor collaboration folder — configured, protected, and tested in a 14-day pilot. The files are protected, and the existing infrastructure is unchanged.
If contractor access governance is part of your Zero Trust data pillar strategy, the Contractor Offboarding File Security Checklist maps the specific controls your C3PAO assessor will ask about.
🔎 Test File-Centric Zero Trust Against Your Own File Population
Theodosian's 14-day pilot scopes to a defined file set — CUI repository, ITAR design library, or contractor collaboration folder — and demonstrates per-file contextual authorization integrated with your existing Zero Trust Architecture. No migration. No infrastructure change.
FAQ: File-Centric Zero Trust
What is file-centric Zero Trust?
File-centric Zero Trust applies the Zero Trust principle — never trust, always verify — at the file layer rather than the network layer. Every open attempt on a governed file triggers a real-time contextual authorization decision across six dimensions: identity/role, device compliance, geographic location, network context, time parameters, and behavioral signals. Access is granted only when all dimensions clear the policy. When they don't, access is denied — regardless of where the file is, what device is attempting access, or whether the user's network credentials are valid.
Does Zero Trust protect files after they've been downloaded?
No. Network Zero Trust governs access events and network environments. Its jurisdiction ends at the download event. Once a file is on a contractor's device, in an email attachment, or on removable media, it is outside every control that network-layer Zero Trust enforces. The Federal Zero Trust Data Security Guide and NIST SP 800-207 both identify this as a known scope limitation of network-layer Zero Trust, positioning the data pillar as a separate requirement.
What is EAR § 734.18, and how does it apply to file encryption?
EAR § 734.18(a)(5) is a safe harbor provision in the Export Administration Regulations. It specifies that the sending, taking, or storing of export-controlled technology does not constitute an export, reexport, or transfer when the technology is protected end-to-end using FIPS 140-2 validated encryption or its successors (including FIPS 140-3). For defense contractors sharing technical data with subcontractors, per-file FIPS 140-3 validated encryption can mean that the file transfer falls outside EAR export control requirements — provided the encryption is end-to-end at the file layer, not just at the transmission channel.
How is file-centric Zero Trust different from IRM or DRM?
Traditional IRM and DRM architectures apply policy controls to files but typically rely on centralized rights servers for key management and policy enforcement. File-centric Zero Trust uses decentralized, zero-knowledge key management — no master key, no central rights server, no single point of compromise. It also evaluates contextual authorization in real time on every access attempt, rather than applying static policy assignments at the point of rights assignment. The behavioral anomaly detection and autonomous response layer — which fires on patterns across access attempts rather than individual access events — is not a feature of traditional IRM architectures.
Does file-centric Zero Trust work with existing Zero Trust infrastructure?
Yes. File-centric controls integrate at the data layer, consuming identity and device signals from existing IdP and endpoint management infrastructure. The network Zero Trust architecture — authentication, device compliance, microsegmentation — remains in place. File-layer controls extend the verification principle to the data pillar without requiring changes to the network or identity controls already deployed. The two layers operate in parallel: network Zero Trust governs access to environments and systems, file-centric Zero Trust governs access to individual files within and beyond those environments.