← Back to Blog
ZTDFTDFProcurementZero TrustDefense

TDF and ZTDF for Procurement Officers: What the Specification Actually Specifies

Lattix branded cover for TDF and ZTDF for Procurement Officers. /29 section number, TDF-to-ZTDF specification diff at the policy and key access layers, IBM Plex Mono on dark grid background, yellow accent on the procurement language that resolves to a configurable capability rather than a custom integration.

Two specifications are now reaching FY27 federal acquisition language with frequency. The Trusted Data Format (TDF) is the OASIS-standardized open format for binding policy to data objects through cryptographic enforcement. The Zero Trust Data Format (ZTDF) is the evolution of TDF that NSA Phase Two of the Zero Trust Implementation Guidelines named, along with IC-TDF, as the interoperability schema for federal data rights enforcement. Procurement officers building solicitation language for object-level data protection encounter both names. They differ in scope, lifecycle, and the cryptographic agility the specifications require.

The differences matter for two practical reasons. First, an RFP that names TDF accepts a different population of vendors than an RFP that names ZTDF. Vendors that ship against the older TDF specification do not automatically ship against ZTDF, and the migration cost falls on the integrator if the RFP is silent on the difference. Second, the evidence categories the specifications produce differ. A TDF-only solution produces a smaller evidence surface than a ZTDF solution, and the procurement language has to reach the evidence the program needs rather than the specification name the vendor markets.

What TDF binds

TDF is the foundational specification. The OASIS Virtru TDF technical committee published the format with the goal of binding policy to data objects in a way that travels with the object across systems and security domains. A TDF-wrapped object carries a policy, a wrapped data encryption key, and a reference to a key access service (KAS) that mediates the unwrap decision. A read against the TDF object reaches the KAS, which evaluates the requesting principal's attribute set against the policy and either releases the wrapped key or fails closed.

The specification names the cryptographic primitives at a specific moment in their lifecycle. The original TDF specification anchored on RSA and AES with the cryptographic posture that was current at publication. The format is extensible, and modern TDF implementations support post-quantum primitives, but the specification itself does not bind a procurement decision to a specific parameter set. An RFP that names TDF and leaves the cryptographic parameter set to the vendor receives proposals with varying postures.

TDF's policy evaluation model is principal-attribute against object-policy. The model handles the common release decision well. The model does not natively bind operations to a time window, a session, or a calling-tool context, and the lineage chain over policy decisions is implementation-specific rather than schema-defined. Mature TDF implementations supply both, but the specification itself does not require them.

What ZTDF binds that TDF does not

ZTDF extends TDF on three axes that procurement officers should track. The first is cryptographic agility. ZTDF requires the implementation to support algorithm migration without an object format change. The wrapped key under ZTDF can be migrated from a classical key encapsulation to a post-quantum one (ML-KEM-768 or ML-KEM-1024 under CNSA 2.0 for National Security Systems) as a configuration change at the KAS rather than a re-wrap of every object. The procurement implication is that an FY27 acquisition under CNSA 2.0 timing pressure converges naturally on ZTDF.

The second axis is the policy evaluation context. ZTDF binds the policy decision to a richer attribute set than the original TDF model. The principal attribute, the host attribute, the calling-tool attribute, the operation scope, and the time window all participate in the policy decision at the policy enforcement point. The procurement implication is that an FY27 acquisition that needs to evaluate release per operation, per tool, or per time window converges on ZTDF.

The third axis is the lineage evidence the specification produces. ZTDF binds the policy decision to a Merkle-tree lineage record in tamper-evident audit storage. The lineage chain is schema-defined, not implementation-specific. The procurement implication is that an FY27 acquisition that requires per-object, per-read evidence for HIPAA Security Rule, DORA Article 30, CMMC SC.L2-3.13.11, or NSA Zero Trust Implementation Guideline Data Pillar v2 satisfies the evidence expectation at the specification layer rather than the vendor-implementation layer.

What IC-TDF binds for intelligence community use

IC-TDF is the intelligence community profile of TDF. It binds the policy attribute schema to the IC's classification, dissemination control, releasability, and need-to-know categories. The policy attribute schema is the integration. An IC-TDF object travels across intelligence community systems and partner programs at the operational tempo the community requires because every implementation evaluates the same attribute set against the same policy schema.

For procurement officers outside the IC, IC-TDF is the model rather than the requirement. The schema-level integration that IC-TDF delivers inside the intelligence community is the integration that ZTDF delivers across the broader federal stack. A program office that names ZTDF in an FY27 solicitation acquires a capability that interoperates across departments, agencies, and partner programs at the schema level. The integration cost converges on the policy attribute schema rather than the wire format.

How to write the procurement language

Solicitations that name TDF as the wire format and ZTDF as the policy and key access model receive proposals that interoperate at the wire level and produce the evidence the program needs at the policy and lineage level. The procurement language reaches both. Solicitations that name only TDF receive proposals with varying cryptographic and lineage postures. Solicitations that name only ZTDF receive proposals from the subset of TDF vendors that have moved to the ZTDF policy and lineage model.

The cleanest language combines a wire-format requirement (TDF, with explicit ZTDF profile alignment), a cryptographic-agility requirement (algorithm migration without object format change, ML-KEM-768 or ML-KEM-1024 under CNSA 2.0 where applicable), a policy-evaluation requirement (attribute-based access control with principal, host, calling-tool, operation, and time window in the policy decision), and a lineage-evidence requirement (Merkle-tree lineage in tamper-evident audit storage with per-object, per-read records). The language describes a capability. The capability is procurable today against multiple vendors. The integration cost is the configuration of the policy attribute schema to the program's mission context, not the rebuild of the wire format and the policy decision model.

What this changes for vendor evaluation

A vendor that ships TDF natively and ZTDF as a forward-compatible profile responds to a solicitation that names both specifications without a translation layer. A vendor that ships a proprietary wire format and offers TDF or ZTDF as an export option carries integration debt that the schema-level naming was designed to eliminate. The evaluation question for the contracting officer is whether the wire format and the policy evaluation model the vendor ships against are the specifications the solicitation names, not whether the vendor can produce a conforming output for a specific RFP demonstration.

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 ZTDF natively and interoperates with TDF objects at the wire layer. The procurement language that names both specifications resolves to a configuration of the same capability rather than a custom integration per program.

The specifications converge because the federal acquisition system is converging. The procurement language that names them converges next.

References

← Back to Blog