A researcher operating as Chaotic Eclipse (Nightmare-Eclipse on GitHub) published a zero-day exploit this week called YellowKey. It bypasses TPM-only BitLocker. All that’s needed is a USB stick and a few files. With this, the attacker can reboot into the Windows Recovery Environment which will open an elevated command prompt with the encrypted drive unlocked. WinMagic has validated that this works as described. Researchers also claim a variant that defeats TPM+PIN exists, though no proof-of-concept has been published for that one yet.
This is getting attention. It deserves some. But not the shock it’s receiving.
One more method on a long list
YellowKey is a new technique, not a new category of problem. BitLocker without pre-boot authentication has been attacked before, many times, through many doors. TPM bus sniffing on the LPC and SPI interfaces. Cold boot against DRAM remanence. DMA via FireWire and Thunderbolt. CVE-2022-41099, the WinRE issue Microsoft patched in 2022. YellowKey adds another door.
What’s notable isn’t that the door exists. It’s who can walk through it. These attacks used to need dedicated hardware, real preparation, real skill. YellowKey is straightforward — the researcher says so himself. The bar collapsed. A motivated non-expert can do in minutes what once took a determined attacker hours.
We’ve known this from the start
The weakness of TPM-only BitLocker has been understood since BitLocker shipped. Without a user-supplied secret at boot, the volume master key has to come from somewhere the machine reaches on its own. Anything that controls the boot environment can reach it too. WinRE is part of that environment. So is everything else running before the OS. The attack surface was always too big to defend door by door.
Nothing prevents an attacker from reading your data if they have your laptop. That’s not provocation. That’s the threat model.
Microsoft says the same thing in their own BitLocker Countermeasures documentation. Pre-boot authentication, they write, is “designed to prevent the encryption keys from being loaded to system memory without the trusted user supplying another authentication factor.” Not a new recommendation. It keeps being rediscovered because it keeps being ignored.
The standards tell a quieter story
NIST’s foundational guidance on storage encryption is SP 800-111, Guide to Storage Encryption Technologies for End User Devices. It defines full disk encryption as “encrypting all the data on the hard drive used to boot a computer, including the computer’s OS, and permitting access to the data only after successful authentication to the FDE product.” It says users must be able to authenticate using the most fundamental components of a device, such as a standard keyboard. Authentication isn’t an enhancement in NIST’s framing of FDE. It’s part of the definition.
The document is also from November 2007. Its authentication model is a person typing at a BIOS-level keyboard. No multi-factor. No hardware tokens. No FIDO. The things a modern pre-boot design would include aren’t in the document because they didn’t yet exist in this context when it was written. Nearly twenty years on, the foundational guidance hasn’t been refreshed.
SP 800-111 is a guideline, not a mandate. But it’s the NIST document that downstream regimes point to — HIPAA breach safe harbor, FISMA-aligned controls, OMB Circular A-130, and the CUI ecosystem that feeds CMMC. Its definition is the inherited definition. And in that inheritance sits a gap. TPM-only BitLocker — the configuration most enterprise deployments run — sits outside the SP 800-111 definition of FDE. NIST has never said so. DISA STIG was clearer about it: control WN11-00-000031 says Windows 11 must use a BitLocker PIN for pre-boot authentication. CMMC, reading the silence, accepts no-PBA configurations because nothing explicitly forbids them.
NIST has had nearly twenty years to settle this. The choice is binary. Update SP 800-111 to say TPM-only doesn’t satisfy FDE, or revise the definition to say user authentication at boot is optional. Either is defensible. Silence isn’t. Silence is what made an industry of no-PBA defaults possible.
YellowKey just made the cost of that silence visible. The attacker no longer needs to be sophisticated. The attacker needs a USB stick.
On the technique — and on the PIN question
We like this work. WinRE has been picked at for years, and prior findings tended to show that something in there could be coerced — usually under specific conditions, usually with follow-on steps. YellowKey goes further. A USB stick, an elevated shell on the unlocked volume, files cleaning themselves up afterward. The category is familiar. The completeness isn’t.
The researcher also claims a TPM+PIN variant. No PoC yet. We don’t think it will hold up — at least not in the same form. The reason is structural. YellowKey, as published, works because the unlock completes on its own. No user gate, nothing to coerce a human past. Put a real PIN gate in the way and the same path has to either bypass the PIN protector entirely — which is a different and much larger finding — or rely on conditions narrower than “TPM+PIN is broken.” We could be wrong. We’d like to see the PoC and find out.
If we’re wrong, there are only two ways to read it. Microsoft built that bypass on purpose. Or Microsoft made a mistake. One of those is true. Both are bad. The trusted-computing framing wrapped around TPM-anchored BitLocker for twenty years doesn’t survive a PIN bypass either way.
If we’re right, the picture is the one the structural argument already points to. TPM-only configurations carry the exposure. Configurations with a user-held secret hold the line. Microsoft gets the better answer. The no-PBA problem is still the no-PBA problem.
Two questions for the researcher:
- The completeness of the WinRE result suggests there’s adjacent territory. What else in the pre-OS environment behaves the way WinRE does in this exploit?
- On the PIN variant: is the PIN protector being bypassed outright, or does the variant depend on cached state, recovery flows, or specific configurations? The distinction matters for anyone defending fleets right now.
Math, not trust
The design principle behind WinMagic’s SecureDoc is this: we — the developers, the people who built it — can’t read a user’s data without that user’s authentication. Cryptography enforces it. Not a promise from us. We didn’t build a backdoor key. We didn’t build a recovery path that walks around the user’s secret. Some smaller things in any security product still depend on keeping details quiet. But the load-bearing property — no authentication, no data — is math, not trust in the vendor.
That’s the answer to the question YellowKey is forcing. When a path exists that releases the volume key without the user’s secret, the vendor can read the user’s data. We can’t read yours. We built the product so no exploit against us can hand us — or anyone — that capability. That should be the standard. (Autoboot configurations, where a customer deliberately chooses convenience over this property, are the exception. They’re explicit choices.)
The practical answer hasn’t changed
The attack is new. The defense isn’t. Pre-boot authentication — a user-held secret required before the drive unlocks — closes the window YellowKey walks through. Not narrows it. Closes it. WinRE doesn’t get a turn. Whatever Eclipse publishes next doesn’t get a turn either. The key never reaches memory until the human at the keyboard authorizes it.
The path from “attacker has your laptop” to “attacker has your data” runs through every component that touches the encryption key before you do. In TPM-only mode that path is wide, well-documented, and now trivially exploitable. Patching individual methods one at a time was never a strategy. It’s a treadmill.
If your BitLocker fleet runs in TPM-only mode and your devices leave the building, this week is the prompt to step off it.
This kind of attention comes for every encryption product eventually. Ours included. We’d rather face it than be the product nobody bothers to look at. The work forcing this conversation is the work that matters.
TALK TO US
Pre-boot authentication, done properly.
SecureDoc supports password, smart card, USB token, CAC/PIV, TPM, and network-validated pre-boot authentication via PBConnex. One product, one policy, the same property at boot. Click here to learn more.
