Why BitLocker can fail without a password (and how to harden it)

The myth of unbreakable disk encryption

A coworker pinged me last month asking why his company's "fully encrypted" laptops were getting flagged in a red team report. The pentesters had pulled secrets off three machines without ever entering a password. His response was the one I always get: "But we have BitLocker on everything."

I get it. Full-disk encryption feels like a binary thing — either the disk is encrypted or it isn't, and if it is, you're safe. That's not how it works, and the gap between "encryption enabled" and "actually secure against a determined attacker" is wider than most teams realize.

I want to walk through one specific failure mode I keep seeing in audits: TPM-only BitLocker without a pre-boot PIN. It's the default in a lot of corporate images, it passes most compliance checklists, and it has a well-documented class of bypass that doesn't require any exotic exploitation.

How TPM-only mode actually works

When BitLocker runs in TPM-only mode, here's roughly what happens on boot:

text

1. UEFI fires up
2. The TPM measures the boot chain (PCR values)
3. If PCR state matches what was sealed, the TPM releases the VMK
4. Windows decrypts the FVEK and mounts the volume

There's no password prompt because the TPM itself is the gatekeeper. The Volume Master Key sits inside the TPM and only comes out if the boot environment looks unchanged.

The problem is the word out. That key has to travel from the TPM chip to the CPU somehow.

The root cause: the bus is not the chip

On a lot of consumer and business hardware, the TPM is a discrete chip connected to the chipset over an LPC bus or, on newer boards, an SPI bus. These are slow, predictable buses with documented protocols.

When the TPM releases the VMK, it ships those bytes in cleartext across that bus. Anyone with a logic analyzer hooked to the right pads can capture them.

I haven't reproduced this attack hands-on myself, but the research is public — write-ups from Denis Andzakovic and others have demonstrated the capture and the protocol parsing in detail, and the hardware cost is under a hundred dollars. So the chain of trust breaks like this:

The attacker steals the laptop
They open it (often just a few screws)
They probe the TPM bus during boot
They capture the VMK as it transits the bus
Game over

No password was ever entered. The TPM did its job perfectly. The key just got copied off the wire.

Confirming you're exposed

Run this on a Windows machine to see what protectors are configured on the system volume.

powershell

# List all key protectors on C:
Get-BitLockerVolume -MountPoint "C:" |
    Select-Object -ExpandProperty KeyProtector |
    Format-Table KeyProtectorType, KeyProtectorId

# If you only see "Tpm" and a "RecoveryPassword" protector,
# you're in TPM-only mode — vulnerable to bus sniffing.

What you want to see is TpmPin or TpmPinStartupKey in that list. Just Tpm means no pre-boot secret is required, which is exactly the configuration the attack targets.

You can also check whether the TPM is discrete or firmware-based:

powershell

# fTPM (firmware TPM) lives inside the CPU package — no external bus
# Discrete TPM sits on the motherboard — has an attackable bus
Get-WmiObject -Namespace "Root\CIMV2\Security\MicrosoftTpm" `
              -Class Win32_Tpm |
    Select-Object ManufacturerIdTxt, ManufacturerVersion

A firmware TPM (Intel PTT or AMD fTPM) isn't immune to all attacks, but the specific bus-sniffing technique doesn't apply because there's no external bus to sniff. That's not a free pass — fTPM has its own attack surface — but it removes this particular foothold.

The fix: add a pre-boot secret

The mitigation Microsoft has recommended for years is straightforward. Require a PIN or a startup key in addition to the TPM. Even if an attacker captures bus traffic, they can't get the VMK released in the first place, because the TPM won't unseal it until the human enters the PIN.

Push it via Group Policy:

text

Computer Configuration > Administrative Templates >
  Windows Components > BitLocker Drive Encryption >
  Operating System Drives

"Require additional authentication at startup": Enabled
"Configure TPM startup PIN": Require startup PIN with TPM

Or set the registry directly for testing:

powershell

$path = "HKLM:\SOFTWARE\Policies\Microsoft\FVE"
New-Item -Path $path -Force | Out-Null

# Require pre-boot auth
Set-ItemProperty -Path $path -Name "UseAdvancedStartup" -Value 1
# Require a PIN with the TPM
Set-ItemProperty -Path $path -Name "UseTPMPIN" -Value 1
# Disallow bare TPM-only
Set-ItemProperty -Path $path -Name "UseTPM" -Value 2

Then re-enroll the protector:

powershell

$pin = Read-Host -AsSecureString "Enter new BitLocker PIN"
Add-BitLockerKeyProtector -MountPoint "C:" `
                          -TpmAndPinProtector `
                          -Pin $pin

# Remove the bare TPM protector once the new one is in place
$tpmOnly = (Get-BitLockerVolume -MountPoint "C:").KeyProtector |
    Where-Object { $_.KeyProtectorType -eq "Tpm" }
Remove-BitLockerKeyProtector -MountPoint "C:" `
                             -KeyProtectorId $tpmOnly.KeyProtectorId

After that, the boot flow needs the PIN before the TPM will release anything, and bus sniffing captures nothing useful.

Secondary hardenings worth doing

A PIN buys you a lot, but layer some defense in depth on top:

Kernel DMA Protection. Blocks Thunderbolt/PCIe peripherals from reading memory before user login. Microsoft's docs cover the firmware prerequisites.
Modern Standby vs hibernation. On Modern Standby systems, the VMK stays resident in RAM during sleep, which puts cold-boot style attacks back in play. For sensitive endpoints, force hibernation so BitLocker re-seals.
Tamper evidence. A bus-sniffing attack requires physical access to the board. Tamper-evident screws or chassis intrusion detection won't stop it, but they'll tell you it happened.
Encrypted TPM sessions. TPM 2.0 supports encrypted command sessions between host and chip. Some platforms negotiate this; many don't by default. Check your firmware vendor's documentation before assuming it's on.

Prevention as policy, not config

The thing I keep coming back to with my coworker's team is that "BitLocker enabled" is a checkbox that compliance frameworks love but attackers don't care about. The questions that actually matter:

Are pre-boot PINs required on every laptop?
Is the default image set up that way, or did someone disable it because users complained?
Is there a detection that fires when a managed device's protector set regresses to TPM-only?

That last one is underrated. People disable PINs. Helpdesk tickets get answered by removing the PIN to "fix" a boot issue. Make protector configuration something your endpoint management actually monitors, not just provisions once and forgets.

Encryption gives you guarantees about cold storage. The interesting attacks happen on the live boot path, and that's where most of these bypasses live. Worth auditing your fleet this week.