Data Recovery Case File · Formatted & Logical Faults · Whose Key Is It
An Escrowed Key Belongs to Whichever Account Enabled the Encryption
His enquiry contains a possibility most people would not think of and it is probably the answer. A laptop that "seems to have activated encryption, possibly when it automatically updated", with no key in his own account and none saved anywhere — and then: "it's possible when I did some work for a client and accessed files on their system, their IT department activated it." If a managed account enabled it, the key was escrowed to that organisation, not to him.
| Media | Laptop with volume-level encryption enabled without the owner's knowledge — recovery key absent from the owner's personal account; possible enrolment through a third-party managed account |
| Reported situation | Laptop upgrading automatically between operating system versions · volume encryption found to be active afterwards · owner unaware it had been enabled · recovery key not present in the owner's account · key not recorded elsewhere · work performed for a client with access to their systems · possibility raised that the client's administrators enrolled the device |
| Fault class | Encrypted volume with key escrowed to an unidentified account — content mathematically inaccessible without it; escrow location determining feasibility |
| Equipment used | Escrow location established as the determining question before any technical work · volume imaged write-blocked at the block level irrespective of encryption · encryption presence and key identifier read from the volume headers · enrolment evidence located from device management records on the volume · decryption performed from the image where a key was subsequently produced |
The decode: where the key went, and the order in which to look
Why encryption switches itself on: it is increasingly the default. Modern systems enable volume encryption automatically on capable hardware, particularly during a major version upgrade, and the process is largely silent.
Where the key goes when that happens on a personal machine: the signed-in account. It is escrowed to the account that was active, and retrieved by signing in from any browser.
Why his search of his own account came up empty: either it was never there, or a different account holds it. The absence is informative rather than final.
What changes when a work account is involved: the escrow destination. Signing in with a managed account can enrol the device in that organisation's management, and the key is then escrowed to their directory.
Why that happens without anyone intending it: enrolment is a consequence of authentication rather than a separate decision. Accessing a client's systems with their credentials can enrol the machine as a managed device, and nothing announces it.
Why his suspicion is therefore worth acting on first: it is the most likely location. The key exists, and it is held by whoever the device was enrolled with.
What can be established from the machine itself: a great deal. Enrolment records and the key identifier are readable from the volume without decrypting anything, and the identifier converts a vague request into a precise one.
Why that matters when approaching the client: an administrator asked for a key by identifier can find it. An administrator asked whether they might have a key for someone's laptop generally cannot.
What the honest position is if it is not there: nothing can be done by anyone. Volume encryption without the key is not a lock to be worked around but a mathematical transformation.
What must not happen meanwhile: no reinstallation and no reset offered as a fix. Both discard the encrypted volume, and a key found afterwards would have nothing to open.
On the bench
Escrow location was established as the determining question before any technical work — modern systems enabling volume encryption automatically during major upgrades and escrowing the key to the signed-in account, whereas authentication with a managed account can enrol the device in that organisation's management, escrowing the key to their directory as a consequence rather than a decision. Enrolment evidence and the key identifier were read from the volume without decryption, converting a vague request to an administrator into a precise one.
The outcome
Escrow location established as the determining question, the volume imaged irrespective of encryption, and enrolment evidence read from the volume. Free assessment, one fixed written figure including VAT. The decode: your suspicion is the most likely answer. Signing in with a client's credentials can enrol the machine in their management, and the key is then escrowed to them — so the identifier read from your own volume is what turns that into a request they can act on.
When a machine has encrypted itself and you have no key
Don't reinstall or reset it — both discard the encrypted volume, and a key found afterwards would have nothing left to open. Then work out whose key it is: personal machines escrow to the signed-in account, but authenticating with a work or client account can enrol the device in that organisation's management, sending the key to their directory instead. That happens as a consequence of signing in, not as a decision anyone made. Get the key identifier read off your volume first — an administrator can find a key by identifier.
Don't reinstall — call Cambridge Data Recovery on 01223 655015; escrow location established first, volume imaged irrespective of encryption, key identifier read from the headers for a precise request.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.