Trusted Data Format (TDF) is an open specification for an encrypted data object that carries its own access policy. A TDF object holds an encrypted payload and a JSON manifest. The manifest records how the payload was encrypted, where to request the decryption key, and which attributes a requester must hold to receive that key. The policy is cryptographically bound to the key, so altering the policy invalidates the binding and the key request fails. Access is decided at the moment of decryption, not at the moment of storage or transfer, which means a TDF object stays governed after it leaves the network that produced it.
What a TDF object contains
A TDF object is a container, by default a ZIP archive using the .tdf extension, holding two parts: the encrypted payload and a manifest.json file.
The manifest carries several structures defined by the OpenTDF specification:
| Manifest structure | What it carries |
|---|---|
payload | Payload type, reference, protocol, encryption state and MIME type |
encryptionInformation | The access policy and everything needed to unlock the payload |
method | The symmetric algorithm, the initialization vector, and whether the payload is streamable. Implementations commonly use AES-256-GCM |
keyAccess | An array of key access objects, each carrying the key access server URL, the protocol, the wrappedKey, and a policyBinding object with an algorithm and a hash |
integrityInformation | A root signature, a segment hash algorithm and per-segment hashes, so modification of a single bit in the encrypted payload is detectable |
assertions | An optional array of verifiable statements about the object or its payload, each with its own binding |
The data encryption key never sits in the manifest in plaintext. It is wrapped to the public key of a key access server, and the manifest records only the wrapped form.
How policy binds to the data object in TDF
Policy binding is the mechanism that makes TDF different from a file that merely happens to be encrypted. During encryption, the client builds a policy object naming the attributes required for access, then computes a keyed hash over that policy using the data encryption key. That value is stored as policyBinding inside the key access object.
Because the binding is computed with the data encryption key, only a party that already holds the key can produce a valid binding. A requester who edits the policy to widen access breaks the hash. The key access server recomputes the binding after unwrapping the key and refuses the request when the value does not match.
The practical effect is that policy and ciphertext are one artifact. Copying the file copies the policy. Emailing it, syncing it to unmanaged storage, or writing it to removable media carries the policy along unchanged.
What happens at decrypt time
Decryption of a TDF object is a request, not a local operation. The sequence runs as follows.
- The client reads the manifest and extracts the key access object and the policy.
- The client generates an ephemeral key pair and builds a signed rewrap request containing the wrapped key, the policy, the policy binding and its own public key.
- The key access server authenticates the caller against an identity provider and unwraps the data encryption key with its private key.
- The key access server validates the policy binding against the supplied policy and the unwrapped key.
- A policy decision point evaluates the requester's attributes against the policy using attribute-based access control (ABAC).
- On allow, the key access server rewraps the data encryption key to the client's ephemeral public key and returns it. On deny, no key material is returned.
- The client unwraps the key, verifies payload integrity against the segment hashes, and decrypts.
Key access objects can be split across several key access servers operated by different organizations. In that configuration every participating server must authorize before the payload key can be reconstructed. A fuller walkthrough of the decision itself appears in How TDF Enforces Access Policy at Decrypt Time.
Where TDF is specified
TDF originated inside the United States intelligence community. The Office of the Director of National Intelligence published a Trusted Data Format specification built on XML, with version 3.0 dated 6 September 2013. That lineage is the source of the term Intelligence Community Trusted Data Format (IC-TDF).
The current JSON encoding is specified by the OpenTDF project, which publishes schema, protocol and concepts documentation in a public repository. Zero Trust Data Format (ZTDF) is a profile built on that specification for allied and coalition use, specified in the CCEB publication ACP 240. The three names describe different things and are covered separately in OpenTDF, TDF, and ZTDF: How the Three Terms Relate.
What TDF does not do
A reference on TDF is incomplete without its boundaries. TDF does not do the following.
TDF does not control plaintext after release. Once the key access server authorizes a request and the client decrypts, the plaintext exists in that client's memory. TDF does not prevent a screenshot, a retype, a photograph of the screen, or a copy into an unprotected file. Persistent control means the ciphertext stays governed, not that released content becomes unrecoverable.
TDF does not work without a reachable key service. Every decrypt requires a rewrap call. Where the key access server is unreachable and no offline provision has been made, access fails closed. That is correct behaviour, and it is also an availability dependency that has to be engineered for disconnected and tactical use.
TDF does not classify data. The specification carries whatever attributes the producing system asserts. Wrong labels produce wrong decisions. Classification quality is an upstream problem, covered in data classification as the foundation of zero trust.
TDF does not replace transport or storage encryption. TLS and disk encryption defend different layers and remain necessary. The division of labour is set out in data-centric zero trust and why policy travels with the data.
TDF does not protect against a compromised key access server. A server that unwraps keys is a trust anchor. Key splitting across independent servers reduces the blast radius of a single compromise, and does not eliminate the need to protect the servers themselves.
How Lattix implements Trusted Data Format
Lattix builds cryptographic enforcement on TDF objects with a policy decision point that evaluates ABAC across subject, device, environment and geography, purpose of use, network posture, risk, and data-object attributes. The decision returned is signed and short-lived, and carries allow or deny, the reasons, the policy version hash, and the object identifier. The policy enforcement point (PEP) acts at decrypt time, so enforcement survives whatever service sits in the path. Defaults are fail-closed and revocation propagates to deny. Content identifiers and Merkle-tree lineage records make decision history queryable. The same posture deploys across cloud, regional hub, tactical edge and air-gapped environments, and key wrapping supports post-quantum key encapsulation with ML-KEM-768 and ML-KEM-1024.
Frequently asked questions
What is Trusted Data Format?
Trusted Data Format is an open specification for an encrypted data object that carries its own access policy inside a JSON manifest. The manifest records the encryption method, the wrapped data encryption key, the key access server to contact, and a cryptographic binding between the policy and that key. Access is evaluated when a client requests the key, which is the moment of decryption.
What is TDF in cybersecurity?
In cybersecurity, TDF is a data-centric zero trust control. Conventional controls protect a location: a network segment, a share, an application. TDF protects the object. Because the policy and the ciphertext are one artifact, the control point moves with the file and applies wherever the file is opened, including on systems the originating organization does not operate.
How does TDF protect files?
TDF encrypts the file payload with a symmetric data encryption key, wraps that key to a key access server's public key, and stores a keyed hash binding the access policy to the key. Opening the file requires a rewrap request that the key access server authorizes against the requester's attributes. Without a successful authorization, no key material is released and the payload stays ciphertext.
Is TDF the same as digital rights management?
TDF and enterprise DRM overlap in intent and differ in construction. Both keep control after distribution. DRM products typically depend on a controlled viewer application to restrict printing, copying and forwarding. TDF specifies an open object format and a key release protocol, and leaves post-decrypt handling to the consuming application. NSA zero trust guidance groups both under data rights management schemas.
Does TDF require internet access to open a file?
Opening a TDF object requires reaching the key access server named in the manifest, over whatever network path connects the two. That can be the public internet, a private enclave network, or a hub inside an air-gapped environment running its own key service. Where no path exists and no offline key provision has been made, the decrypt request fails closed.
What file types can TDF protect?
TDF is payload agnostic. The manifest records a MIME type and treats the payload as opaque bytes, so documents, images, archives, database exports, message bodies and streamed content are all valid payloads. Applying TDF to structured records and to fields within them is an implementation choice rather than a format limitation.