The Tiny Chip That Quietly Rules Your Windows Security
“Every measurement tells a story.”
For years, the Trusted Platform Module (TPM) sat quietly on motherboards around the world, doing its job without asking for attention. Then Windows 11 arrived and suddenly everyone was asking:
“Wait… what is a TPM and why does Microsoft suddenly care so much?”
The funny thing is that Microsoft has cared about TPM for almost two decades. Enterprise Architects and IT Pros know that part of the piece. Residential users, home users were a bit shocked when that requirement hit the stage.
A Short Trip Through TPM History
Back in the Windows Vista era, Microsoft introduced BitLocker Drive Encryption. While BitLocker could work with USB startup keys and PINs, the real magic happened when a TPM 1.2 chip was present.Instead of simply storing encryption keys somewhere on disk, BitLocker could seal its secrets inside dedicated hardware that could verify whether the system had been tampered with before releasing them. The result?
A stolen disk became significantly harder to access, and boot-level attacks suddenly had a much tougher opponent.
As security requirements evolved, TPM 2.0 arrived. Rather than merely being a newer version, TPM 2.0 introduced more flexible cryptographic algorithms, stronger attestation capabilities, modern key management and support for scenarios that didn’t even exist when Vista launched.
Fast forward to today, and TPM 2.0 has become the foundation for many of Windows’ most important security features. Think of it as Windows’ hardware-backed vault, detective, identity provider and lie detector all rolled into one tiny chip.
TPM Myth #1: “The TPM Stores All Your Secrets”
One of the most common explanations of a TPM goes something like this:
“The TPM is a secure chip that stores encryption keys.”
That sounds simple. It is also slightly wrong. A TPM is not designed to be a tiny hardware vault packed with secrets. In fact, storing large amounts of persistent sensitive data on a TPM would be a terrible idea from both scalability and security perspectives. What the TPM actually provides is something far more powerful:
protected cryptographic operations.
Instead of asking:
“Can I store my secret here?”
The better question is:
“Can I use the secret available in that table, without exposing it?”
That distinction changes everything.
The TPM can generate keys, protect keys, bind keys to specific platform states and perform cryptographic operations on behalf of software. The important part is that private key material remains non-exportable and protected by TPM policy. Windows doesn’t trust the TPM because it stores secrets. Windows trusts the TPM because the TPM can prove that secrets were used correctly without revealing them. In short, storing your own values is simply not allowed. changing values can be allowed if you are TPM Owner. Imagine I’m allowed to store some malicious code in the TPM? this is the actual strength of the TPM chip.
Root of Trust for Storage
The Name Everyone Uses… And Why It Is Slightly Misleading
The TPM specification refers to a Root of Trust for Storage (RTS). That name often leads people to imagine a miniature hardware safe filled with certificates and passwords. The reality is much more interesting. The RTS is a trust anchor responsible for protecting cryptographic objects through TPM-controlled mechanisms.
Keys can be bound to:
- Platform state
- PCR values
- User authorization
- Device identity
- Attestation policies
A key may exist in wrapped form outside the TPM and only become usable when the TPM validates the required conditions. Think of the TPM less as a vault and more as a highly suspicious security guard. The key may be sitting nearby. The TPM simply refuses to use it unless everything looks exactly as expected.
BitLocker: A Perfect Example
BitLocker is often described as:
“The encryption key is stored in the TPM.”
Again, not entirely accurate, it is stored on the hard drive. and as long as the encryption key matches the encryptic value of the TPM chip (based on the values of the TPM Chip), BitLocker can be unlocked, if at least that is your only metric.
What actually matters is that the TPM will only release or enable access to the BitLocker protector when specific PCR measurements match expected values.
If someone changes:
- UEFI firmware
- Secure Boot settings
- Boot Manager
- Early boot components
- Other PCR measured values..
the PCR values change, and the calculated encryption no longer matches the encryption key stored on the… hard drive. Which in essence does not allow you to unlock BitLocker. It will profoundly go to recovery mode.
The goal is secure authorization based on measured platform integrity.
PCRs Are the Real Stars
If there’s one TPM component Windows truly relies on every day, it’s the PCRs. PCRs are not storage locations for secrets. They are measurement registers.
Every step in the boot chain contributes cryptographic measurements which are extended into PCRs. Windows security features lean heavily on this capability:
- BitLocker: Uses PCRs to determine whether the platform booted as expected.
- Measured Boot: Records the entire boot story from UEFI to the Windows kernel.
- Device Health Attestation: Uses PCR measurements to verify platform health.
- Conditional Access: Allows cloud services to make trust decisions based on attested measurements. If the TPM were a detective story, the PCRs would be the notebook containing all the evidence.
A Better Definition of TPM
Instead of saying:
“A TPM stores keys.”
I’d suggest:
“A TPM is a hardware root of trust that protects cryptographic operations, measures platform integrity and enables secure attestation of device identity and health.”
Less marketing,more technically correct. And honestly, much more impressive.
Lady Itris Nerd Note 💜
If you hear someone say “BitLocker stores its key in the TPM”, don’t immediately correct them at a conference coffee break. The simplified explanation is common. But technically the TPM’s real value lies in policy-controlled key usage, measured boot and attestation, not in acting as a miniature encrypted hard drive.
Alright, we’ve already covered quite some things, but we haven’t shown the actual architecture.
What Is a TPM?
A Trusted Platform Module (TPM) is a dedicated security processor that acts as a hardware Root of Trust. A TPM does not exist to store large amounts of information. Instead, it provides protected cryptographic functions, records measurements about the platform state, and allows software and cloud services to verify that a device is operating as expected. At its core, the TPM provides three trust services:
- Trust for Measurement
- Trust for Storage
- Trust for Reporting
Everything else is built on top of those foundations.
Into the Rabbit Hole: The Objects Living Inside a TPM
The TPM specification defines dozens of cryptographic objects, hierarchies, authorization models and measurements. Most documentation immediately jumps to BitLocker and Windows Hello for Business, but that skips the most interesting part. Let’s first understand the TPM itself. Imagine entering an extremely paranoid building. Every room has guards. Every guard reports to another guard. Nobody trusts anyone without cryptographic proof.
Welcome to TPM-land
Before we start dissecting PCRs, attestation and measured boot, we first need to answer a question that most TPM documentation completely skips: who is actually allowed to make the TPM do something?
This sounds like a simple question until you realize that a TPM is not passive hardware. A TPM isn’t comparable to RAM, a disk controller or a network adapter. Those components generally perform whatever operation the operating system requests. The TPM is much closer to a security officer than a hardware component. Every sensitive command is evaluated against authorization rules, hierarchy permissions and policies before it is allowed to execute. This design exists because a TPM is supposed to remain trustworthy even if the operating system itself becomes compromised.
Historically, TPM 1.2 introduced the concept of ownership. Taking ownership of the TPM established an authorization secret and allowed management operations to be performed. Unfortunately, this created a misconception that still exists today. Many administrators came away with the impression that TPM ownership was similar to becoming a local administrator in Windows. In reality, ownership never meant unrestricted control. The TPM always remained the final authority regarding what operations could be performed.
With TPM 2.0, the concept evolved significantly. Instead of relying on a single owner, the TPM introduced multiple hierarchies, each governing a different trust domain within the chip. There is an Endorsement Hierarchy that represents TPM identity, a Storage Hierarchy responsible for protected objects and key relationships, a Platform Hierarchy that allows firmware-level control over certain TPM functions, and a Null Hierarchy used for temporary objects that leave no persistent footprint.
This distinction becomes important when people talk about PCR modification or TPM Quotes. A common statement is that “you need TPM ownership to change values.” Technically, that isn’t quite correct. The TPM evaluates whether the caller possesses sufficient authorization within the appropriate hierarchy, whether the requested operation is valid for that PCR, whether platform locality requirements are satisfied, and whether policy restrictions permit the action. The TPM ultimately decides whether the request is allowed. Ownership is therefore less about having control over the TPM and more about being trusted to ask certain questions.
This architecture also explains why TPM attestation carries so much weight. When a TPM produces a Quote, it is not simply dumping internal data structures. The Quote operation is protected because its output becomes evidence. A verifier receiving a Quote must be able to trust that the measurements genuinely originated from the TPM and were not fabricated by software running on the machine. The TPM’s authorization model is therefore the first layer in a much larger chain of trust.
Once authorization has been established, the next challenge becomes identity. If a TPM is going to provide evidence, a remote system needs a way to determine whether that evidence came from a genuine TPM manufactured by a trusted vendor rather than from software pretending to be one. This is where the Endorsement Key enters the picture.
The Endorsement Key, commonly referred to as the EK, is often described as the TPM’s identity. While that description is reasonably accurate, it hides some interesting details. The EK is actually a persistent asymmetric key pair that exists within the Endorsement Hierarchy. Modern TPM 2.0 implementations typically contain an RSA Endorsement Key, an ECC Endorsement Key, or both. The private portion of the key is generated and protected within the TPM boundary and is specifically designed to remain non-exportable. If an attacker could extract the private Endorsement Key, it would become possible to clone TPM identities and undermine the entire attestation model.
The public portion of the Endorsement Key, often called EKPub, is a very different story. The public key can be retrieved and shared because public keys are not secrets. However, an EKPub by itself has very little value. A verifier receiving a public key has no way of knowing whether it belongs to a genuine TPM, a software emulator, or a laptop somewhere across the planet. Cryptography alone proves possession of a key pair. It does not prove where that key originated.
This problem is solved through the Endorsement Key Certificate, or EKCert. During manufacturing, TPM vendors provision a certificate that cryptographically binds the Endorsement Key to the TPM hardware. The certificate is signed by a manufacturer-controlled certificate authority and effectively serves as a statement saying that this specific Endorsement Key belongs to a TPM produced by that vendor. Suddenly the public key becomes meaningful. A verifier can validate the certificate chain, verify the manufacturer’s signature, and establish confidence that the TPM is genuine.
Interestingly, the EK is rarely used directly in operational attestation. If every attestation transaction exposed the Endorsement Key, devices would become trivially trackable across services and organizations. Microsoft, Google, Linux vendors, cloud providers and any other relying party could theoretically recognize the same physical TPM every time it interacted with them. From a privacy perspective, that would be a nightmare. I once did such a project, where the EK (not the EKCert) was used to enroll certificates! Imagine the possibilities. ( I will come back to this topic)
Instead, TPMs create Attestation Identity Keys, commonly called AIKs or, in TPM 2.0 terminology, Attestation Keys. These keys act as privacy-preserving representatives of the TPM. Trust in the Attestation Key is ultimately derived from the Endorsement Hierarchy, but day-to-day attestation operations occur using the AIK rather than the EK itself. This allows a verifier to trust the attestation without requiring direct exposure of the TPM’s permanent hardware identity.
When a Quote operation occurs, the TPM gathers the requested PCR measurements, incorporates a verifier-provided nonce to prevent replay attacks, packages the resulting information into an attestation structure, and signs that structure with an Attestation Key. The output is not merely a list of PCR values. It is cryptographically signed evidence linking those measurements to a genuine TPM. The verifier can independently validate the signature, confirm freshness through the nonce, validate the certificate chain behind the attestation key, and establish confidence that the measurements have not been fabricated or altered.When a Quote operation occurs, the TPM gathers the requested PCR measurements, incorporates a verifier-provided nonce to prevent replay attacks, packages the resulting information into an attestation structure, and signs that structure with an Attestation Key. The output is not merely a list of PCR values. It is cryptographically signed evidence linking those measurements to a genuine TPM. The verifier can independently validate the signature, confirm freshness through the nonce, validate the certificate chain behind the attestation key, and establish confidence that the measurements have not been fabricated or altered.
Establishing Identity:
The TPM’s identity begins with the Endorsement Key (EK). This is a persistent asymmetric key pair provisioned under the Endorsement Hierarchy and serves as the foundational identity of the TPM itself. Notice the wording carefully: TPM identity, not device identity. If you replace a motherboard containing a discrete TPM, you have effectively replaced the TPM identity even if Windows remains unchanged. The private portion of the EK is designed to remain non-exportable throughout the lifetime of the device. If a private EK could be copied to another platform, attestation would immediately become meaningless because TPM identities could be cloned.
The public half of this key pair is called the Endorsement Public Key (EKPub). This key can be safely shared with external systems and attestation services. However, an EKPub alone proves absolutely nothing. Anyone can generate a public key. The existence of a public key only proves that a key pair exists, not that it belongs to genuine TPM hardware.
This is where the Endorsement Key Certificate (EKCert) comes into play. During manufacturing, the TPM vendor signs a certificate containing information about the TPM and its associated EKPub. This certificate typically contains the TPM manufacturer’s identity, model information and the associated public endorsement key. When a remote verifier validates an EKCert, it effectively validates a chain of trust back to the TPM vendor. In other words, the verifier is not trusting the TPM because the TPM says it is genuine. The verifier trusts the TPM because the manufacturer cryptographically vouched for it.
Exposing the EK for every attestation operation would create a privacy disaster. Every service could identify the same TPM forever. To solve this problem, the TPM generates Attestation Identity Keys (AIKs), known in TPM 2.0 as Attestation Keys (AKs). These are signing keys specifically intended for attestation operations. The trustworthiness of the AIK ultimately derives from the Endorsement Hierarchy, but operational attestation uses the AIK rather than the EK itself. Think of the EK as your passport and the AIK as the temporary visitor badge you use every day. People trust the badge because it was issued from an already trusted identity source.
Establishing measurements:
PCRs, or Platform Configuration Registers, are probably the most important structures inside the TPM. Despite the name, they behave nothing like traditional processor registers. A CPU register can be overwritten at will. A PCR cannot. PCRs are only updated through a process called extension. Whenever a new measurement arrives, the TPM calculates:
PCRnew = HASH(PCRold || NewMeasurement)
The existing PCR value becomes part of the next PCR value. This means history accumulates. Measurements are chained together. A PCR therefore becomes a cryptographic representation of everything that happened before it.
The TPM specification defines twenty-four PCRs.
- PCR 0 contains measurements associated with the Core Root of Trust for Measurement (CRTM), BIOS or UEFI firmware and the earliest code executed during startup.
- PCR 1 contains measurements associated with platform configuration. Firmware settings and platform-specific configuration information frequently influence this register.
- PCR 2 contains measurements of Option ROM code. Traditionally this includes firmware executed by devices such as RAID controllers, storage adapters and network adapters before the operating system loads.
- PCR 3 contains measurements of Option ROM configuration and settings.
- PCR 4 contains measurements associated with the platform boot manager. In Windows systems this typically relates to the Windows Boot Manager.
- PCR 5 records boot configuration information, including configuration used during operating system startup.
- PCR 6 is used for platform state transitions and various host platform events during startup.
- PCR 7 is arguably the most famous PCR in modern Windows deployments. PCR 7 contains measurements associated with Secure Boot state and policies. This includes the Platform Key (PK), Key Exchange Keys (KEK), allowed signature databases (db), forbidden signature databases (dbx) and Secure Boot configuration itself. If PCR 7 changes unexpectedly, BitLocker often becomes extremely interested since Windows 10.
- PCR 8 through PCR 15 are used for operating-system specific and implementation-dependent measurements. These registers extend the trust chain beyond firmware and into the operating system loading process.
- PCR 16 through PCR 23 are generally reserved for Dynamic Root of Trust for Measurement (DRTM) environments. Technologies such as Intel TXT, AMD SKINIT and Microsoft System Guard use these registers to establish a new trust boundary after the platform has already booted.
The TPM specification supports multiple PCR banks simultaneously. A system may maintain a SHA-1 PCR bank, a SHA-256 PCR bank and additional PCR banks at the same time. Every measurement extends into multiple banks, producing different PCR values based on the hashing algorithm used. Modern Windows environments primarily rely on SHA-256 PCR banks.
One of the most misunderstood TPM capabilities is sealing. Sealing does not mean storing a secret inside a PCR. It means protecting the usage of an object behind policy requirements. A TPM may seal an object to PCR values so that the object only becomes usable when specific measurements match the state that existed when the object was created. If PCR values differ from the expected values, the TPM refuses the operation. This is the mechanism heavily relied upon by BitLocker. The encryption key is stored on disk, but its availability depends on TPM policy evaluation and PCR state.
All these measurements eventually become evidence through the TPM2_Quote() command. During a quote operation, a verifier sends a random nonce to prevent replay attacks. The TPM gathers selected PCR values, packages them into a TPMS_ATTEST structure and signs the resulting data using an Attestation Key. The resulting Quote contains the selected measurements, TPM metadata, clock information, firmware information and a cryptographic signature. The verifier can independently validate the signature and verify that the measurements originated from a genuine TPM.
At this point the architecture shown in the diagram begins to make sense. The EK and EKCert establish trust in the TPM itself. The AIK provides a privacy-preserving attestation identity. PCRs record the history of platform execution. Sealing ties cryptographic operations to measured platform states. Quotes transform measurements into evidence. Everything else in the TPM ecosystem is built on top of these primitives.
| TPM Primitive | Windows Consumer | Purpose |
|---|---|---|
| EK (Endorsement Key) | TPM Identity | Establishes the cryptographic identity of the TPM itself |
| EKCert (Endorsement Key Certificate) | AD CS Key Attestation Trust | Proves that the TPM originates from a trusted manufacturer |
| AIK / AK (Attestation Identity Key / Attestation Key) | AD CS Key Attestation Signing | Signs attestation evidence for certificate enrollment |
| TPM Attestation Evidence | AD CS Certificate Issuance Decision | Allows the CA to determine whether a hardware-protected key should receive a certificate |
| TPM-Protected Key | Windows Hello for Business | The actual user credential; the private key remains non-exportable and TPM-protected |
| TPM Authorization Policy | Windows Hello for Business | PIN, fingerprint, or facial recognition unlocks the use of the protected key |
| EK / EKCert | Windows Hello for Business Provisioning | Proves that keys were generated on genuine TPM hardware |
| AIK / AK | Windows Hello for Business Key Attestation | Demonstrates that authentication keys are TPM-bound and hardware protected |
| Storage Hierarchy | Windows Hello for Business | Protects and manages user authentication keys |
| Attested Certificates | Windows Hello for Business Certificate Trust | Allows AD CS to issue certificates only for TPM-protected keys |
| TPM-Sealed Objects | BitLocker | Protects the BitLocker protector and controls when it may be used |
| PCR 0 | BitLocker, Measured Boot | Measures CRTM, firmware, and early boot components |
| PCR 1 | BitLocker, Measured Boot | Measures platform configuration information |
| PCR 2 | BitLocker, Measured Boot | Measures Option ROM code |
| PCR 3 | BitLocker, Measured Boot | Measures Option ROM configuration |
| PCR 4 | BitLocker | Measures the Windows Boot Manager |
| PCR 5 | BitLocker | Measures boot configuration data (BCD) |
| PCR 6 | Measured Boot | Measures platform state transitions |
| PCR 7 | BitLocker, Secure Boot | Measures PK, KEK, db, dbx, and Secure Boot configuration |
| PCR 8-15 | Measured Boot | Extend the trust chain into the operating system startup process |
| PCR 16-23 | Microsoft Defender System Guard | Support Dynamic Root of Trust for Measurement (DRTM) scenarios |
| PCR Extend Operations | Measured Boot | Build the measured boot chain from firmware to operating system |
| TPM Quote() | Device Health Attestation | Produces verifiable evidence of platform state |
| TPM Quote() | Microsoft Intune Compliance | Allows compliance decisions based on TPM measurements |
| TPM Quote() | Conditional Access | Supports hardware-backed trust decisions |
| AIK / AK | Device Health Attestation | Signs TPM Quotes and attestation evidence |
| Storage Hierarchy | Credential Guard | Protects credential-related cryptographic material |
| Storage Hierarchy | Virtual Smart Cards | Protects smart card keys without requiring physical cards |
| Sealing Policies | BitLocker | Ensure key material is only usable under expected platform conditions |
| EK / EKCert | Windows Autopilot | Establish hardware trust during device onboarding |
| EK / EKCert | Microsoft Entra Device Registration | Establish trust in the enrolling device |
| DRTM PCRs (16-23) | Microsoft Defender System Guard | Enable runtime attestation and post-boot trust establishment |
| Attested Certificates | AD CS Certificate Enrollment | Provide hardware-backed certificate issuance assurance |
| TPM-Protected Keys | VPN, Wi-Fi, 802.1X Certificates | Ensure private keys remain bound to TPM hardware |
The TPM doesn’t provide BitLocker, Windows Hello for Business, Device Health Attestation, or even Certificate Trust. It provides primitives. Windows simply consumes those primitives. The EK establishes identity. The EKCert establishes legitimacy. The AIK proves authenticity. The PCRs record history. Sealing enforces policy. Quotes provide evidence. Everything else is just Windows building security features on top of those building blocks. 💜
Are you still with me? This is a major foundation for Security. I hope I covered all the aspects. Trust, but verify. And when in doubt, let the TPM tell its side of the story.
Yours truly,
Lady Itris
The feminine nerd💜