Cause of loss · encryption & TPM locks
A machine that asks for 48 digits at startup is behaving correctly: the TPM has measured something it did not expect — new firmware, an altered boot setting, a replacement mainboard — and it will not release the key until the recovery one is entered. The disk underneath is generally sound, which is why a Maidenhead BitLocker case begins with paperwork rather than a screwdriver.
Describe the fault to an engineer
0800 6890668
| The signs | The likely cause | Start here |
|---|---|---|
| BitLocker recovery screen: enter the recovery key for this drive | The boot measurements no longer match, so the TPM keeps the key sealed | Track the key down; never guess |
| Use the number keys, or the function keys F1–F10 (F10 for 0). | The screen explaining how to type the 48 digits | Numbers only; a password will not work |
| Recovery key ID (to identify your key): | An eight-character label naming which of your keys the drive wants | Search the escrows by that ID |
| For more information go to: aka.ms/recoverykeyfaq | Microsoft's published guidance | The key will be in your account |
| BitLocker waiting for activation | The volume is prepared for encryption, not encrypted | Readable, but not actually protected |
| A sealed volume on a disk that is failing | Hardware first, decryption afterwards | Image it sealed, then unlock |
Nothing becomes chargeable until you have said yes to it. Each item takes a case number of its own the moment it arrives, an engineer establishes what has actually failed, and you are given a candid view of which files stand a realistic chance of returning. The single quote that follows is fixed, written down, and costs nothing.
The eight characters on screen are the starting point, since they identify which key belongs to the volume. Each store is then checked in turn: the Microsoft account the machine was set up with, a work or college sign-in, an IT escrow in Entra ID or Active Directory, the sheet printed when encryption began. No key means no data, for anyone.
Where the disk itself is deteriorating, a full sector-level image is taken with the volume still locked, so that no decryption is ever asked of failing hardware.
With the key in hand the image is unlocked; where the BitLocker metadata itself is damaged, Microsoft's own repair-bde rebuilds the volume, and the files go out on new media.
Nothing is billed until you have seen the recovered file list in full and told us to go ahead. What comes back arrives on new media, with the return journey at our cost, and the case stays open at this end until you have opened every file yourself.
Stated without decoration: a BitLocker volume with no 48-digit key stays closed. Microsoft says so, and so do we, because encryption that could be talked round would be worth nothing. The first stage is therefore a hunt through accounts and drawers rather than an engineering exercise: the personal sign-in, the work sign-in, the escrow IT keeps, a folded sheet at the back of a file. When the key surfaces, the files almost always follow. When it genuinely does not exist, no honest laboratory can open the volume, and you will hear that at the free diagnosis, not after an invoice.
Because an overnight firmware update shifted the TPM measurements, the workstation woke asking for a recovery key nobody had ever written down. The Recovery Key ID led us to the practice's escrow in Entra ID, and repair-bde then rebuilt the damaged BitLocker metadata onto a clean disk. Not one project file was lost.
Start from the eight-character Recovery Key ID on screen, which names the key you need. Home machines file theirs under the Microsoft account they were set up with, at aka.ms/myrecoverykey; work devices answer to aka.ms/aadrecoverykey. Ask IT about an Intune or Active Directory escrow, and look for the printout saved when encryption went on.
No, and that holds for Microsoft as much as for any laboratory: the volume is doing precisely what it was installed to do. Cases that end well are the ones where a key still exists somewhere and the actual fault lies in the hardware or the volume metadata.
Because a measurement the TPM holds no longer agrees with the machine in front of it. The usual causes are a BIOS or firmware update, an altered Secure Boot setting, a mainboard repair, or the disk being moved to different hardware. In July 2024 a Windows update did it at scale.
The hardware, always. A full copy is taken while the volume is still sealed, and the unlock is then performed on that copy, where nothing can deteriorate. Asking a failing disk to decrypt itself inverts the order.
Each further power-up asks more of a drive that has already begun to fail. Open the case first and let the free diagnosis tell you what is left.