TPM 2.0: The Hardware Root of Trust Your Windows Security Depends On

When Microsoft made a TPM 2.0 chip a hard requirement for Windows 11, a lot of people treated it as an arbitrary hurdle - one more reason their perfectly good PC "wasn't supported." But the TPM is not busywork. It is the piece of silicon that makes the difference between "my disk is encrypted" and "my disk is encrypted and the key can't be trivially extracted." It is the anchor that lets Secure Boot, BitLocker, Windows Hello, and Credential Guard actually mean something. If it's missing, disabled, or unhealthy, a whole stack of security features quietly degrades to "encryption theater."

This post explains what the TPM does in plain terms, why its state (not just its presence) matters, and how to audit it on a single machine or across a fleet.

What a TPM actually is

A Trusted Platform Module is a small, tamper-resistant cryptographic coprocessor. On modern machines it's usually not a discrete chip at all but firmware TPM (fTPM) running in the CPU's secure enclave - Intel PTT or AMD fTPM. Either way, the contract is the same: it can generate and store keys that never leave the chip in plaintext, and it can measure the boot process into tamper-evident registers.

Two capabilities matter for endpoint security:

• Sealed key storage. A key can be "sealed" so it is only released when the machine is in a known-good state. BitLocker uses this: the volume master key is sealed to the TPM and only unsealed if the boot chain hasn't been tampered with.
• Platform measurement. As the machine boots, each stage hashes the next and extends the result into Platform Configuration Registers (PCRs). You can't rewind a PCR - you can only extend it. That makes the boot sequence tamper-evident, which is exactly what measured boot and remote attestation rely on.

What breaks when the TPM isn't there (or isn't healthy)

The failure mode is rarely a loud error. It's a silent downgrade:

• BitLocker without a TPM falls back to a password or USB key protector - or, worse, gets configured with weaker protection and no pre-boot integrity check. The disk is "encrypted," but the assurance that the key won't be released to a tampered boot chain is gone.
• Secure Boot and measured boot lose their attestation anchor. Secure Boot can still block unsigned bootloaders, but you can no longer prove to a management server that a machine booted clean.
• Windows Hello for Business credentials are meant to be TPM-bound. Without a TPM they fall back to software key storage, which is far easier to exfiltrate.
• Credential Guard and virtualization-based security depend on TPM-backed keys to protect secrets in an isolated VTL. No TPM means those protections are hollow.

And "TPM present" is not the same as "TPM usable." A TPM 1.2 chip won't support SHA-256 PCR banks. A TPM in a bad state (not owned, not ready, needs clearing) can be present in Device Manager while BitLocker refuses to bind to it. A firmware TPM disabled in BIOS shows up as "no TPM" to Windows even though the hardware is right there.

How to check your TPM by hand

The fastest built-in check is the TPM management console:

tpm.msc

It shows the manufacturer, spec version, and a "The TPM is ready for use" status. For something scriptable, PowerShell exposes the same data:

Get-Tpm

# Key fields:
#   TpmPresent   : True
#   TpmReady     : True
#   TpmEnabled   : True
#   TpmActivated : True
#   TpmOwned     : True

To confirm the spec version and PCR banks (you want 2.0 and a SHA-256 bank):

Get-CimInstance -Namespace root\cimv2\security\microsofttpm -ClassName Win32_Tpm |
  Select-Object SpecVersion, ManufacturerIdTxt, ManufacturerVersion

And to see whether BitLocker is actually using the TPM as a key protector - the thing you really care about:

Get-BitLockerVolume -MountPoint C: |
  Select-Object -ExpandProperty KeyProtector

If you don't see a Tpm or TpmPin protector in that list, your encryption isn't anchored to hardware, regardless of what Get-Tpm reports.

What "good" looks like

• TPM present, spec version 2.0, and enabled in firmware.
• TpmReady = True and TpmOwned = True - Windows can bind keys to it.
• A SHA-256 PCR bank available (needed for modern measured boot).
• BitLocker on the OS volume with a TPM-based protector, ideally TPM + PIN for high-value machines so a stolen laptop can't cold-boot straight into the desktop.
• Secure Boot enabled, so the measurements the TPM records reflect a signed boot chain.

Auditing it at scale

Checking one machine with tpm.msc is easy. Checking every machine in an organization - and catching the laptop where a BIOS update quietly reset the TPM, or the batch of refurbished PCs that shipped with fTPM disabled - is where manual checks fall apart.

WinSentinel's Encryption module folds TPM state into a machine's overall posture: it reports whether a TPM 2.0 is present and ready, whether BitLocker is bound to it, and whether Secure Boot is enabled to give those measurements meaning. That runs locally and free on a single machine. If you're responsible for a fleet, WinSentinel Pro rolls those findings up so you can answer "which of my 60 endpoints have BitLocker that isn't hardware-anchored?" in one view instead of RDP-ing into each box.

The TPM is the quiet foundation the rest of your Windows security stands on. It's worth confirming it's actually there, actually enabled, and actually being used - not just assumed.

Install the free CLI and check your own machine in about 20 seconds:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

See the audit modules for everything the Encryption module inspects, or read the companion post on Secure Boot, measured boot, and memory integrity for how these firmware protections fit together.