A finance manager’s laptop stopped booting and came up on the blue BitLocker screen asking for a 48-digit key nobody had. Underneath the encryption, the NVMe drive was dying. Month-end was three days away. Two problems stacked on top of each other — and taking them in the wrong order would have destroyed the data.
A finance manager’s laptop stopped booting mid-week and came up instead on the blue BitLocker recovery screen, demanding a 48-digit key. The company’s IT provider tried the obvious things, could not get past it, and stopped — correctly. Two years of working files, reconciliations and correspondence were on the machine, and the month-end was three days away.
Diagnosis found two problems stacked on each other, which is the classic shape of a business BitLocker job. The NVMe SSD was failing — unstable, dropping out under sustained reads. And the volume was BitLocker-encrypted by company policy. Either alone is routine. Together they need to be taken in the right order, because every unlock attempt is an expensive read, and this drive did not have many left in it.
The instinct is to solve the lock, because the lock is what you can see. That instinct is wrong. Each attempt to unlock and mount a failing drive spends read cycles it may not have, and a drive that dies during an unlock attempt takes the encrypted data with it. So the drive was stabilised at controller level, then imaged while still encrypted — a full sector-by-sector copy of the ciphertext, taken gently, weak areas last, nothing decrypted, nothing written back. (This is worth understanding, because it decides everything. A BitLocker key can be searched for in two physical places: on the drive — escrowed, or left in the clear where the volume was only suspended — and in the computer’s RAM, where the key lives in memory for as long as the volume is mounted. Had the laptop arrived still powered up and unlocked, Passware could have captured the key straight from its running memory. But this one was already sitting on the recovery screen, powered down and dismounted, so RAM held nothing — the key had to come from escrow instead. That is exactly why you never keep power-cycling a machine you might need to image: every restart throws away whatever the memory was holding.)
Finding the key is its own discipline, and there are only so many places one can physically be. Passware Kit, the forensic decryption suite we run, can search two of them directly: the drive image itself — where a clear key is sometimes left in plain form, for instance when BitLocker has been suspended rather than fully switched off — and the machine’s RAM, if it was captured while still running, since a mounted volume keeps its key in memory. Neither applied here: the laptop had arrived powered off, and the disk carried no clear key. That left the place business keys nearly always live — the company’s own directory.
Where a workplace enables BitLocker, the recovery key is normally escrowed automatically — into Entra ID (Azure AD), Active Directory, or the organisation’s management platform. Their IT provider had simply never had cause to look. It was retrieved in minutes, by the company, from their own tenant — and fed to Passware, which took the encrypted image and the key and wrote out a decrypted copy, the original never touched.
With the recovery key in hand, the decryption ran against the image, not the laptop, on Passware Kit Forensic — the forensic decryption platform we use for BitLocker and other encrypted volumes. Given the encrypted disk image and the recovery key, it produces a clean decrypted copy of the volume without ever writing back to the original. BitLocker encrypts sector by sector, so damaged areas cost you those sectors and not the whole volume — and its metadata is stored in more than one place on the disk, so a header damaged in one copy can often be read from another. That redundancy is why an imaged, decrypted BitLocker volume with bad sectors is usually a recoverable one.
The decrypted image mounted, and the finance manager’s working files, reconciliations and mail store came back — verified, returned on fresh media, ahead of the deadline that had made it urgent. The failing drive was returned too, and the company retired it.
One honest note, which we made on day one: had the key not existed anywhere, that would have been the end of it. Properly implemented BitLocker without key, password or TPM cooperation is designed to be unbreakable, and it is. We would have told them so free of charge rather than billing them to find out.
If a work machine has dropped into the BitLocker screen: stop trying keys, and ask IT to pull the recovery key from Entra ID, Active Directory or your management platform. It is almost certainly there. And if the drive is also failing — slow, noisy, dropping out — power it down, because every attempt costs reads you cannot spare.
BitLocker recovery is really two disciplines stacked, and the order matters. The free diagnostic tells you which problem you actually have. NDAs are signed as standard on business recovery work, and every device stays with our own engineers under our ICO registration (ZC173784).