Deleting a file from an application and making its old contents unrecoverable are different operations. For encrypted storage, the gap can include recovery keys, wrapped copies of a content key and backups that outlive the visible document.
This becomes a business problem when a laptop leaves an organisation, a cloud contract ends or a sensitive project closes. A disappearing filename is easy to demonstrate. A defensible statement about sanitisation needs evidence about the media and the keys that can still unlock it.
Cryptographic erase has conditions
NIST SP 800-88 Revision 2 addresses media sanitisation, including cryptographic erase. The method depends on eliminating the relevant cryptographic access, not merely hiding a document in a user interface. The guidance treats the suitability of the encryption and key-management implementation as part of the decision.
The full NIST publication discusses the affected encryption and wrapping keys. Those details matter because removing one key record is insufficient if another retained route can recover the same data. This is guidance for a sanitisation programme, not certification of a particular commercial storage product.
Start with a key inventory
Imagine a fictional project folder encrypted before upload. Its content key is protected for two employees and an approved recovery process. The storage provider has ciphertext. At project closure, deleting one employee’s wrapped copy does not establish that the other employee or the recovery process has lost access.
Even deleting every known key wrapper would not recall plaintext that someone exported earlier. That copy has its own lifecycle. The distinction is operationally useful: one action changes access to the encrypted object; another deals with already readable copies.
A key inventory should connect the protected object to the keys and recovery paths that can open it. It must also record the scope of a key. If a single key protects unrelated projects, destroying it to erase one project may destroy legitimate access to the others. Fine-grained encryption can make selective retirement more practical, but only if recovery copies preserve that granularity.
Why the delete button is weak evidence
A cloud application’s delete command might remove an index entry, move an object into a recoverable state or start a retention process. Its label does not reveal which behaviour applies. Read the relevant service policy and test a harmless object under the account’s actual configuration.
There is a similar ambiguity on a workstation. Removing the visible file does not establish that every temporary copy has gone. A local application may create exports or synchronised copies elsewhere. The right response is to map the workflow, not promise universal erasure from a single click.
Do not test destruction on genuine business records. An organisation may have a legitimate obligation to retain them, and a destructive experiment can cause irreversible loss. Use synthetic material in a disposable environment with the owner’s approval.
A controlled retirement test
Create a small invented document and record its hash. Identify the intended encrypted copies and authorised recovery mechanism. Verify that the document opens before the test. Then perform the documented retirement procedure on that disposable object and attempt the explicitly listed recovery paths.
Record both successful and failed attempts. A failed recovery through one interface is not proof that every possible copy has been eliminated. It is evidence about that interface under those conditions. The test report should state its limits and name any retained backup whose expiry still lies ahead.
For physical media retirement, follow the organisation’s approved sanitisation procedure and validation requirements. An application-level exercise cannot stand in for evidence about an entire drive. Conversely, a drive sanitisation certificate says nothing about a cloud backup that never resided on that drive.
What decentralised key management changes
When a storage operator does not possess the keys needed for content decryption, an object can remain on that operator’s infrastructure without granting it readable content. Retirement then depends heavily on the endpoints and recovery routes that do hold the necessary material.
The historical AVLab description of UseCrypt Safe provides background for this key-management discussion. It is historical coverage of Safe, not a contemporary sanitisation assessment of Messenger. The UseCrypt evidence register helps keep that scope visible.
Bringing Privacy Back should include a comprehensible end to access, not only a private beginning. A person needs to know which keys still exist, who can recover them and what a deletion claim actually covers. That is the difference between an attractive button and a retirement procedure another engineer can examine.
