Cause of loss · encryption & TPM locks
The machine asking for 48 digits when it first starts up is working as expected. The TPM detected something it was not expecting (new firmware, a different boot setting, or a different mainboard) and therefore will not provide the key to access the disk until the recovery key is provided. The disk underneath is usually in good shape, which is why a Maidenhead BitLocker case starts 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 are no longer valid, so the TPM seals the key | Track down the key; do not guess |
| Use the number keys, or the function keys F1–F10 (F10 for 0). | Screen on how to enter the 48 numbers | Use only numbers; a password will not work |
| Recovery key ID (to identify your key): | Eight-character label name of the key this drive is looking for | Find the escrow(s) using that ID |
| For more information go to: aka.ms/recoverykeyfaq | Microsoft's guidance on recovery keys | Your recovery key will be listed in your account |
| BitLocker waiting for activation | This volume is ready for encryption; it has not been encrypted | Not protected, but readable |
| A locked container on a disk that is failing | First hardware, then decrypt later | Image it while locked, then unlock it |
Nothing is chargeable until you say yes. Every item gets a case number of its own immediately upon receipt, an engineer determines what has failed, and you get a clear picture of which files have a real possibility of being recovered. The single quote that follows is fixed, written down and does not cost anything.
The eight characters displayed are the beginning of determining which key belongs to the volume. Then each possible location is searched for the correct key: the Microsoft account the computer was originally configured with, a company/college sign-in, an IT escrow created via Entra ID or Active Directory, as well as the paper generated when encryption began. No key means no data for anyone.
When a drive begins to fail, a complete image of every sector (and therefore all data) is made while still encrypted (locked), thus preventing any request to decrypt the data from ever reaching the failing drive.
With the key in hand the image is unlocked; when the actual BitLocker metadata itself is damaged, Microsoft's built-in repair-bde utility reconstructs the volume, and the files are restored to new media.
You don't get charged anything until you've confirmed and authorised that everything is fine after seeing the entire list of what was recovered. Any recovered items are returned via brand-new storage media and the postage costs for these are covered by us. We do not consider a project complete here until we receive confirmation that you have been able to successfully access and review every item you received back.
Stated simply: if there is no 48-digit key for a BitLocker volume, it remains closed. Microsoft states this, and so do we, because if the encryption could be compromised in some manner, it would be worthless. Therefore the process begins by searching through various locations such as accounts and drawers for the 48-digit key, rather than with any engineering work: the personal login, the work login, the key stored in IT's escrow, a folded sheet at the back of a file. Once the 48-digit key is located, in most cases all files contained within the BitLocker volume will also become available. If the key genuinely does not exist, no reputable laboratory can decrypt or open the volume, and you will hear this stated during the complimentary diagnostic evaluation, not after you have been sent an invoice.
Due to an overnight firmware update, the TPM values changed, causing the workstation to wake looking for a recovery key that no one had ever written down. Once we got the Recovery Key ID, that took us to the practice's escrow in Entra ID. After that we ran repair-bde to rebuild the damaged BitLocker metadata onto a fresh disk, and none of the project files were lost.
Start with the eight-character Recovery Key ID on the screen that tells you what recovery key you want. Home machines have theirs stored under their Microsoft account at aka.ms/myrecoverykey. Business machines are at aka.ms/aadrecoverykey. Ask your IT department about escrowing in Intune or Active Directory and see if you can locate the printout made when you first started encrypting.
No, and that applies equally to both Microsoft and any laboratory; the volume is performing exactly as it was designed to perform. The cases that close out positively are those where there is some sort of key remaining somewhere and the real issue is with either your hardware or the volume's metadata.
Because the measurement held by the TPM no longer matches up with the physical machine sitting in front of it. Usually this would occur due to a BIOS/firmware update, a Secure Boot configuration change, a mainboard repair, or you moving the disk to other pieces of hardware. In July 2024 a Windows update caused this at scale.
Always hardware. A copy of all data is created while the volume is still sealed, and then the unlocking operation is done on that copy, which cannot deteriorate. It is bad policy to ask a failing disk to decrypt itself (the reverse order).
Every additional power-up asks for even more of a drive that is already starting to fail. First open a case with us, and let the free diagnosis tell you how much remains.