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.
This is a scenario, not a case study. It describes a failure pattern we handle regularly and how it is approached, written from the technical work rather than from one client's job. Our documented case files are here.
A drive protected by BitLocker develops a hardware fault. The recovery key is available — that part is fine. But the drive is failing, and the usual instinct is to unlock it and copy the files off before it gets worse.
Unlocking a BitLocker volume and copying from it keeps the drive powered, seeking and working for as long as the copy takes. On a failing disk that is precisely the load that finishes it, and a copy that stops at sixty per cent leaves you with sixty per cent.
Imaging is the opposite operation: read once, work around bad areas, return to them afterwards with different timing. The image is taken of the encrypted volume exactly as it sits, ciphertext and all, without needing the key at all.
The key is then applied to the image. The drive is never asked to do anything again.
BitLocker encrypts at the volume level, sector by sector, with metadata at the start of the volume describing the arrangement. Nothing about decryption requires the original hardware — given the encrypted sectors and the key, the plaintext is computable anywhere.
That means a partial image still yields a partial decryption. Where ninety-five per cent of the drive imaged, ninety-five per cent decrypts, and the unreadable regions appear as damage in the decrypted volume rather than preventing decryption entirely.
The exception is the volume metadata itself. If the region holding the BitLocker header is among the unreadable sectors, the volume will not decrypt at all — though BitLocker keeps backup metadata elsewhere on the volume for exactly this reason, and that is frequently recoverable.
This is worth stating plainly because it is where people hope for an exception. With the recovery key or password, encryption adds nothing to the price and very little to the work — it is an ordinary drive recovery with a decryption step at the end.
Without either, there is no route in. AES with a correctly generated key has no shortcut, no back door and no vendor override, and hardware failure does not create one.
Before concluding the key is lost: check the Microsoft account the machine was set up with, and on any work machine ask IT, because it is almost certainly in Azure AD or Intune.