The Windows Encryption Audit Nobody Runs: BitLocker, TPM, and the Cert Store

Ask most Windows admins whether their machines are encrypted and you'll get a confident yes. BitLocker's on. The little padlock shows up in Explorer. Done.

Then you actually look, and the picture falls apart. BitLocker is on for C: but the D: data drive that holds the database backups is wide open. The recovery key is escrowed nowhere. The TPM is sitting at version 1.2, so half the hardware-backed protections silently never engaged. There are three SHA-1-signed certificates in the personal store and a self-signed root CA that a long-uninstalled proxy left behind. TLS 1.0 is still enabled on the SChannel server side. None of that shows up as a padlock, and none of it is what an attacker who already has a foothold cares about.

“Is BitLocker on?” is the first question of an encryption audit, not the whole thing. Here is what a real one covers, why each part matters, and how to check it yourself.

1. BitLocker — every fixed drive, not just the OS volume

The most common BitLocker mistake isn't “it's off.” It's “it's on for the volume nobody was worried about.” Windows happily encrypts C: during setup and leaves secondary fixed drives untouched. Those secondary drives are usually where the interesting data lives — backups, VM images, exported reports.

Check every fixed volume, and check the protector configuration, not just the on/off bit:

# Per-volume status, protection state, and key protectors
manage-bde -status

# Or, structured:
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionPercentage, EncryptionMethod

# What protectors guard each volume? (TPM, RecoveryPassword, etc.)
(Get-BitLockerVolume -MountPoint C:).KeyProtector

Two findings that a naive check misses: a volume stuck at EncryptionInProgress (it is not protected yet), and a volume whose only protector is a numeric recovery password with no TPM binding — which means it isn't transparently unlocking and someone is probably storing the recovery key in a sticky note. WinSentinel's Encryption module walks each fixed drive, parses the protection state and method, and flags volumes that are unencrypted or only partially encrypted instead of reporting a single machine-wide “yes.”

2. TPM — present is not the same as ready

BitLocker, Credential Guard, and Windows 11 itself all lean on the TPM. But “a TPM exists” and “the TPM is enabled, activated, and version 2.0” are three different facts, and only the last one buys you the modern protections.

Get-Tpm | Format-List TpmPresent, TpmReady, TpmEnabled, ManufacturerVersionFull20

The case that bites people is TPM 1.2. It's present, it's enabled, BitLocker even uses it — so every surface-level check says “good.” But TPM 1.2 can't back Credential Guard the way 2.0 does, and it blocks the Windows 11 upgrade path. On most machines built in the last several years, 2.0 is already in the CPU (Intel PTT / AMD fTPM) and just needs to be switched on in UEFI. WinSentinel explicitly flags a detected 1.2 module as outdated rather than letting “TPM: present” paper over it.

3. EFS — the encryption you forgot you had

Encrypting File System is per-file, per-user encryption that rides on a certificate in your personal store. It's easy to forget it exists — until a user encrypts a folder, the certificate is lost on a reinstall, and the data is gone. An audit should know whether EFS is disabled by policy, available on demand, or actively in use with certificates present, because each state has a different recovery story.

# Is EFS disabled by policy?
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\EFS" -Name EfsConfiguration -EA SilentlyContinue

# EFS certificates in the user's personal store (EKU 1.3.6.1.4.1.311.10.3.4)
Get-ChildItem Cert:\CurrentUser\My |
  Where-Object { $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.4.1.311.10.3.4' }

If EFS certificates exist, the action item is simple and urgent: back up the certificate and private key somewhere safe. Lose it and you lose the files — BitLocker won't save you, because EFS encrypts above the volume layer.

4. The certificate store — where weak crypto hides in plain sight

The personal and trusted-root certificate stores are a blind spot on almost every machine. Three things to look for:

• Expired or expiring-soon certs — expired certs cause mysterious service outages; expiring ones are a countdown you want to see before the outage, not after.
• Weak keys and signatures — RSA below 2048 bits, or anything signed with SHA-1 / MD5 / MD2. These are cryptographically broken and have no business in a live store.
• Rogue user-level root CAs — a self-signed certificate in CurrentUser\Root is exactly what an intercepting proxy (Fiddler, Burp, mitmproxy) or some adware installs to read your TLS traffic. Sometimes it's legitimate corporate tooling; sometimes it's the leftover of something you uninstalled; occasionally it's hostile. Either way you want to know it's there.

# Expired certs in the personal store
Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.NotAfter -lt (Get-Date) } |
  Format-List Subject, NotAfter

# User-installed trusted roots (these should be rare and recognizable)
Get-ChildItem Cert:\CurrentUser\Root | Format-List Subject, Issuer, NotAfter

WinSentinel scores the personal store for expiry, key size, and signature algorithm, and separately flags self-signed certificates in the user trusted-root store — the single most useful certificate finding on a developer's machine, because dev tooling litters that store constantly.

5. TLS / SChannel — the protocols the OS will still speak

SChannel is the Windows component that negotiates TLS for almost everything: RDP, LDAPS, WinRM, .NET clients. Its protocol behavior is controlled by registry keys under SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols, and the defaults are not what you'd hope. A real audit verifies two directions at once:

• Legacy protocols are actually disabled — SSL 2.0/3.0 and TLS 1.0/1.1, on both the Client and Server sub-keys. “We disabled SSL 3.0” on the client while the server half still answers is a partial fix that scanners catch.
• Modern protocols aren't accidentally turned off — someone hardening a box by hand occasionally disables TLS 1.2 along with the legacy ones, which is its own outage waiting to happen.

# Is TLS 1.0 Server still enabled? (want Enabled=0 / DisabledByDefault=1)
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -EA SilentlyContinue

The encryption module checks each legacy protocol's Client and Server keys, distinguishes “explicitly disabled” from “not configured, relying on OS default,” and also scans the configured cipher-suite order for the usual suspects — RC4, DES, NULL, EXPORT, MD5.

6. Credential Guard and DPAPI — protecting the secrets themselves

The last layer isn't about data at rest on disk — it's about the credentials in memory and the keys that protect everything else.

Credential Guard uses virtualization-based security to wall off NTLM hashes and Kerberos tickets so that a tool like Mimikatz can't scrape them out of LSASS. Without it, an attacker who lands code execution on the box can often harvest credentials and move laterally in minutes. It's configured but frequently not running because a hardware prerequisite (UEFI Secure Boot, virtualization extensions, TPM 2.0) isn't met — so checking the policy flag alone lies to you; you have to confirm it's actually running.

# Is Credential Guard actually running? (1 in the array = Credential Guard)
(Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

DPAPI is the Data Protection API that Windows, browsers, and countless apps use to encrypt saved passwords and tokens. Its master keys are ultimately protected by the user's login password — unless Credential Guard or domain backup raises the bar. An audit should report which of those protections is actually in play, because “protected by a weak login password alone” is a very different risk than “backed by Credential Guard.”

Why this is one audit, not seven scripts

You can run every snippet above by hand. The problem is that nobody does it twice. Encryption posture drifts: a new drive gets added unencrypted, a certificate expires, someone disables a protocol during troubleshooting and forgets to undo it, a TPM gets reset after a firmware update. The value isn't in checking once — it's in checking every time and getting told what changed.

That's what the Encryption module does inside WinSentinel: one pass covers BitLocker per volume, TPM presence/readiness/version, EFS, the certificate stores, SChannel protocols and cipher suites, Credential Guard, and DPAPI — each finding rated by severity with a concrete remediation. It's part of the free, single-machine tool; there's no fleet or license gate on running it locally.

# Install the CLI and audit the encryption posture on this machine
dotnet tool install --global WinSentinel.Cli
winsentinel --audit --category Encryption

Run it once and you'll almost certainly find at least one of the things above — a second drive that was never encrypted, a TPM that's enabled but stuck at 1.2, or a SHA-1 certificate that should have been retired years ago. The padlock said everything was fine. It wasn't.