The YellowKey BitLocker bypass has a PoC, no patch, and a clear exploitation path for anyone with physical access or the ability to trigger WinRE on a target device. The collective response from most enterprise security teams will be to wait for the patch and move on. That response misses the more important observation.
BitLocker, deployed the way most enterprise organisations deploy it, was always limited protection against determined physical access. YellowKey is not a new threat category — it is a demonstration of the gap that has existed since TPM-only BitLocker became the default enterprise configuration.
What BitLocker Actually Protects Against
BitLocker’s threat model, when deployed with TPM-only unlocking, is: an offline attack where someone removes the drive and reads it on a different machine. Against that specific threat — a stolen laptop, a decommissioned drive going to recycling — TPM-only BitLocker is effective. The TPM won’t release the key on a different machine.
What it does not protect against: a motivated attacker who boots the device itself. In TPM-only configurations, the TPM releases the encryption key automatically during any authenticated boot sequence — including Windows Recovery Environment. If the WinRE is accessible without a pre-boot PIN (which is the default), and if there’s a vulnerability in how WinRE handles the unlocking sequence (which YellowKey demonstrates), the encryption provides no protection against someone sitting at the machine.
This is not new information. Microsoft’s own documentation distinguishes between TPM-only protection and TPM+PIN protection, explicitly noting that TPM-only mode is vulnerable to scenarios where an attacker can manipulate the pre-boot environment. The BitLocker FAQ has contained this caveat for over a decade.
Why Organisations Deploy It Wrong Anyway
TPM+PIN is more secure. It is also inconvenient. Enforcing a pre-boot PIN means that every time a managed laptop reboots — after a patch, after a crash, after a restart — the user must physically be present to enter the PIN before the machine will boot. Remote troubleshooting becomes harder. Helpdesk call volume increases. Unattended reboots for patch deployment no longer work.
So organisations deploy TPM-only BitLocker, satisfy the “full-disk encryption required” checkbox in their compliance framework, and move on. The compliance requirement is met. The security requirement — protecting against physical access by a motivated attacker — is not met. But the compliance framework doesn’t ask whether the deployment is secure against physical attackers; it asks whether BitLocker is enabled.
This gap is not unique to BitLocker. It appears everywhere that compliance requirements are written as point-in-time configuration checks rather than threat-model assessments. “MFA enabled” doesn’t distinguish between TOTP (bypassable) and phishing-resistant hardware tokens. “Encryption at rest” doesn’t distinguish between TPM-only and TPM+PIN. “Vulnerability scanning performed” doesn’t distinguish between monthly scans with 120-day remediation SLAs and weekly scans with 7-day critical patch windows.
What Actually Protects Against Physical Attackers
For organisations with a genuine physical attack threat model — executive devices, machines in unsupervised environments, devices that regularly travel to locations where adversaries have physical access — the security requirement is TPM+PIN or TPM+USB key. Not TPM-only.
YellowKey exploits the WinRE unlock path. TPM+PIN breaks that path — the machine won’t boot, including into WinRE, without the PIN. An attacker sitting at the machine cannot proceed past the PIN prompt without knowledge they don’t have.
The operational inconvenience is real. There are segments of any organisation’s fleet where TPM-only is an acceptable trade-off — machines in physically secure data centres, desktop systems that never leave the building. For those, TPM-only is appropriate. For laptops belonging to executives, finance staff, M&A teams, or anyone else handling sensitive data in unsupervised locations, the risk profile is different.
The patch for YellowKey will arrive, and the gap it exposed will be closed. But the underlying question — whether your BitLocker deployment matches your actual threat model or just your compliance requirement — will remain open after the patch is deployed. That question doesn’t get answered by waiting for Microsoft.
Share this article