BLK / How the drive was locked / Escrow: AD, Entra ID, Intune, MBAM

Active Directory · Entra ID · Intune · MBAM · msFVE-RecoveryPassword · recovery password viewer

BitLocker key escrow recovery. On a company machine, the key is usually already kept somewhere you can read it.

A business laptop at the BitLocker recovery screen is usually the happiest case of all, because managed devices almost always escrow their recovery keys automatically, and your IT department can read them out. Where the key lives depends on how the organisation is set up. A traditional domain stores it in on-premises Active Directory, as the msFVE-RecoveryPassword attribute on the computer object, read with the BitLocker recovery password viewer or PowerShell. A cloud or hybrid organisation stores it in Microsoft Entra ID, where an administrator reads it from the device in the portal. Intune-managed devices expose the key to administrators in the Intune console, and older estates may use MBAM, Microsoft's BitLocker Administration and Monitoring, which issues single-use keys. The common thread is that the key is retrievable by the right person, so a managed lockout is a matter of identifying where the key is and getting an administrator to read it. We help organisations do this under proof of authority, and we are for the harder cases: a failed drive from a managed machine, a damaged key record, or an estate where the escrow was misconfigured and the key is not where it should be.

Owner-only, proof requiredFree first look£800 + VAT, one diskNo fix, no fee on the balance

Rather talk it through? An engineer answers the bench line
0800 6890668

Stop before you reinstall or reformat anything. If the machine is at the BitLocker recovery screen, the data is intact behind the key; reinstalling Windows, reformatting the drive or clearing the TPM again will not get you in and can overwrite what is there. Do not keep typing the wrong key until a device locks you out. If the machine is still running and unlocked, do not shut it down before you have read the lost-password pages. Find your recovery key first, and send nothing until you have.

Each escrow store, and how the key comes out of it.

Active Directory (on-premises): the key is stored against the computer object as the msFVE-RecoveryPassword attribute, inside an msFVE-RecoveryInformation child object. An administrator reads it with the BitLocker Recovery Password Viewer snap-in in Active Directory Users and Computers, by searching for the recovery password using the first part of the key ID, or with PowerShell. The key ID on the recovery screen matches the stored record.

Microsoft Entra ID (Azure AD): an administrator signs in to the portal, opens the device, and views the BitLocker keys stored against it, at aka.ms/aadrecoverykey for the device owner. This is the common case for modern cloud-joined laptops.

Intune: for Intune-managed devices, the recovery key is visible to administrators in the device's properties in the Intune admin centre. MBAM: older managed estates use Microsoft BitLocker Administration and Monitoring, which stores keys centrally and issues single-use recovery keys that expire once used.

Because the key is retrievable, most managed lockouts never need a recovery lab at all: the right administrator reads the key and the machine starts. We are for when that breaks down, a drive that has physically failed, a key record that is damaged or missing, or an organisation that finds its escrow was not capturing keys after all. In every case we work under documented authority from the organisation, with a clean chain of custody.

Why a managed machine is usually the easy case.

The key is captured automaticallyOrganisations configure BitLocker so that every machine escrows its recovery key to AD, Entra ID or Intune the moment encryption is turned on. That is the whole point of managed BitLocker: no key is ever only on the machine, so a lockout is recoverable by design.

An administrator can read it outThe key is not hidden from the organisation, only from the user at the screen. An administrator with the right role reads it from the directory or portal and reads it back to the user, or enters it. The key ID on the screen points to the right record when there are many.

MBAM keys are single-useWhere MBAM is in play, each recovery key is used once and then expires, and a fresh one is issued. It is worth knowing, because a key that worked before will not work again; the administrator retrieves the current one.

We are for when escrow failsSometimes the escrow was misconfigured and never captured the key; sometimes the computer object or key record was deleted; sometimes the drive itself has failed. Those are the cases that reach us, and they are where proof of authority and careful forensic work matter.

What you see, and what is behind it.

Describe yours to us →

What you see	What is usually behind it	Where that leaves you
Managed laptop at the recovery screen	Key escrowed to AD, Entra ID or Intune	An administrator reads it out; machine starts
Several keys in the directory	Multiple records for the device	The key ID on the screen identifies the right one
MBAM key that worked before now fails	MBAM keys are single-use	Retrieve the current key from MBAM
Key not in the directory at all	Escrow was misconfigured or the record deleted	Falls back to any other protector, or lab work
Managed drive has physically failed	A hardware job on a company drive	Imaged, then decrypted with the escrowed key

From the drive arriving to your files going back.

Work we have closed →

Logged the day it lands, and the first look costs nothing Free

A number goes on the parcel and the drive the day it is opened, matched to your enquiry by the booking sheet inside. Before anything is read we check the proof of ownership you sent. The drive is then connected through a write blocker, read-only, and examined: whether it is a healthy drive behind a lost key, or a failing drive behind a known key, is settled here, and so is whether what you want is possible. That first look is free, and you may stop at it owing nothing.

Nothing to pay for lookingProof of ownership checked firstRead-only, nothing written to the drive

Imaged at the sector level, before anything else

A drive that answers at all is imaged in full on a hardware imager, behind a write blocker, weak areas last, with a map kept of what could not be read. The image is a copy of the encrypted sectors, so it is useless to anyone without your key, which is a privacy gain in itself. Every later step is done on the image. The original drive is never decrypted, never written to, and never worked on directly.

Sector by sector, behind a write blockerNothing written to the original

The physical fault repaired on the clone, when there is one

A drive that has failed, that reads slowly or that drops out is stabilised and imaged in passes; a mechanically failed disk is repaired and read on the bench, a dead SSD controller read at the chip level, before any decryption is attempted. The aim at this stage is one clean image of the encrypted volume to decrypt from. Where the drive is healthy and the problem is only the key, this stage is skipped.

Mechanical and chip-level work where neededOne clean encrypted image to work from

The image decrypted with your key or password

With your recovery key, recovery password or the drive's password, the image is unlocked: the protector releases the Volume Master Key, the VMK releases the Full Volume Encryption Key, and the volume is decrypted from the clone. Where the metadata or header is damaged, repair-bde and the key package rebuild it at the block level onto a separate target. Where the key is lost but a memory image or hibernation file is available, the Volume Master Key is extracted from it with Passware. Without a key, a password to attack, or a memory capture, the volume cannot be opened, and you are told so at the free look.

Protector → VMK → FVEK → volumeDecrypted from the clone, never the original

The file system rebuilt, and the list before the bill

Once the volume is open it is an ordinary NTFS or exFAT file system, and any damage in it is repaired on the image and the files recovered. What was recovered is listed for you first, and only then does a bill exist. The files go home on fresh media. The original drive is returned, or securely destroyed at your request; we never send the key and the data by the same route.

Files listed before any invoiceFresh media, supplied with the job3–7 days at the bench

From the bench

Start with your IT department or administrator. On a managed machine the key is almost always escrowed, and reading it out is a two-minute job for the right person.
The key ID on the screen matches the directory record. It identifies the exact key among many, which matters in a large estate.
MBAM keys are single-use. If a previously working key is refused, the administrator retrieves the current one rather than reusing the old.

Automatic escrow to AD, Entra ID or Intune is why a managed-laptop lockout rarely needs a recovery lab at all.

One job, followed all the way through.

UK · BLK-2026-0705JOB LOGGED ✓

A company-issued laptop whose SSD failed, Entra-joined, with the recovery key safely in the organisation's directory and a departing employee's handover files on it

A textbook managed case with a hardware twist. The IT manager confirmed the organisation's authority to have the drive recovered and read the recovery key from Entra ID against the device. The SSD itself had failed, so we imaged it behind a write blocker and decrypted the image with the escrowed key. The handover files came back and were returned to the organisation under its authorisation. The escrow did its job; only the hardware needed us.

100% recovered; escrowed key, failed drive6 days at the bench

Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

Ask your IT department or administrator first
Have them read the key from AD, Entra ID or Intune
Match the key ID on the screen to the right record
Provide the organisation's authority for any lab work

What sets us back

Assuming a managed lockout needs a recovery lab; usually it does not
Reusing an MBAM key that has already been used once
Reimaging the machine before reading the escrowed key
Having an unauthorised person request recovery of a company drive

We recover BitLocker drives for the people who own them. Before any work begins we ask for proof that the drive is yours or that you are authorised to have it recovered: a purchase receipt, the device serial, a letter on company letterhead for a work machine, or written authorisation from the owner, together with photo ID and a signed authorisation. It is a condition of the work, not a formality, and it is what keeps the service on the right side of the Computer Misuse Act. A drive with no proof of ownership is returned unread.

Questions answered before you commit.

Where is the BitLocker key for a work laptop stored?

Almost always in the organisation's directory: Active Directory as the msFVE-RecoveryPassword attribute, Microsoft Entra ID for cloud-joined devices, or Intune for Intune-managed ones; some older estates use MBAM. An administrator with the right role can read it out, which solves most managed lockouts without a recovery lab.

My company laptop is asking for a BitLocker key. What do I do?

Contact your IT department or administrator. On a managed machine the recovery key is almost certainly escrowed and they can read it out, matching the key ID on your screen to the right record. If the drive has also failed, that is where we come in, working under the organisation's authority.

The key from our records is not being accepted. Why?

If you use MBAM, keys are single-use and expire once used, so an old key will be refused and the administrator must retrieve the current one. Otherwise, check the key ID on the screen matches the record you are reading; a large estate has many keys and it is easy to use the wrong device's.

Can you recover a managed drive that has failed?

Yes. With the organisation's authority and the escrowed key, we image the failed drive and decrypt the image, returning the data to the organisation. The escrow provides the key; we solve the hardware failure. Proof of authority is required because it is a company device.

What does it cost?

If the key is in the directory and the drive is healthy, reading it out costs nothing from us. A failed managed drive falls under single-disk recovery at £800 + VAT, 50% non-refundable on acceptance and 50% no fix, no fee, invoiced to the organisation.

Begin here if yours is doing the same thing.

Device Encryption on Windows Home →How to find your recovery key →The recovery key is not accepted →The CrowdStrike recovery loop →Recovery key, or 48-digit password →

The data is behind the key, not gone.

Looking at it is free, and it begins with the one question that decides everything: do you have the recovery key or password, or can you retrieve it. Tell us what the recovery screen says and what the drive has done, send the proof that it is yours, and back comes a straight account of what is possible and the one price to do it. Until then, reinstall nothing and reformat nothing.

0800 6890668

Price my job Packing and posting

How the drive was locked

Manufacturers

Why you are seeing the recovery screen

What it costs, and what follows