Recovering Data From an Encrypted Drive

Full-disk encryption is now the default on most business laptops, through BitLocker on Windows or FileVault on macOS, and that is a good thing. It does introduce one consequence that catches organisations out: when an encrypted drive fails, or stops unlocking, the recovery key stops being an IT formality and becomes the thing the data depends on.

If the recovery key or password is genuinely gone, the data is generally not recoverable, by us or by anyone else. Modern full-disk encryption does not have a back door, and it cannot be brute-forced in any useful timeframe. Any provider claiming they can routinely break BitLocker or FileVault without credentials is claiming something that should be treated with considerable scepticism.

We would rather say this plainly than take on work that will not succeed. It is also why the first step in these cases is always to hunt properly for the key, before concluding it is lost.

BitLocker recovery keys are commonly stored in one of a few places, and organisations frequently have one without realising: in Active Directory or Entra ID if the device was domain-joined or Entra-joined, in Intune for managed devices, in the Microsoft account used to sign in to the machine, or saved to a file or printed at the time encryption was enabled. FileVault keys may be held in an MDM, or as a personal recovery key stored at setup.

It is worth checking all of these before deciding a key is unavailable, because the answer is often yes in a system nobody thought to look at. An administrator with the right access can usually confirm within minutes.

Where the recovery key is available, a failed encrypted drive is handled much like any other failed drive. The drive is imaged at sector level first, and decryption is applied to the image rather than to the original. The usual causes of failure — bad sectors, failing heads, controller problems — are what actually determine the outcome, exactly as they would on an unencrypted disk.

There is one real difference worth understanding. On an unencrypted drive, a handful of unreadable sectors damages a few files and the rest is fine. Encrypted data is far less tolerant: unreadable sectors in the wrong place can affect much more than their own size, and damage to the areas holding the volume's own encryption metadata can prevent the volume from being decrypted at all. Encrypted drives therefore benefit more than most from being imaged early, before a marginal drive degrades further.

BitLocker sometimes demands a recovery key after a firmware update, a motherboard or TPM change, a boot configuration change or a failed update. The drive itself may be perfectly healthy. In that situation the fix is the recovery key, not recovery work, so it is worth establishing which situation you are in before assuming the worst.

Repeatedly powering on a drive that is genuinely failing, in the hope it will unlock this time, is the thing to avoid. If the drive is making unusual noises or the machine hangs on access, stop and assess it.

Escrow recovery keys centrally, in Active Directory, Entra ID or an MDM, and check they are actually landing there rather than assuming the policy works. An encrypted laptop whose key is in a managed directory is a minor incident when it fails. The same laptop with the key on a sticky note that went in the bin is usually a total loss, and no amount of technical skill changes that.