Zero Trust Without Data Labels Is a Network Diagram

The zero trust architecture passed review. Then an analyst exported a report to a spreadsheet, mailed it to a contractor, and the label stayed behind.

That is the failure mode the policy documents are aiming at, and it is not a network problem. Every control in the stack assumed the data would stay where it was classified. The data moved, which is what data does.

What the guidance actually asks for

OMB memorandum M-22-09, published in January 2022, set the federal direction. It describes five pillars: identity, devices, networks, applications and workloads, and data. The first four got the budget and the dashboards. The fifth is where the hard work sits, and it is the one most often represented by a data loss prevention tool that blocks email attachments.

CISA's maturity model followed the same structure, and it is honest about the ordering problem. You cannot enforce a policy about data you have not classified, and you cannot classify data without knowing where it lives and who owns it.

The change of administration in January 2025 did not repeal the direction. It changed the rhetoric around it. The technical requirements are still in the guidance, still in the contracts, and still in the assessments that decide whether a system gets authorized.

A label that does not travel is a filing system

Most organizations classify data at the perimeter of a system. A repository is marked CUI. A database is marked sensitive. A share is marked internal.

That works until the data leaves the container. Then the classification is whatever the person handling it remembers, and the person handling it is often a tool.

The test is simple. Take a record and follow it through five hops: a copy to a laptop, an export to CSV, an attachment in a ticket, a paste into a model prompt, a snapshot in a backup. At each hop, can the system still answer what the record is and who may see it.

If the answer depends on a human remembering, the label is documentation, not a control.

A classification that does not survive the copy is a comment, not a control.

Everything downstream depends on this

Four things become possible only after the label travels.

Policy enforcement at the point of use. Not "this share is sensitive" but "this record is CUI, this principal has the authorization, this action is permitted, and here is the decision." That is what a policy engine needs as input.

Key management that means something. If you can map a record to the key that protects it, you can answer an auditor's question about which keys protected which data at which time. If keys are per database and records move between databases, you cannot.

Retention that is enforceable. The hardest deletion request is the one where nobody knows where the copies are. Label driven retention makes deletion a query rather than an archaeology project.

Agent permissions. This is the one that will bite in 2025 and 2026. An agent with access to a corpus does not read one record and stop. It reads, combines, and acts, at machine speed, across whatever the token permits. If the records do not carry their own handling rules, the agent's permission is the only control, and permissions are coarse.

The practical build, in order

Classify at creation, not at rest. The system that generates the record knows what it is. Capture that at write time and carry it in the metadata, not in the filename.

Define the handling rules per class, and make them machine readable. Who may read, where it may be stored, how long it may be kept, whether it may be sent to an external model. If the rules live in a policy PDF, they will be applied by humans inconsistently and audited by humans slowly.

Enforce at egress. The boundary that matters is where data leaves your control: an API call, an upload, a prompt, a backup to a region you did not intend. Put the check there, and log the decision.

Prove it with keys. The strongest evidence that a control worked is cryptographic. Which key, which custodian, which rotation. That evidence survives a change of personnel, which policy documents do not.

The uncomfortable part for contractors

In GovCon, this is becoming a contract question rather than an architecture preference. CMMC Level 2 requires controls over how CUI is handled, and the assessment asks you to demonstrate that the controls operate, not that they are documented.

The shared responsibility model makes this harder, not easier. In a government cloud environment, the provider secures the infrastructure and you secure the configuration, the identity, and the data. The line moves with the service, and it moves again when the provider ships a new feature.

I have watched federal programs spend months on a boundary diagram that was obsolete the week it was signed, because the diagram described the network and not the data.

The end state is not a product you buy. It is a property of your records: they know what they are, they carry that knowledge, and the systems that touch them can read it and enforce it.

That is a multi-year build for any organization with legacy systems, and it starts with one unglamorous decision. Pick the data class that matters most, follow it through every hop, and write down where the label falls off. The places it falls off are your road map.

Zero trust is not a perimeter you rebuild. It is a property you attach to the data and then have to keep attached.