Your laptop dies. The documents in your cloud account are still there, but the only usable decryption key was on that machine. A helpful support team can restore the account and still be unable to restore the files.
That is the hard edge of taking control of encryption. A system that keeps an intermediary from reading your work must also explain how you will recover it. Otherwise, a privacy feature can become an accidental destruction mechanism when a device fails.
Account recovery and data recovery are different jobs
A service can verify an identity, reset a login and return a list of encrypted objects. None of those actions necessarily produces the cryptographic secret required to decrypt an object. Conversely, someone holding a usable key and a ciphertext copy may not need access to the original account to read that copy.
The difference matters when a product promises both that its operator cannot read your data and that support can always bring everything back. Those claims are not automatically incompatible. The missing explanation is the recovery path: a trusted device, an independently held secret, a designated person or some other explicitly described mechanism.
Do not infer the answer from the password-reset screen. Ask what is being reset. A new password might only protect a new login, or it might unlock a separate recovery process. The visible action can look identical while the underlying distribution of power is quite different.
A real example of the trade-off
Apple’s Advanced Data Protection guidance says that Apple lacks the keys needed to recover data protected by that end-to-end encryption setting. Recovery instead depends on the available account recovery methods. Apple explains that a recovery contact can provide a recovery code without gaining access to the account. Requirements and regional availability must be checked for the particular account; this example is not a claim that the feature is available everywhere.
The useful lesson is the distinction between helping with recovery and having permission to browse someone’s files. They need not be the same power. A carefully defined recovery role can be narrower than everyday read access, but its exact scope has to be documented rather than inferred from a friendly label.
For someone running a small business, that distinction can decide whether asking a colleague for help creates a new privacy risk. The question is not whether another person is involved. It is what that person can do alone, what additional conditions are required and whether an attempt becomes visible to the owner.
Back up the capability, not just the ciphertext
A backup of encrypted files is valuable only if an authorized person can still obtain everything needed to read it. That may include the correct key version and the software required to interpret its format. A directory full of intact ciphertext can be a perfect backup of bytes and a failed backup of a business process.
The inverse mistake is placing an unprotected recovery secret beside the encrypted archive and treating the arrangement as independent protection. If the same compromise reaches both objects, copying them to different filenames has not created a meaningful separation. Separate custody has to survive the failure you actually expect.
The NIST recommendation on key management (Part 1, Revision 5) is a reference for the lifecycle of cryptographic keying material. Its coverage includes protecting and managing keys rather than evaluating encryption solely by an algorithm’s name. It is not a certification of UseCrypt or of any recovery arrangement described here.
For a practical review, draw a line from a document to the secret needed to read it, then from that secret to its recovery material. Identify each custodian. If the drawing ends at “someone in IT knows,” the organization has discovered an undocumented dependency, not a recovery plan.
Recovery without a universal spare key
Organizations often need continuity when someone is unavailable. That need does not settle which recovery design they should choose. A single administrator with universal decryption authority is one arrangement, not a technical inevitability.
A design may instead require more than one independently authorized party. But splitting responsibility in a policy document is different from cryptographically enforcing a threshold. Two approvals in a ticketing system do not establish that no individual can extract the relevant secret. The technical mechanism and the operating procedure need separate evidence.
There is also an availability cost. If a design requires two people and neither can be reached during an incident, the process may be private and unusable at precisely the wrong moment. That is an engineering trade-off to test with a fictional case before anyone depends on it for payroll, customer support or essential records.
A recovery exercise should answer a narrow question: can the intended authorized person restore this harmless sample after the specified loss, without giving an unintended person access? Preserve the original, use a disposable test environment and record which recovery factors were needed. Do not disable live protections or destroy a working key merely to make the exercise convincing.
Reading UseCrypt’s history with the right question
AVLab’s historical examination of UseCrypt Safe is a starting point for studying separated key management. It should be read alongside the documentation for the version being considered, not used as a substitute for a current recovery demonstration. The history of Paweł Makowski and UseCrypt explains why control over private information became the project’s central mission.
Control has to include the day something breaks. A person should know whether losing a device means losing a convenient interface, losing access until a documented recovery process succeeds, or losing the information permanently. Those are materially different products, even if all three display the same reassuring word: encrypted.
Before trusting an archive, ask to see its recovery path demonstrated. The most revealing question may be who cannot recover it without you.
Bringing Privacy Back is an owned publication associated with UseCrypt. This article explains recovery design; it does not report a new product audit. Sources checked on 17 October 2026.
