Locked out of a laptop, no recovery key anywhere, and a deadline. The way in was not an attack on the encryption — it was a key Windows had written to the disk itself and left there.
A Manchester architecture practice. A senior colleague moved on, and the Dell laptop they had used would no longer start — a half-completed feature update had left Windows dropping straight to the blue BitLocker recovery screen on every power-up.
The system partition was encrypted with XTS-AES 256, protected by the machine’s TPM and gated by a start-up PIN. The 48-digit recovery key existed nowhere: never escrowed to the firm’s Microsoft 365 tenant, never printed, never written down. Inside were months of active project work.
This matters, because it explains why the job was possible and why it is not a way around encryption generally.
BitLocker does not encrypt your disk with your PIN, or with your recovery key. It uses a two-level hierarchy.
The full volume encryption key is what actually encrypts the data. It is generated once when protection is switched on and it never changes, because changing it would mean re-encrypting the entire volume.
The volume master key encrypts that key. And the volume master key is in turn encrypted separately by each protector you have configured — the TPM, a start-up PIN, the recovery password, a USB startup key — with each encrypted copy stored in the volume’s own metadata.
That structure is why you can add or remove a protector instantly, and why the recovery key works even though it was generated before most of your files existed. Every protector is simply a different lock on the same key, and any one of them opens the chain.
Which also means: obtain the volume master key by any route and the recovery key becomes irrelevant. You are not bypassing the encryption. You are holding the thing the encryption was protecting.
When a BitLocker volume is mounted and in use, the volume master key necessarily exists in memory — the system cannot read or write the disk without it.
And when Windows hibernates, it writes the contents of memory to a file on that same disk so it can restore the session later. The hibernation file therefore contains, among everything else, whatever keys were resident at the moment of hibernation.
A powered-down laptop offers no live memory to capture, and with no PIN and no recovery key that would normally be the end of the road. But the image carried a hibernation file from the last time the machine had slept, and the key was in it.
Worth knowing that this is more common than it sounds. Windows enables fast startup by default, which is not a full shutdown — it hibernates the system session and writes that same file. A machine somebody “switched off” has frequently hibernated instead.
The original drive was left alone. Nothing was mechanically wrong — this was purely a lost-key situation — but the handling was the same as any other job.
The NVMe came out, went behind a hardware write blocker, and a complete sector-by-sector forensic image of the locked volume was taken and verified against a SHA-256 hash before anything else happened. Had the drive been reading poorly it would have been acquired on the hardware imager instead; it copied without complaint. The physical disk then went into a bag and all work ran against the image.
That ordering matters more than usual on an encrypted volume. Encryption is unforgiving of partial data: a corrupted region does not degrade gracefully into a slightly wrong file, it decrypts to noise. One clean verified image, taken once, is worth considerably more than repeated attempts against the original.
The volume master key was extracted from the hibernation file, the full volume encryption key derived from it, and the volume unlocked.
To be plain: nothing was cracked and nothing was brute-forced. XTS-AES 256 is not attackable and we would not pretend otherwise. What happened here is that Windows had itself written the key to the disk in the ordinary course of operating, and it was still there.
Which is also the honest limit of this technique. No hibernation file, or one written before protection was enabled, or a machine genuinely fully powered down for its whole life, and there is nothing to retrieve. In that situation, with no recovery key and no escrow, the answer is no — and it would have been given at the free diagnostic.
Unlocked, the volume presented as a standard NTFS partition with everything intact: project files, drawings and mail archives. It went out on fresh media three working days after arrival.
Along with one recommendation, which is the actual lesson. Turn on BitLocker key escrow across the practice. In a Microsoft 365 or Active Directory environment the recovery key can be stored centrally and automatically the moment protection is enabled, at no cost and with no ongoing effort — and a mislaid key then locks nobody out of anything. You can check what protectors a drive has and whether a key was ever escrowed from an elevated command prompt with manage-bde -protectors -get C:, which is a worthwhile thing to run across an estate before you need to.
Decryption work is undertaken only for the owner of the device and only on written authority from the business.
Post it or bring it in. Either way the diagnostic costs nothing and commits you to nothing, and you get one figure in writing before a single screw is turned.
Nothing can begin until the device is on the bench, which makes this the only step that needs anything from you. Pack it properly, put your details in with it, and send it over. What follows is a free diagnostic and a written figure, in that order.
Posting it? Use something tracked and insured — whatever is on the drive is worth considerably more than the postage. Bringing it in? Weekdays, 9am to 5:30pm, and it still wants packing as above for the journey.
Tell us what the device is, what it is doing, and anything already tried — an engineer will come back with a realistic view of the odds and a price band, before you commit to posting anything.
We’ll get back to you soon. Anything pressing, call 0161 871 0788.
BitLocker recovery is the process of getting back into a Windows volume encrypted with BitLocker, using the 48-digit recovery key or the account credentials tied to it. Where the drive itself has also failed, the disk is imaged read-only first and the volume unlocked from that image rather than from failing hardware.
If the drive is healthy and the key is available, unlocking and extracting the data is usually a matter of hours. Where the drive has physical faults the timescale is set by the imaging, typically three to four working days. The free 48-hour diagnostic tells you which situation you are in.
No. BitLocker can only be unlocked with the recovery key or the credentials it is tied to — that is the point of it, and no recovery firm can break it. Check your Microsoft account, any Azure AD or domain record, and any printout made at setup before assuming the key is lost.
Kick off with an instant online quote, or ring us and talk it through first. Either way you’ll know a clear, fixed price before any work starts.