@GossiTheDog, @wdormann: 1. This is not the same as "mount the OS drive on another computer using your own password", because a PIN alone isn't enough to mount a BitLocker-protected volume in the "TPM + PIN" mode. Since early BitLocker bypasses, Microsoft explicitly states that "a PIN known to an attacker" is a vector (e.g., "[t]o exploit the vulnerability the attacker needs to know the TPM PIN if the user is protected by the BitLocker TPM+PIN", see CVE-2022-41099). So, yes, YellowKey is exploitable in the "TPM + PIN" setup, because an attacker can enter that PIN (and bypass the other protection layers that disallow admin-level access to the mounted encrypted volume, because knowing the PIN isn't enough here). Compare this to the "enter a known password only and bypass 2FA" situation (not the same situation, but I don't have another analogy). 2. However, the way the YellowKey is exploited here is much worse. In general, this is another attack that can inject (and launch!) an attacker-controlled executable into the encrypted file system: a. via the unencrypted data manipulation, AND b. without violating existing code integrity controls (like Secure Boot and TPM measurements) — you don't execute anything in the boot path (no WInRE required for an attacker; actually, it's just proposed as an execution environment to prepare transaction log files, but any other would work; the exploit itself requires WinRE, but not its deployment), AND c. reachable from the storage stack alone (a backdoored HDD/SSD can bypass your pure-software BitLocker in the "TPM + PIN" setup, the same for the implicit network boot you can see in the "ESX plus network datastore" case in many cloud providers, the same for the confidential computing scenario enforced via BitLocker and RAM encryption).