How to Revoke Access to a File Someone Already Downloaded
Access to a file someone already downloaded can be revoked only if that file was encrypted with an access policy bound to it before distribution, so that opening it requires a live key release. Revocation then works by changing the answer the key service returns: the next request to unwrap that object is denied, and the ciphertext on the recipient's disk becomes unopenable. Revocation does not delete the file, and it does not reach plaintext the recipient already extracted. It prevents future key release. That is the whole of the mechanism, and stating its edge honestly is what makes it usable.
Revocation acts on key release, not on the file
Revocation of a downloaded file is a decision-service operation, not a file operation. The originating organization has no reach into a disk it does not control, so nothing is deleted, overwritten, or clawed back. What the organization controls is the response to the next key request.
Three conditions must have been true at distribution time for revocation to be possible:
The payload was encrypted before it left. A file distributed in the clear cannot be revoked by any mechanism, because nothing about opening it requires the originator's participation.
The content encryption key was wrapped to a key service rather than shipped with the file. If the recipient holds the key directly, as a password or a private key the file was encrypted to, revocation is impossible; the recipient can open the file indefinitely with no further contact.
Opening requires a fresh authorization decision. A key service that hands out a permanent key on first request has performed distribution, not enforcement. Revocation requires that each open, or each bounded interval, produce a new decision that current policy can change.
Where those conditions hold, revocation is a policy edit whose effect appears at the next unwrap. Where they do not hold, no product revokes the file, and a claim to the contrary describes link expiry on a copy that has already been downloaded.
What happens when a revoked file is opened
A recipient opening a revoked object sees a failure that originates at the key service, not at the file.
- The recipient's client reads the protected object and finds the wrapped content encryption key and the bound policy.
- The client sends an unwrap request carrying the object identifier, the requester's identity assertion, and the device and environment attributes it can attest.
- The policy decision point (PDP) evaluates attribute-based access control (ABAC) rules against the current policy version, which now excludes this requester or this object.
- The PDP returns deny, with the reason and the policy version that produced it.
- The policy enforcement point (PEP) withholds the unwrapped key, and the denial is recorded against the object identifier.
The recipient still possesses the file and no longer possesses any path to its plaintext. The full decrypt sequence, including the allow case, is set out in How TDF Enforces Access Policy at Decrypt Time.
Dynamic revocation models compared
Several distinct mechanisms are described as revocation. They differ in what is actually withdrawn, how long the withdrawal takes to bite, and how much collateral damage it causes.
| Model | What is withdrawn | Time to take effect | Granularity | Principal limitation |
|---|---|---|---|---|
| Share-link expiry or deletion | The ability to fetch a new copy | Immediate for new fetches | Per link | No effect on copies already downloaded |
| Account or identity disablement | The subject's ability to authenticate | Next authentication, plus any token lifetime | Per user, across everything | Coarse; does not remove one file from one recipient |
| Rights-management license revocation | The per-document use license issued to a recipient | Next license request, after any cached license expires | Per document per user | Cached licenses grant a window of continued access |
| Cryptographic erasure of a key | The key itself, permanently | Immediate | Per key, so per everything encrypted under it | Destroys access for every legitimate holder too |
| Policy change with per-request evaluation | The allow decision for a named subject or object | Next unwrap request | Per object, per subject, per condition | Requires the decision service to be reachable |
| Re-encryption or revocable attribute-based encryption | The mathematical ability of a revoked key to decrypt | On re-encryption or key update | Per attribute or per user | Cost of re-encrypting or re-issuing key material at scale |
Policy change with per-request evaluation is the model that answers the specific question of revoking one file from one recipient without disrupting anyone else. Cryptographic erasure is decisive but blunt, and it is the right tool for retiring a whole data set rather than correcting a single misdirected share. Key custody choices determine which of these are even available, a topic developed in Key Management for Data-Centric Security.
Cached licenses and offline windows
Revocation is rarely instantaneous, and the gap has a specific cause: clients cache the artifact that grants access so that documents open without a round trip.
Microsoft documents this behavior plainly for files encrypted with Purview sensitivity labels. Revoking a file prevents future access, but a user who has already opened it retains access until their use license for that file expires, and the default use license validity period is 30 days. Revocation is also keyed to the file's content identifier, so copies carrying a different content identifier are not covered by the same action. Those are engineering trade-offs rather than defects, and every persistent protection system makes some version of them.
The design lever is license or decision lifetime. Short lifetimes make revocation take effect quickly and require the decision service to be reachable often. Long-lived cached licenses support disconnected work and widen the window in which a revoked recipient can still open the file. Choosing a lifetime is choosing how long a revocation may take to land. Fail-closed defaults deny once the cached decision expires rather than falling back to allow.
What revocation cannot reach
Revocation prevents future key release. It does not reach any of the following, and no implementation changes this.
Revocation does not reach plaintext already extracted. If the recipient opened the file and saved a copy as an unprotected document, exported it, or pasted its contents elsewhere, that derived content is outside the protected object and outside the policy that governed it.
Revocation does not reach screenshots, photographs, printouts, or retyped text. Content rendered to an authorized human can be captured by that human. Watermarking and screen-capture controls raise effort and improve attribution; they do not prevent capture.
Revocation does not reach content already ingested by another system. If a protected file was decrypted and its text loaded into a search index, a training corpus, or a retrieval pipeline, the copy inside that system is governed by that system's controls, not by the original object's policy.
Revocation does not reach access that already happened. Revocation is prospective: it bounds future exposure and produces evidence of past access, and it does not undo a disclosure that has already occurred.
Revocation is therefore a containment control, not an eraser. It bounds the window and the blast radius, converting an irreversible mistake into a limited one. The same distinction governs how boundary controls behave once a file is on a recipient's disk, examined in What Happens to DLP Controls After the File Is Downloaded.
How to make revocation work in practice
Revocation capability is decided before distribution, not after the incident. Five practices determine whether the option exists when it is needed.
Protect objects at creation rather than at egress, so any path a file takes carries the bound policy. Objects protected only when they cross a monitored gateway are unprotected on every path the gateway does not see.
Set decision and license lifetimes deliberately, and document the resulting revocation latency as a stated figure rather than an assumption.
Bind policy to attributes rather than enumerated recipient lists, so revoking a role, a project, a clearance, or a jurisdiction reaches every object those attributes govern in one action.
Preserve object identity across copies, because revocation acts on an object identifier. Systems that assign a new identifier when a file is re-saved break the link between the revocation and the copies in circulation.
Record denials as well as approvals. Attempted-access records after a revocation are among the most useful signals available for working out who still holds the file.
Frequently asked questions
Can you revoke access to a file someone already downloaded?
Yes, if the file was encrypted with a bound access policy before it was distributed and opening it requires a live key release. Revocation then denies the next unwrap request, leaving the recipient with unopenable ciphertext. If the file was distributed in the clear, or the recipient holds the decryption key directly, revocation is not possible by any mechanism.
How does dynamic revocation of encrypted data work?
Dynamic revocation works by evaluating the access policy at every decrypt request rather than once at distribution. The protected object carries a bound policy and a key wrapped to a key service. Changing the policy changes the outcome of the next unwrap. Because the file itself is unchanged, revocation requires no contact with the recipient's device and no ability to modify what is stored there.
How long does revocation take to take effect?
Revocation takes effect at the next authorization request, so the delay equals the remaining lifetime of any cached decision or use license. Microsoft, for example, documents a default use license validity of 30 days for files protected with sensitivity labels, during which a user who already opened a file retains access. Shorter decision lifetimes shorten revocation latency and increase dependence on a reachable decision service.
Does revoking a file delete it from the recipient's device?
No. Revocation is a decision-service operation and reaches nothing on a device the originating organization does not control. The encrypted file remains on the recipient's disk. What changes is that the key request required to open it is denied, so the file becomes ciphertext with no available path to plaintext.
Can revocation stop someone who already copied the text out?
No. Once an authorized recipient has decrypted an object, any plaintext they extracted, screenshotted, printed, retyped, or pasted into another document is outside the protected object and outside its policy. Revocation bounds future access and produces a record of attempts; it does not reach content that has already left the protected container.
How Lattix implements revocation
Lattix treats revocation as an ordinary consequence of per-request evaluation rather than a separate feature. The Lattix policy decision point evaluates ABAC across subject, device, environment and geography, purpose of use, network posture, risk, and data-object attributes, and returns a signed, short-lived decision carrying allow or deny, the reasons, the policy version hash, and the object identifier. Because decisions are short-lived, revocation propagates to deny without waiting for a long cached license. The policy enforcement point acts at decrypt time, so a denial holds regardless of which application or storage service is in the path, and defaults are fail-closed. Content identifiers and Merkle-tree lineage make post-revocation access attempts queryable per object. The broader category this mechanism belongs to is described in What Is Persistent Data Protection.