Persistent data protection is a class of control that keeps an access policy attached to a data object for the entire life of that object, including after the object has been copied, forwarded, or downloaded onto a device the originating organization does not manage. The protection is cryptographic rather than administrative: the payload is encrypted, the policy is bound to the key material, and opening the object requires a fresh authorization decision rather than mere possession of the file. Persistent data protection is the mechanism that lets a data owner retain control after data leaves.
What makes data protection persistent
Data protection is persistent when three properties hold at once. Removing any one of them returns the control to the boundary it was meant to escape.
The policy is carried inside the object. The rules governing who may open the object, under what conditions, and until when are written into the protected file and cryptographically bound, so editing them invalidates the binding. Copying the file copies the rules. A policy stored only in the system the file came from stops applying the moment the file is elsewhere.
The key is not in the object in usable form. The content encryption key is wrapped to a key service rather than derived from a password the recipient holds. Possession of the file is therefore not possession of the plaintext, which is what separates persistent protection from a password-protected archive.
The decision is made per request, against current attributes. Each open triggers an evaluation at a policy decision point (PDP), and a policy enforcement point (PEP) releases or withholds the unwrapped key at decrypt time. Because evaluation happens at request time rather than distribution time, a clearance change or a revocation reaches copies distributed months earlier.
How to protect a file after it leaves the organization
Protecting a file after it leaves the organization requires encrypting the file before distribution and binding an access policy to the key that opens it. The sequence is consistent across implementations: classify the object and attach its attributes; encrypt the payload with a content encryption key; bind the access policy cryptographically so a modified policy breaks the binding; wrap the key to a key service so it never travels with the file; then distribute by any path. On each open, the recipient's client requests an unwrap, the decision point evaluates attribute-based access control (ABAC) rules against current attributes, and the enforcement point releases the key or denies.
Approaches differ in what holds the control after the file leaves, which is the only question that matters here.
| Approach | What holds the control | Effect after the file leaves | Revocable after download |
|---|---|---|---|
| Password-protected archive | Possession of a password shared out of band | None; the password is a bearer credential | No |
| Expiring share link | The hosting service, at fetch time | Control ends at the moment of download | Only before download |
| View-only portal with download disabled | The hosting application's renderer | Strong inside the portal, absent once content is captured | Not applicable |
| Full-disk or storage-tier encryption | Custody of the volume or bucket key | None; the file is plaintext once read out of the volume | No |
| Enterprise DRM and IRM | A cooperating rendering application plus a license service | Rights travel with the file and are checked at each open | Yes, subject to cached license lifetime |
| Object-level encryption with bound policy (TDF, ZTDF) | The policy bound into the object plus a key service | Policy travels with the object and is evaluated at every decrypt | Yes, at the next key request |
The object format that carries the policy is covered in What Is Trusted Data Format, and the decrypt sequence in How TDF Enforces Access Policy at Decrypt Time.
Enterprise DRM and IRM as the ancestors of persistent data protection
Enterprise digital rights management (EDRM) and information rights management (IRM) are the direct ancestors of persistent data protection, and they solved the hard part of the problem first.
The Digital Property Rights Language originated at Xerox PARC in the mid-1990s under Mark Stefik. ContentGuard, founded by Microsoft and Xerox in 1999, developed that work into the eXtensible Rights Markup Language (XrML), first released in 2001, which became the basis for Part 5 of MPEG-21, the Rights Expression Language standardized as ISO/IEC 21000-5. A parallel and still active line produced the Open Digital Rights Language, whose Information Model 2.2 became a W3C Recommendation on 15 February 2018. Commercial IRM followed the same idea into the enterprise through Microsoft Rights Management Services and its successors, Adobe's rights management server products, and specialist vendors including Fasoo, Seclore, and NextLabs.
What that generation established is still correct: a machine-readable rights expression can be carried with content, a license service can be consulted at each open, rights can expire, and access can be withdrawn after distribution. Those are the load-bearing ideas of the category.
Where classical EDRM and IRM stopped is a matter of architecture rather than quality. Enforcement depended on a cooperating rendering application, so coverage was strong for office documents and PDFs and weak for arbitrary file types, database extracts, and model training corpora. Cross-organization identity was hard before federation matured, which made external sharing the difficult case rather than the default one. Rights expression languages standardized the vocabulary, but vendor implementations did not interoperate, so a protected object was usually readable only inside one vendor's client. Persistent data protection today pursues the same objective with federated identity, ABAC in place of per-user rights lists, and an open object format that more than one implementation can read.
Persistent data protection compared with conventional encryption
| Question | Encryption at rest and in transit | Persistent data protection |
|---|---|---|
| What the control protects | The storage medium and the transport channel | The individual data object |
| What grants access | Possession of the key | A policy decision evaluated at request time |
| Scope of one successful access | Everything encrypted under that key | The one object whose policy evaluated to allow |
| Conditions that can be enforced | None beyond key possession | Subject, device, environment and geography, purpose of use, network posture, risk, object attributes |
| Effect of revocation after distribution | None without re-encrypting and redistributing | The next key request is denied |
| Evidence produced | Key usage at the service, if instrumented | Per-object decisions with reasons, policy version, and object identifier |
Encryption is the mechanism inside persistent data protection, not an alternative to it. Conventional encryption answers one question, whether the requester holds the key. Persistent data protection answers a policy question at every request and can change the answer after distribution.
What persistent data protection cannot do
Persistent data protection has hard limits, and a reference that omits them is not usable for architecture decisions.
Persistent data protection does not reach plaintext after an authorized release. Once a permitted user opens an object, the rendered content can be photographed, screen-captured, retyped, summarized by a local tool, or copied into an unprotected document. The control governs release of the key, not the behavior of a person who was legitimately given the content.
Persistent data protection does not remove the availability dependency. Evaluating a policy and unwrapping a key requires a reachable decision service. Disconnected operation requires pre-provisioning decisions or keys, and every pre-provisioned window is a window in which revocation has not yet taken effect. Fail-closed defaults deny rather than allow when the service cannot be reached.
Persistent data protection does not correct bad attributes. A policy that references a stale clearance, an over-broad group, or a wrong classification is enforced faithfully and wrongly. Attribute governance is the recurring operational cost of the model, which is why classification practice is a prerequisite, as set out in Data Classification as the Foundation of Zero Trust.
Persistent data protection does not reach data already distributed in the clear, and it does not defeat a compromised endpoint at the moment of authorized use. Objects protected from creation are governed; copies made before adoption are not. If an attacker controls the device of a user whose policy evaluates to allow, the attacker sees what the user sees.
Frequently asked questions
What is persistent data protection?
Persistent data protection is a control model in which an access policy stays cryptographically bound to a data object wherever that object travels. The payload is encrypted, the policy is bound to the key, and each attempt to open the object triggers a fresh authorization decision. Because the decision happens at open time rather than at distribution time, protection continues after the object leaves the originating environment.
How can I protect a file after it leaves my organization?
Encrypt the file before distribution, bind an access policy to it, and wrap the content encryption key to a key service instead of shipping the key with the file. Every recipient open then requires a live authorization decision against current attributes. Share links, password-protected archives, and view-only portals all end their control at the moment of download, so they do not meet this requirement.
What technologies let data owners retain control after data leaves?
Three families do this in production: enterprise DRM and information rights management, which check per-document rights inside a cooperating application; object-level encryption formats with bound policy, such as Trusted Data Format and Zero Trust Data Format, which evaluate a policy at every decrypt; and key management arrangements such as hold-your-own-key, which withdraw access at key or tenant granularity rather than per object.
Is persistent data protection the same as DRM?
Not the same, but directly descended from it. Enterprise DRM established the core ideas: rights carried with content, a license check at each open, and revocation after distribution. Persistent data protection generalizes those ideas beyond cooperating document applications, replaces per-user rights lists with attribute-based access control, and uses open object formats so that more than one implementation can read a protected object.
Does persistent data protection stop screenshots and photographs?
No. Once a policy evaluates to allow and content is rendered to an authorized user, that content can be photographed, screen-captured, or retyped. Watermarking and screen-capture blocking raise effort and improve attribution but do not prevent capture. Persistent data protection governs release of the key and records who obtained access, not what a legitimate holder does afterward.
How Lattix implements persistent data protection
Lattix implements persistent data protection as cryptographic enforcement at the data object. The Lattix policy decision point evaluates ABAC across subject, device, environment and geography, purpose of use, network posture, risk, and data-object attributes, then returns a signed, short-lived decision carrying allow or deny, the reasons, the policy version hash, and the object identifier. The policy enforcement point acts at decrypt time, so enforcement survives whatever application or storage service sits in the path. Defaults are fail-closed and revocation propagates to deny. Content identifiers and Merkle-tree lineage make decision history queryable per object. The same posture deploys across cloud, regional hub, tactical edge, and air-gapped environments. The revocation case is covered in How to Revoke Access to a File Someone Already Downloaded.