JADC2 Cross-Domain Data Sharing Requires a Data-Centric Substrate

The Joint All-Domain Command and Control concept and its execution under Combined JADC2 (CJADC2) require mission data to move across security domains, organizational boundaries, and coalition partners at operational tempo. The DoD CIO's JADC2 Implementation Plan and the more recent CJADC2 implementation directives identify cross-domain data sharing as the critical enabling capability. The constraint is not the network. The constraint is the architectural pattern that determines whether data can be released across a domain boundary without compromising the classification of the data at rest in the originating domain.

The historical pattern for cross-domain data sharing is the guard appliance. A guard sits between two security domains. The guard inspects data flows crossing the boundary, applies content-based rules, and releases or holds data. Guards are evaluated under the National Cross Domain Strategy and Management Office processes, deployed under accredited baselines, and operated under cross-domain solution authorities. The pattern is mature. The pattern does not scale to JADC2 tempo.

Where the guard pattern breaks at JADC2 tempo

A guard evaluates data at the boundary. The evaluation reaches the data content and the labels accompanying the data. The evaluation does not reach the originating mission context that determines whether release is appropriate for the specific operational moment. A guard that releases sensor data to a coalition partner based on the data's classification label cannot evaluate whether the operational situation at the moment of release is one in which the release supports the mission. The evaluation occurs at a layer that does not see the mission.

JADC2 operational tempo introduces additional pressure. The number of data flows that have to cross domains in a JADC2-enabled engagement runs into the thousands per minute across sensor systems, weapons systems, command nodes, and partner forces. A guard architecture that processes each flow through an appliance produces latency proportional to the appliance throughput. The latency exceeds the operational tempo by orders of magnitude for many flow categories.

The DoD Zero Trust Strategy 2.0 and the NSA Zero Trust Implementation Guideline Data Pillar v2 published April 2026 both name the data pillar as the architecturally correct enforcement layer for cross-domain release at tempo. The data pillar moves enforcement from the boundary to the object.

What ABAC over ZTDF actually moves

The Zero Trust Data Format (ZTDF) wraps mission data in a structure that carries the object's classification, handling caveats, release markings, and policy directly with the data. The Intelligence Community Trusted Data Format (IC-TDF) is the IC-specific variant. NSA Phase Two announcements in April 2026 named ZTDF and IC-TDF as the interoperability schemas across IC and DoD systems. The ZTDF-formatted object is the architecturally correct unit of cross-domain release.

Attribute-based access control evaluated at a policy enforcement point reaches the object at the moment of access. The PEP evaluates the principal's attributes (identity, clearance, citizenship, current mission assignment, operational role, partner status) against the object's release policy. The PEP either releases the wrapping key for unwrap on the requesting host or denies the request. The evaluation occurs at every read, not only at the boundary. The evaluation operates at the speed of the cryptographic operation, not at the speed of an appliance inspection.

Lattix Technologies implements this pattern through ABAC at the PEP, post-quantum key encapsulation under ML-KEM-768 and ML-KEM-1024, and Merkle-tree lineage in tamper-evident audit storage. A mission data object in ZTDF format travels across domain boundaries as ciphertext. The object is readable at the receiving domain only by a principal whose attributes satisfy the object's policy. The release event writes a lineage record. The audit chain establishes, cryptographically, who read what data at what mission moment.

The coalition pattern

Coalition cross-domain release is the variant of the problem where the receiving system is operated by a partner force outside the originating organization's security control. Coalition partners run their own identity infrastructure. Coalition partners apply their own classification frameworks. Coalition partners cannot be assumed to enforce the originating organization's controls.

ABAC over ZTDF objects produces a coalition pattern that does not depend on the receiving partner's enforcement. The object carries its own encryption and policy. The PEP that evaluates the access decision can be operated by the originating organization, by a trusted third party, or by a federated arrangement. A coalition partner that receives a ZTDF object reads the object only by presenting attribute claims that the originating organization's PEP accepts. The originating organization retains release authority on a per-object basis.

The pattern is the architectural answer to the Five Eyes interoperability requirements articulated through the NSA Phase Two announcements, the AUKUS data sharing arrangements emerging under Pillar II, and the broader coalition operational requirements that the DoD CIO has identified as JADC2 enabling capabilities.

What program offices should be doing in the next 90 days

Three operational priorities matter for program offices building toward JADC2 milestones.

The first is the data inventory against mission categories. The inventory identifies which data flows cross domain boundaries today, which flows are expected to cross domain boundaries under JADC2 timelines, and which classification frameworks apply. The inventory bounds the architectural change.

The second is the cross-domain solution architecture decision. Programs that depend on guard appliances for cross-domain release face throughput and tempo constraints that JADC2 milestones expose. Programs that move to ABAC-over-ZTDF data-centric release face a one-time integration cost and a sustainable architectural posture. The decision in 2026 determines the operational outcome in 2027 and beyond.

The third is the PKI and attribute authority architecture. ABAC requires a signed attribute claim. The signature requires an authority. The authority requires a trust framework. The trust framework requires interoperability with partner authorities. The work to establish these authorities is multi-year. Starting in 2026 produces operational capability by 2028. Starting in 2027 does not.

How the architecture aligns with DoD direction

The DoD Zero Trust Strategy 2.0 names data as a foundational pillar. The NSA Zero Trust Implementation Guidelines articulate the data pillar's enforcement at the object level. The DoD CIO's JADC2 Implementation Plan identifies cross-domain release at tempo as the critical capability gap. The CJADC2 implementation directives name interoperability with coalition partners as a primary requirement. The architectural pattern that satisfies all four directions is consistent. It is the pattern this post describes.

References

• DoD CIO, JADC2 Implementation Plan
• DoD Zero Trust Strategy 2.0
• NSA Zero Trust Implementation Guideline Data Pillar v2
• NSA, ZTDF and IC-TDF Phase Two Announcements
• Office of the Director of National Intelligence, IC-TDF
• NIST SP 800-207, Zero Trust Architecture
• National Cross Domain Strategy and Management Office