Why isn't the default BitLocker protection enough?
Because the default setting hands your encryption key over automatically, with no PIN and no password, the moment your PC boots. Microsoft's own documentation says as much: “TPM-only authentication method doesn't offer a high level of data protection.” It stops a rootkit from tampering with your boot files. It does nothing against someone willing to pull the RAM out of a running machine or plug into an exposed data port before Windows finishes locking things down.
This is the second guide in the anti-tola series, and it has more real steps than the first. If you followed the GrapheneOS guide already, this is the same idea applied to a Windows laptop or desktop: close the gap between “encrypted” and “actually protected.” I've run this exact configuration on my own machines for years. It is not theoretical, and none of it is switched on by default.
What's actually wrong with “TPM-only,” in plain terms?
A TPM (Trusted Platform Module) is a small security chip built into most modern PCs that stores your BitLocker encryption key. On the default “TPM-only” setting, the TPM checks that your boot files haven't been tampered with, and if they haven't, it hands the key over automatically — no PIN, no typing anything. Microsoft's own guidance splits attackers into two tiers: an opportunistic thief with no lab equipment, against whom TPM-only is genuinely fine, and an attacker “with skill and lengthy physical access” — someone who can open the case, or plug in specialist hardware — against whom Microsoft recommends something stronger: a PIN.
The specific attack this matters for is a cold-boot or direct-memory-access (DMA) attack: pulling your encryption key straight out of the computer's memory chips while it still holds a live copy, either by force-rebooting the machine before the memory fades, or by plugging a device into a port (Thunderbolt, PCIe) that can read memory directly, bypassing Windows and its login screen entirely. TPM-only offers no defence here, because the key is sitting in memory, unlocked, the instant the machine boots. A PIN closes this gap by requiring something only you know before the key is ever loaded.
How do you turn on a pre-boot PIN?
Requiring a PIN means the key stays locked until you type it, even if someone has the machine itself. From an administrator command prompt:
manage-bde -protectors -add C: -tpmandpin
This prompts you to set the PIN interactively. One thing worth flagging, because it trips people up searching for this online: some guides show a -type tpmandpin flag — that's wrong for this command. -tpmandpin is the flag itself, no -type needed; -type only applies when removing a protector, not adding one.
By default, this PIN is numeric only, 6 to 20 digits. That's already a large improvement over nothing, but the next section takes it further.
Can the PIN be a real password instead of just numbers?
Yes — Windows calls this an “enhanced PIN,” and it allows letters, symbols, and spaces, not just digits. It's off by default and has to be turned on through Group Policy first:
Computer Configuration › Administrative Templates › Windows Components › BitLocker Drive Encryption › Operating System Drives › Allow enhanced PINs for startup
Turn that setting on, then set your PIN again using the same manage-bde command above — it'll now accept a full alphanumeric passphrase instead of just numbers. Microsoft is explicit that this is what actually raises the cost of an attack: with a sophisticated enhanced PIN, brute-forcing it becomes, in their words, “nearly impossible.”
One genuine caveat, straight from Microsoft: not every PC's firmware correctly supports typing letters and symbols at the pre-boot screen. Test it — reboot and confirm you can actually enter your full enhanced PIN at the pre-boot prompt — before you rely on it, or you risk locking yourself out with a passphrase your own firmware can't accept.
Where should your recovery key actually go?
BitLocker gives you four places to store the 48-digit recovery key it generates: save it to your Microsoft account, save it to a file, print it, or save it to a USB drive. Here's the part worth knowing before you click through the setup wizard: saving to your Microsoft account is the default Microsoft recommends for an ordinary home PC — and it's also the one option that hands a copy of your key to a third party. Anyone with lawful access to that Microsoft account, including Microsoft itself under a legal order, gets your recovery key along with it. That defeats the entire point of this guide.
Export it to a file or print it instead, then take that 48-digit number and store it properly — not as a loose text file on the same machine (useless if that machine is seized), and not on a sticky note. The third guide in this series covers exactly this: setting up a password manager as the single place every recovery key, seed phrase, and backup code you own actually lives.
Does disabling USB storage stop a “Rubber Ducky” keystroke-injection attack?
No — and this is a common, wrong assumption. A USB Rubber Ducky is a small device that plugs in and pretends to be a keyboard, then types out an attack payload at high speed the instant it's connected. It never presents itself as a USB storage drive during the attack. Every operating system trusts keyboards by default, with zero authentication, because that's how HID (Human Interface Device) input has always worked. Turning off USB mass storage in your BIOS does nothing to stop this, because storage was never the mechanism.
What actually helps is locking down physical and pre-boot access more broadly — which is the BIOS/UEFI lockdown below.
How do you lock down the BIOS/UEFI itself?
The BIOS (or UEFI, its modern replacement) is the software that runs before Windows even loads — it's what decides what device the computer boots from in the first place, and a Rubber Ducky-style attack, or any bootable USB rescue disk, can potentially reorder that boot sequence or bypass Windows entirely if this layer isn't locked down too. The National Security Agency's own UEFI hardening guidance — still their current published guidance, even though the document itself dates to 2018 — lays out the concrete steps:
- Set a unique UEFI/BIOS administrator password, and disable or lock down the separate (weaker) user-level password.
- Lock the boot order so it prioritises your actual boot drive, and disable booting from removable media, external drives, and network boot.
- Disable unused ports and peripheral interfaces you don't need for daily use.
- Turn on Secure Boot and make sure the TPM is enabled and active.
- Confirm non-administrators can't change any of the above.
Every one of these is a setting inside your PC's BIOS/UEFI setup screen (usually reached by pressing a key like Delete, F2, or F10 during startup — check your specific PC's documentation for which one). None of it requires special tools. All of it closes the exact door a Rubber Ducky or a bootable rescue disk is built to walk through.
What's the “extreme end” of hardware encryption, and do you actually need it?
This tier is for people with a genuinely serious threat model — not a requirement for most readers, and worth understanding clearly before deciding whether it applies to you.
Windows has a feature called Virtualization-Based Security (VBS), with a component called HVCI (Hypervisor-Protected Code Integrity) sitting on top of it. In plain terms: it uses your CPU's virtualisation features to run a walled-off, isolated check on the operating system's core (its kernel) while Windows is running, catching malicious code that tries to burrow into that core — the kind of attack a traditional rootkit relies on.
Here's the distinction that actually matters, and the one that's easy to get wrong: VBS/HVCI protects the operating system while it's running. It does nothing for cold-boot or DMA attacks — that's still BitLocker's job, specifically the pre-boot PIN covered above, combined with a separate setting called DMA/Kernel DMA Protection that guards physical ports. Don't mistake turning on VBS for solving the memory-extraction problem; they're different layers protecting against different moments of attack.
If you do want it: your CPU needs to be reasonably recent to run it well — Intel chips from the Kaby Lake generation onward, or AMD from Zen 2 onward, have the hardware features (Mode-Based Execution Control and Guest Mode Execute Trap, respectively) that let it run efficiently. Windows itself will only turn it on automatically on somewhat newer hardware still (8th-generation Intel or newer, AMD Zen 2 or newer, with 8GB of RAM and virtualisation enabled in the BIOS) — older-but-still-Kaby-Lake-or-newer machines can run it, just by turning it on manually rather than relying on Windows to switch it on for you.
Putting it together
None of this is a single switch. It's four separate layers, each closing a specific gap: a pre-boot PIN so the key never releases without something only you know, a recovery key that lives in your own password manager instead of Microsoft's servers, a locked-down BIOS so nothing can bypass Windows before it even loads, and — for anyone who genuinely needs it — VBS/HVCI on top, protecting the operating system itself once it's running. Most people reading this need the first three. The fourth is there if your threat model calls for it.
The next guide in this series covers exactly where that recovery key, and every other credential you depend on, actually belongs: choosing a password manager built for zero-knowledge, end-to-end encrypted storage. The privacy technology archive collects all three guides as they publish.
