TPM-only BitLocker leaves the Windows Recovery Environment in play
BitLocker with TPM-only unlock is convenient because the user does not have to do anything at boot. That convenience comes with a catch: Windows Recovery Environment files are left unencrypted so recovery still works when BitLocker itself fails. That design keeps the machine repairable, but it also leaves material in place that attackers have used in bypasses.
Microsoft patched several related bugs in 2025, including attacks that used WinRE to side-step certain BitLocker configurations. The useful detail is not the name of the bug. It is the behaviour. If the pre-boot path can be tampered with and the disk opens without a second factor, the TPM has done its job and still not protected the boundary you probably care about.
A pre-boot PIN closes the gap without pretending the laptop is a vault
BitLocker PINs are a practical control, not a magic shield. They force authentication before the system decrypts the volume, which blocks the lazy win of just powering on a machine and letting the TPM sort it out. That matters most for lost, stolen, or unattended laptops, where physical access is the starting point for abuse.
The PIN does not make a laptop invulnerable. It does make the boot process less forgiving. That is the point. Full disk encryption is good at protecting data at rest. It is weaker when the attacker gets the device and the unlock path does not ask for anything beyond possession of the hardware.
Using the same PIN for Windows Hello and BitLocker can be a sensible compromise when memorising two secrets is the real problem. It is not elegant, but elegance is not the job here.
Where the PIN is awkward, use the least-bad fallback
Some devices will not handle a manual PIN well. Shared endpoints, unattended kit, and time-critical laptops can make pre-boot entry a nuisance. In those cases, the fallback should still add a barrier rather than dropping back to TPM-only and hoping for the best.
One option is BitLocker Network Unlock, which reads the key from a trusted network and skips the PIN prompt while the device remains on that network. If it is disconnected, the user gets the PIN prompt. That is useful for managed sites with stable LAN access, less so for roaming machines that live in trains, taxis, and hotel Wi-Fi purgatory.
A Startup Key on USB is another fallback. It still adds pre-boot authentication with the TPM, but it swaps memorisation for a physical token. That creates its own mess: lost keys, stolen keys, and the usual joy of tracking which USB stick belongs to which machine. Still, it is stronger than leaving the machine to unlock itself.
Conditional access can sit above all this for higher-risk devices. If the endpoint is the wrong shape, or the wrong risk level, block it from sensitive resources. That does not fix weak pre-boot settings. It does stop a compromised laptop from walking straight into everything else.
Check the policy on a real device before you trust it
BitLocker settings have a habit of looking correct in a policy editor and behaving oddly on the machine you actually care about. Test the boot flow on hardware that matches the real deployment. Confirm that the PIN is requested, that recovery still works, and that the fallback path does what you expect when the network is missing or the USB key is absent.
A policy that has never been exercised on a real endpoint is just a promise with a checkbox next to it.
