← Back to Blog
Zero TrustData SecurityDefenseZTDFCross-Domain

Cross-Domain Solutions Modernize From Guard Appliances to Object-Level Release

Lattix branded cover for Cross-Domain Solutions Modernize From Guard Appliances to Object-Level Release. /27 section number, twenty-year guard lineage to ZTDF/IC-TDF object-level release, IBM Plex Mono on dark grid background, yellow accent on the object-level release decision point.

Cross-domain solutions have done critical work for two decades. A coalition operation requires intelligence to move from a higher-classification network to a partner network at a lower classification, and the guard appliance evaluates each release at the boundary. Filter, sanitize, audit, release. The pattern is mature, the operational record is strong, and the federal certification pipeline (UCDMO baseline, NSA Raise the Bar) gives program offices a defensible procurement path.

The pattern is also reaching its operational ceiling. Joint and combined operations under CJADC2, the NATO Federated Mission Networking initiative, and Title 50 partner integrations all describe a release tempo that exceeds the boundary-evaluation model. A guard appliance evaluates data at the moment it crosses the boundary. The operational moment the warfighter or intelligence consumer needs the data is downstream of the boundary, and the round trip back to the guard for a subsequent release decision does not fit the operational clock.

NSA Phase Two of the Zero Trust Implementation Guidelines, released January 30, 2026, names Zero Trust Data Format (ZTDF) and the Intelligence Community Trusted Data Format (IC-TDF) as the interoperability schemas for data rights enforcement across security domains. The procurement implication is not subtle. The release decision moves from the appliance at the boundary to the object itself, evaluated at a policy enforcement point at the speed of cryptographic operations rather than at the speed of an appliance round trip.

What guard appliances actually do, and where the model breaks

The guard appliance evaluates a candidate release against a release policy. Inputs include the source classification, the destination classification, the data content (against a regular-expression and signature library, sometimes a content classifier), and the release authorization. Outputs are a release decision and an audit record. The guard is a deterministic evaluator with a known threat model, certifiable behavior, and a clear control boundary.

The model breaks under three conditions that are now operationally common. First, the release authority needs to vary by attribute of the receiving party rather than by the destination network. A coalition partner with a Five Eyes attribute should reach data that an other-partner attribute should not, even when both partners share the same destination enclave. The guard evaluates the network, not the receiving principal's attribute set. Second, the release decision needs to remain valid only for a bounded window. A time-bounded release, a session-bounded release, or an operation-bounded release requires the policy decision to be re-evaluated at every read. The guard evaluates once, at the boundary, and the released bytes carry no further policy. Third, the release decision needs to be auditable per-object, not per-batch. Post-release accountability under HIPAA, GDPR, Title 50, and coalition agreements requires a per-object lineage chain that the guard's session-level audit does not produce.

What ZTDF and IC-TDF change

ZTDF and IC-TDF are not appliances. They are data formats with cryptographic enforcement bound to the object. The object carries a policy that names the attributes a requesting principal must satisfy. The object carries a wrapped data encryption key under a key access service. A read against the object reaches a policy enforcement point that evaluates the requesting principal's attribute set against the object's policy. A satisfying attribute set unwraps the key. A non-satisfying attribute set fails closed, the object remains ciphertext, and the access attempt produces a lineage record.

The release decision moves from the guard at the network boundary to the policy enforcement point at the moment of access. The object travels freely across security domains as ciphertext. The boundary becomes the place the ciphertext crosses, not the place the release decision happens. The operational tempo benefit is the round-trip elimination. The architectural benefit is the per-object, per-read, attribute-aware release decision that the guard model could not produce.

NSA Phase Two names ZTDF and IC-TDF as the interoperability schemas. The naming matters because it removes the integration cost that has historically blocked object-level release adoption in defense and intelligence environments. The schemas are the integration. A vendor that ships against ZTDF and IC-TDF natively interoperates with every other ZTDF and IC-TDF implementation across the federal stack. The procurement question for FY27 becomes whether the candidate solution implements the named schemas, not whether the vendor and the integrator can produce a one-off translation layer.

How the architecture composes with existing cross-domain investment

Guard appliances do not disappear under this architecture. The boundary still requires a controlled crossing point. The guard's role compresses. The release decision moves to the object. The boundary inspection function remains for content that has not yet been wrapped, for malware sanitization on inbound flows, and for audit accountability at the network egress. The architecture is composable with existing UCDMO-baselined guards rather than replacing them.

The procurement pattern that works is to wrap the data plane in ZTDF or IC-TDF and leave the boundary plane to the existing guard. The object travels as ciphertext, the guard inspects the ciphertext for accountability, and the policy enforcement point evaluates the release at the moment of access. The architecture inherits the certification posture of the existing guard for the boundary and the auditability posture of the policy enforcement point for the object. Each component carries the responsibility it is best suited to.

What this means for FY27 RFP language

Federal program offices building FY27 RFI and RFP language are converging on capability specifications that name ZTDF and IC-TDF, attribute-based access control at the policy enforcement point, ML-KEM key encapsulation parameter sets, and Merkle-tree lineage evidence. The convergence is visible in solicitations that previously named only the guard appliance vendor list. The language change is small. The architectural change behind the language change is substantive.

Vendors that ship against the ZTDF and IC-TDF schemas natively respond to the procurement language cleanly. Vendors that ship against proprietary formats and offer a translation layer carry the integration debt that the schema naming was designed to eliminate. The trajectory across FY27 and FY28 RFPs is toward solicitations that evaluate object-level release as a procurable capability with named standards, rather than as a custom integration exercise.

Lattix Technologies binds policy to data objects through attribute-based access control at the policy enforcement point, post-quantum key encapsulation under ML-KEM-768 and ML-KEM-1024, and Merkle-tree lineage in tamper-evident audit storage. The architecture implements the ZTDF and IC-TDF schemas natively. The procurement question is the only question the schemas were designed to answer.

References

← Back to Blog