The TPM in Windows: One Primitive, Twenty-Five Years, and the Chip Microsoft Bet On Twice

1. The chip nobody asked for#

On June 24, 2021, Microsoft announced Windows 11 ^[1] -- and told hundreds of millions of working PCs they were no longer eligible to upgrade. Not because they were too slow. Because they did not have a small chip most users had never thought about: a TPM 2.0. The PR backlash was immediate; the technical rationale was almost invisible. Why was Microsoft willing to take that much heat over a piece of silicon?

The next morning, Microsoft's security team tried to explain ^[2]. The argument was four words long: hardware root of trust.

"All certified Windows 11 systems will come with a TPM 2.0 chip to help ensure customers benefit from security backed by a hardware root-of-trust."

That sentence sat awkwardly against the user experience: a green checkmark in the PC Health Check tool, or a red X telling you to buy a new computer. The deeper claim -- that a passive cryptoprocessor underwrote the security guarantees of half the operating system -- was not something Microsoft had ever asked consumers to think about. For OEMs, the requirement was old news. Since July 28, 2016 ^[3], every new Windows device model had been contractually required to "implement and enable by default TPM 2.0." The 2021 mandate did not introduce the chip. It made an existing OEM rule into a visible install gate.

This article is about that piece of silicon: what it does, why Windows needs it more than ever, and why twenty-five years of engineering and twenty-five years of attacks have together produced a chip that quietly defines what modern Windows can defend against -- and what it cannot.

The central claim, which the rest of this piece will earn: a passive cryptoprocessor designed in 1999 became the load-bearing pillar of half of Windows security, and the history of attacks against it has been a sustained empirical argument about exactly how passive that pillar is allowed to be.

2. The problem the TPM was built to solve#

Picture an engineer at IBM in early 2000. The Windows kernel has just been rooted again. The newly shipped DPAPI master keys -- introduced with Windows 2000's general availability on February 17, 2000 ^[5] -- are recoverable in seconds once SYSTEM falls. Stolen ThinkPads come back with their fresh EFS volumes already decrypted. Where do you put a secret that the OS cannot read?

Software-only key storage was Generation 0. Windows had DPAPI, EFS, and LSA secrets ^[6], all deriving their wrapping keys from the user's logon credential or from system-level material. Every derivation had the same structural problem: the unwrapping key, sooner or later, lived in the kernel's address space. An attacker who reached SYSTEM (or who carried the disk away to a separate machine) could replay it. A volume encrypted "at rest" was decryptable as soon as the disk was readable -- and a disk you can read is a disk you can read offline. Microsoft now states the constraint plainly: a TPM-resident key, by contrast, "truly can't leave the TPM" ^[7]. That property cannot be retrofitted onto software-only storage.

Software-only key storage cannot defend against an attacker who reaches SYSTEM, and cannot defend against an attacker who carries the disk away. To survive both, the secret must live in silicon that the OS itself cannot read.

In October 1999 ^[8], five PC-industry incumbents took that observation and turned it into an industrial coalition: Compaq, Hewlett-Packard, IBM, Intel, and Microsoft incorporated the Trusted Computing Platform Alliance. The Wikipedia Trusted Computing Group article gives the day-precision date as October 11, 1999. The original TCPA press release URL has not survived; the founder list and date are consistent across secondary sources. TCPA's charter was narrow: define a chip that could hold keys an x86 OS could not export, record boot-time integrity measurements, and sign attestations about that boot. The first chip to ship against the resulting TPM Main Specification 1.1b ^[9] appeared in 2003 ^[10]. Atmel, Infineon, and STMicroelectronics built it.

In parallel, Microsoft Research ran its own bet. Paul England, Butler Lampson, John Manferdelli, Marcus Peinado, and Bryan Willman ^[11] published "A Trusted Open Platform" in IEEE Computer, July 2003. The codename inside Microsoft was Palladium; the public name was the Next-Generation Secure Computing Base, NGSCB. It described a Windows where high-assurance code could run isolated from a possibly-compromised OS kernel, anchored in a hardware secure coprocessor that looked very much like a TPM. The motivating sentence read like a thesis: NGSCB extends personal computers "to offer mechanisms that let high-assurance software protect itself from the operating systems, device drivers, BIOS, and other software running on the same machine."

NGSCB never shipped as advertised. By 2005, reports indicated ^[12] that Microsoft would ship "only part of the architecture, BitLocker, which can optionally use the Trusted Platform Module to validate the integrity of boot and system files prior to operating system startup." The "Nexus" hypervisor, the user-mode high-assurance "agents," the protected paths for keyboard and display -- all dropped against the Vista deadline. The deadline pressure on Vista is legendary. The architecture team chose to ship the smallest piece of NGSCB the existing chip could underwrite -- BitLocker -- and shelved the rest. That shelved piece eventually returned, fifteen years later, as Virtualization-Based Security and Credential Guard.

The shelved primitives, however, did not die. Measured boot -- the firmware measures the boot loader, the boot loader measures the kernel, each measurement extended into a register that cannot be rewound -- migrated into Vista BitLocker and, later, into Windows 8 Measured Boot. Sealed storage -- a key tied to a measured boot state, unreleasable unless the boot state matches -- became the defining property of every TPM-bound BitLocker volume. Remote attestation -- a device signing a quote of its own measurements for a remote verifier -- became Device Health Attestation. NGSCB shipped, just not as itself.

TCPA had built a chip that could hold a key the OS couldn't read. Which keys, under whose authority, against which threats? The first answer was almost good enough -- and it lasted about a decade.

3. Generation 1 and Generation 2: TPM 1.1b -> 1.2, and why they failed#

If you opened a 2007 ThinkPad and looked at the LPC bus next to the Super-IO chip, you would see a small Infineon SLB chip ^[13]. That was your TPM 1.2. It did exactly one job, and Vista's BitLocker was the first feature to depend on it.

The architectural skeleton of TPM 1.x ^[10] was simple. At least sixteen Platform Configuration Registers, with the PC Client TPM Interface Specification mandating 24 per active bank. Hash algorithm: SHA-1. Asymmetric algorithm: RSA-2048. A single root of storage, the Storage Root Key, whose private half never left the chip. An Endorsement Key burned in at manufacture as the chip's permanent identity. An HMAC-SHA1 authorization model over command parameters. A "Take Ownership" ceremony where the platform owner created the SRK and bound it to an owner secret.

TPM 1.2 ^[10], shipped in late 2003 and standardized as ISO/IEC 11889:2009, layered on the practical machinery: locality (a way for code at different privilege levels to extend different PCRs), monotonic counters, NV indices, transport sessions, and the eight-PCR split between firmware (PCR[0..7]) and OS (PCR[8..15]). It was the chip that mass-deployed in essentially every business PC from 2006 to 2014. When Windows Vista ^[12] reached volume-license RTM in late 2006 and broad availability in early 2007, BitLocker ^[14] (Enterprise and Ultimate editions only) became the first mainstream Windows feature whose security depended on the chip: BitLocker sealed the Volume Master Key to PCR values describing the boot-loader chain, so that a stolen disk could not be decrypted offline. Secure Boot binding (PCR[7]) would not arrive until UEFI Secure Boot ^[15] shipped with Windows 8 in 2012.

flowchart TD
EK["Endorsement Key (EK)
RSA-2048, burned at manufacture"]
Owner["Owner secret
(Take Ownership)"]
SRK["Storage Root Key (SRK)
RSA-2048, single per chip"]
K1["Storage key
(child)"]
K2["Binding key
(child)"]
K3["Signing key
(child)"]
AIK["Attestation Identity Key
(independent RSA key)"]
PCA["Privacy CA"]

Owner --> SRK
SRK --> K1
SRK --> K2
SRK --> K3
AIK --> PCA
EK -. cert .-> PCA

The problem with all of this was not that anyone broke it. The problem was that the architecture hard-coded its cryptographic primitives into its data structures. SHA-1 was not a configurable algorithm; it was the literal width of the PCR register and of every hash field in the spec. RSA-2048 was not a configurable algorithm; it was the literal layout of the EK, the SRK, and every protected key blob. If the world deprecated SHA-1, you did not patch the firmware. You replaced the chip.

NIST SP 800-131A deprecated SHA-1 ^[16] digital signatures starting in 2011. The 2017 SHAttered collision ^[17] drove the point home. The 2017 SHAttered SHA-1 collision does not retroactively break Vista BitLocker in practice -- to do that, an attacker would have to choose firmware blobs whose hashes collide, not merely demonstrate a collision exists. But it ended any defense of "SHA-1 in PCRs is fine because nobody can collide it." Algorithm flexibility cannot be retrofitted onto silicon whose data structures hard-code SHA-1. There were other limitations: a single SRK hierarchy meant clearing the chip's storage hierarchy also reset chip identity; the Privacy CA model for attestation never deployed at scale; ECC was missing; and the HMAC-based authorization model made every command exchange a piece of bespoke crypto plumbing.

TCG accepted the constraint in 2014 and started over. The 2.0 design did not add features to 1.2. It answered a different question: how do you let one TPM survive twenty years of cryptographic transitions?

4. Generation 3: TPM 2.0 -- one primitive, many algorithms#

On April 9, 2014 ^[10], the Trusted Computing Group ^[19] did something rare in standards bodies: they threw away a working specification and started from a different question. The result was the TPM 2.0 Library Specification, Family 2.0, Level 00, Revision 116. A year later it became ISO/IEC 11889-1:2015 Edition 2 ^[20], which removed the "industry consortium" objection from procurement teams in regulated environments. By July 28, 2016 ^[3], Microsoft had quietly made TPM 2.0 a contractual must-have for every new Windows OEM SKU.

Four conceptual changes carry the architecture.

4.1 Algorithm agility#

Every cryptographic algorithm in TPM 2.0 carries an integer identifier. PCRs no longer have a single hash; they have banks, one per supported algorithm, all extended in parallel by a single command. Microsoft's own documentation ^[7] describes the contract: when firmware extends PCR[0] with the IBV's CRTM measurement, the TPM extends both the SHA-1 bank and the SHA-256 bank, and on newer parts the SHA-384 bank as well. ※ The PC Client Platform TPM Profile mandates SHA-1 + SHA-256 minimum, not SHA-256-only. Backwards compatibility had a cost. Future-proofing against SHA-3 and post-quantum algorithms is now a matter of registering a new ID, not replacing silicon.

4.2 Four hierarchies, four primary seeds#

Where TPM 1.x had a single SRK, TPM 2.0 has four hierarchies -- Platform, Endorsement, Storage, Null -- each rooted in a per-hierarchy primary seed. Primary keys are derived deterministically: call TPM2_CreatePrimary with the same template against the same seed, and you get the same key back, byte-for-byte. The Apress textbook by Arthur, Challener, and Goldman ^[21] -- the de-facto developer reference for the spec -- describes this as the architectural fix to a real operational problem: the platform owner can clear the storage hierarchy without losing the device's endorsement identity.

flowchart TD
subgraph Platform["Platform Hierarchy
(firmware-only)"]
PSeed["Platform Primary Seed"]
PSRK["Platform SRK"]
PSeed --> PSRK
end
subgraph Endorsement["Endorsement Hierarchy
(privacy-sensitive)"]
ESeed["Endorsement Primary Seed"]
EK["EK"]
AK["AK
(restricted signing)"]
ESeed --> EK
ESeed --> AK
EK -. cert .-> AK
end
subgraph Storage["Storage Hierarchy
(owner-cleared)"]
SSeed["Storage Primary Seed"]
SRK["SRK"]
Sealed["Sealed VMK
(BitLocker)"]
Bound["Hello key
(per-user)"]
SSeed --> SRK
SRK --> Sealed
SRK --> Bound
end
subgraph Null["Null Hierarchy
(reset on every reboot)"]
NSeed["Null Primary Seed
(per-boot random)"]
end

4.3 Enhanced Authorization#

The most interesting change is how TPM 2.0 talks about access control. Every protected object has a policyDigest, an algorithm-agile hash of an arbitrarily complex set of conditions. To use the object, the caller starts a policy session (TPM2_StartAuthSession with SE_POLICY) and walks predicates -- TPM2_PolicyPCR, TPM2_PolicyAuthorize, TPM2_PolicySigned, TPM2_PolicyCommandCode, TPM2_PolicyAuthValue -- each extending the running session digest. At the end, the TPM checks that the session digest matches the object's policyDigest, and only then authorizes the operation. BitLocker, in its current Microsoft Learn description ^[14], uses this to seal the Volume Master Key to PCR[7] (Secure Boot policy) and PCR[11] (BitLocker control flags). Any tampering with Secure Boot configuration -- or any non-BitLocker boot path -- causes unseal to fail.

4.4 The unifying primitive: measure, extend, seal, quote#

The reason any of this matters for Windows is that the entire feature surface compresses down to four operations on the same set of registers.

• Measure. A piece of code computes the hash of the next piece of code (or configuration) about to run.
• Extend. That hash is folded into a PCR via PCR_new = H(PCR_old || hash). The operation is one-way: PCRs cannot be rewound.
• Seal. A symmetric key (or arbitrary blob) is encrypted under the TPM's Storage hierarchy with a policyDigest that names a specific set of PCR values. TPM2_Unseal releases the blob if and only if the live PCR state matches.
• Quote. The TPM signs a snapshot of selected PCRs with an Attestation Key. A remote verifier can check the signature against a known AKpub and an EK certificate chain.

The boot of a measured Windows machine is exactly this loop. The Core Root of Trust for Measurement -- a small piece of immutable firmware -- measures the next stage and extends PCR[0]. Each stage measures the next: PCR[2] for option ROMs, PCR[4] for the Windows Boot Manager, PCR[7] for the Secure Boot policy, PCR[11] for BitLocker volume control flags, and on through ELAM and the kernel. Microsoft's Trusted Boot description ^[22] walks the chain.

sequenceDiagram
participant FW as Firmware (CRTM)
participant BM as Bootmgr
participant Win as Windows kernel
participant TPM as TPM
FW->>TPM: PCR_Extend(PCR[0], H(firmware))
FW->>BM: Hand off
BM->>TPM: PCR_Extend(PCR[4], H(bootmgr))
BM->>TPM: PCR_Extend(PCR[7], H(SecureBoot policy))
BM->>Win: Hand off
Win->>TPM: PCR_Extend(PCR[11], H(BitLocker control))
Win->>TPM: TPM2_Unseal(VMK, policyDigest = PCR[7],PCR[11])
TPM-->>Win: VMK if PCRs match policy, else error

Now compress the Windows feature catalogue against those four operations.

• BitLocker ^[14] seals the VMK to a PCR policy.
• Measured Boot and Device Health Attestation ^[23] quote PCRs to a remote verifier.
• Credential Guard ^[24] seals the VBS-isolated NTLM/Kerberos secrets with a policy that includes the VBS measurement.
• Windows Hello for Business ^[25] creates a per-user RSA-2048 or P-256 key whose authorization policy requires the PIN gesture and is bounded by the TPM's anti-hammering counter.
• Virtual smart cards, DPAPI-NG, and TPM key attestation ^[26] for ADCS-issued certificates all sit on the same primitives.

One primitive -- measure, extend, seal, quote -- underwrites every Windows hardware-rooted security feature shipped since Vista. The TPM's value to Windows is not a list of cryptographic operations. It is a single, composable contract: "this key only releases when the boot looks like this."

By July 28, 2016, TPM 2.0 was a hidden contractual requirement under the entire Windows OEM channel. By June 24, 2021, Microsoft made the same chip the visible install gate for Windows 11. The architecture had won the building. Then attackers started taking it apart.

5. The threat model collapses inward (2019-2024)#

On March 13, 2019, a New Zealand security researcher named Denis Andzakovic posted a blog entry ^[13] that, in retrospect, started the modern era of TPM offense. He had spent $40 NZD on an iCE40 FPGA stick, soldered four wires to an HP business laptop, and lifted the BitLocker Volume Master Key off the LPC bus. With the disk in hand and the motherboard accessible, a thief could decrypt a TPM-only BitLocker volume in the time it took to boot it once. Andzakovic open-sourced the FPGA gateware ^[27] the same day. Andzakovic credits Hector Martin (@marcan) for prototyping LPC sniffing earlier; the 2019 write-up was the first end-to-end public demonstration with reproducible code.

The structural insight, which has not been backed away from, is that Windows does not enable TPM 2.0 parameter encryption on the BitLocker boot path. The VMK travels in plaintext at the LPC bus's 33 MHz clock across a few millimetres of PCB. Why doesn't Windows turn on parameter encryption for BitLocker? The boot-time pressure is real -- pre-OS code lives in a tight memory budget and parameter encryption requires HMAC-signed sessions. The pragmatic mitigation Microsoft documents is preboot authentication (PIN or startup key), which makes the bus-sniffed VMK insufficient on its own.

The attack would not stay a one-laptop curio. In late 2020, WithSecure's Henri Nurmi released an SPI variant ^[28] and a public BitLocker-key extraction tool. A year later, Thomas Dewaele and Julien Oberson at SCRT reproduced the LPC attack ^[29] on a Lenovo ThinkPad L440 with an ST33TPM12LPC chip and published a tutorial. By October 2024, SCRT had industrialized the attack ^[30] across "the three major enterprise-grade laptop manufacturers (i.e. Lenovo, HP, and Dell)" in "a few minutes."

The first reassurance the industry reached for was: ship the TPM inside the chipset. No bus, no sniff. Both Intel (Platform Trust Technology, fTPM-in-CSME ^[31]) and AMD (fTPM-in-PSP) had already done this for cost reasons. The second reassurance lasted eight months.

In November 2019, Daniel Moghimi, Berk Sunar, Thomas Eisenbarth, and Nadia Heninger -- soon to be USENIX Security 2020 -- released TPM-Fail ^[32]. Their finding: Intel PTT and a STMicro ST33 dTPM both leaked ECDSA private keys through ordinary timing side channels in their scalar multiplication. The numbers were brutal:

"A local adversary can recover the ECDSA key from Intel fTPM in 4-20 minutes depending on the access level. We even show that these attacks can be performed remotely on fast networks, by recovering the authentication key of a virtual private network (VPN) server in 5 hours." -- TPM-Fail, tpm.fail ^[32], 2019

NVD assigned CVE-2019-11090 ^[33] to Intel PTT and CVE-2019-16863 ^[34] to STMicroelectronics' ST33TPHF2ESPI. The latter entry is blunt: "STMicroelectronics ST33TPHF2ESPI TPM devices before 2019-09-12 allow attackers to extract the ECDSA private key via a side-channel timing attack because ECDSA scalar multiplication is mishandled, aka TPM-FAIL." Both chips were certified -- the STMicro chip held Common Criteria EAL4+, and the Intel chip held FIPS 140-2 ^[32] -- at the moment of disclosure. Certification did not catch the bug. The presentation is preserved in the USENIX Security 2020 proceedings ^[35].

The final beat came four years later. In April 2023, Hans Niklas Jacob, Christian Werling, Robert Buhren, and Jean-Pierre Seifert posted faulTPM (arXiv:2304.14717) ^[36], with reproducible code at github.com/PSPReverse/ftpm_attack ^[37]. The attack: voltage-glitch the AMD Platform Security Processor and walk out with the entire internal TPM state. The paper's own claim is the sentence that, more than any other, framed the modern TPM threat model.

"this vulnerability exposes the complete internal TPM state of the fTPM. It allows us to extract any cryptographic material stored or sealed by the fTPM regardless of authentication mechanisms such as Platform Configuration Register validation or passphrases with anti-hammering protection." -- Jacob, Werling, Buhren, Seifert, faulTPM (2023) ^[36]

Two to three hours of physical access. Anti-hammering bypassed because anti-hammering is enforced by the TPM, and once the TPM's internal state is on your bench you set the counter to zero. PCR-policy bypassed because the sealed blob's wrapping key is in the extracted state. The structural punch is that this makes BitLocker TPM+PIN on AMD fTPM with a low-entropy PIN less secure than a TPM-less passphrase (a corollary the faulTPM paper makes explicit ^[36]): the TPM concentrates all your trust into a chip whose internal state can be exfiltrated.

timeline
title Three generations of TPM attack
section Bus sniffing
2019 March : Andzakovic - $40 FPGA, BitLocker VMK off LPC bus
2020 December : WithSecure - SPI variant and key-extraction tool
2021 November : SCRT reproduces on Lenovo ThinkPad L440
2024 October : SCRT - few-minute attack on Lenovo, HP, Dell
section Side channel in fTPM
2019 November : TPM-Fail (Moghimi, Sunar, Eisenbarth, Heninger)
2019 November : CVE-2019-11090 (Intel PTT), CVE-2019-16863 (STMicro)
section Fault injection in fTPM
2023 April : faulTPM - full AMD fTPM state extracted in 2-3 h

If a $40 FPGA defeats discrete TPM, a network packet defeats Intel PTT, and a few hours of physical access defeats AMD fTPM completely -- where does the next generation of TPM live? Microsoft's answer was on the CPU die itself.

6. State of the art: five realizations of one specification#

All five chips in this section pass the same TCG conformance suite. They expose the same TPM2_* command surface to Windows. They fail to completely different attackers. The architecture is identical; the attack surface is everything.

6.1 Discrete TPM#

The classical chip. Infineon, STMicroelectronics, Nuvoton. Hangs off the motherboard's LPC, SPI, or I2C bus. Best certifications (Common Criteria EAL4+, FIPS 140-2/3). One bug class: bus sniffing in minutes for $40 against the BitLocker boot path that Windows leaves in plaintext.

6.2 Intel PTT#

TPM 2.0 inside the Converged Security and Management Engine -- historically on the Platform Controller Hub die, and increasingly on the SoC die in integrated-platform Intel processors since Tiger Lake. Either way, no physical bus to sniff. Defeated by TPM-Fail ^[32] timing side channel; firmware-patched, but inherits CSME's broader attack surface and CSME's update story (UEFI capsule via OEM, lifecycle entirely under the OEM's control).

6.3 AMD fTPM (PSP)#

TPM 2.0 inside the AMD Platform Security Processor ^[38] (an ARM TrustZone Cortex-A5 core integrated into every modern Ryzen SoC). Ships in essentially all Ryzen-class client SoCs since 2017. No physical bus to sniff. Defeated end-to-end by the faulTPM ^[36] voltage-glitch attack against the PSP. The structural problem is shared TEE: the same coprocessor is responsible for memory encryption setup, secure-boot enforcement, and TPM service, and a single fault-injection path drops all of those.

6.4 Microsoft Pluton#

A Microsoft IP block on the CPU SoC die, with Microsoft-authored Rust firmware ^[39] delivered through Windows Update. According to Microsoft's hardware list, Pluton "is currently available on devices with the following chipsets running on Windows 11: AMD: Ryzen 6000, 7000, 8000, 9000 and Ryzen AI Series ... Intel: Core Series Processors -- Ultra 200V Series, Ultra Series 3 and Series 3 ... Qualcomm: Snapdragon 8cx Gen 3 and Snapdragon X Series." The same page notes that "Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation given the importance of memory safety."

The thesis is laid out in Microsoft's November 17, 2020 announcement post ^[40], which links explicitly to Andzakovic. The architectural framing is unusually direct.

"The Pluton design removes the potential for that communication channel to be attacked by building security directly into the CPU." -- Microsoft Security Blog, November 17, 2020 ^[40]

Three things change at once. The bus is gone -- Pluton is on-die, so dTPM bus-sniffing has no surface to attack. The TEE host is dedicated -- Pluton is not the same coprocessor that runs SEV memory encryption or ME runtime services. And the firmware ships through Windows Update -- so when a Pluton firmware vulnerability is found (and one will be found), the patch reaches the deployed fleet through Windows Update rather than through OEM UEFI capsule rollouts. The Pluton-as-TPM page makes the trade-off explicit: "Microsoft Pluton can be used as a TPM, or with a TPM. Although Pluton builds security directly into the CPU, device manufacturers might choose to use discrete TPM as the default TPM." ^[41] Several enterprise security teams have publicly cited the Pluton update model as a reason to keep dTPM as their default for high-assurance fleets even where Pluton silicon is available.

6.5 vTPM#

A software TPM emulation, typically inside a hypervisor. Azure Trusted Launch ^[42] is Microsoft's flagship implementation: "Trusted Launch is the default state for newly created Azure Gen2 VM and scale sets." The vTPM lives in a host-protected memory region and inherits the trust of the host. For cloud workloads where the threat model already includes "the hypervisor host is honest," this is the right shape; for adversarial physical access, it is not.

6.6 Head-to-head#

flowchart LR
subgraph TPMs["Five realizations"]
dTPM["Discrete TPM
(LPC/SPI/I2C)"]
PTT["Intel PTT
(CSME)"]
AMD["AMD fTPM
(PSP)"]
Pluton["Microsoft Pluton
(on-die, Rust, WU)"]
vTPM["vTPM
(Hyper-V / Azure)"]
end
subgraph Surface["TCG2 command surface"]
TCG["TPM2_* commands"]
end
dTPM --> TCG
PTT --> TCG
AMD --> TCG
Pluton --> TCG
vTPM --> TCG
TCG --> BL["BitLocker VMK seal"]
TCG --> MB["Measured Boot / DHA"]
TCG --> CG["Credential Guard"]
TCG --> WH["Windows Hello"]
TCG --> VSC["Virtual smart cards"]
TCG --> DPAPI["DPAPI-NG"]
TCG --> KA["TPM key attestation (ADCS)"]

The deep claim of the Pluton design is not that it is a better cryptoprocessor. It is that the previous decade's lesson -- TEE memory-safety bugs are systemic, certification did not catch them, and OEM UEFI capsule patching is too slow -- argues for moving the firmware signer to Microsoft and the firmware language to Rust. That is a political choice, not just a technical one. The October 2019 Secured-core PCs initiative ^[43] was the first public step; Pluton is its descendant.

If you can sniff a dTPM, time-attack an Intel PTT, glitch an AMD fTPM, and trust Microsoft to sign your Pluton firmware -- which threat are you actually defending against?

7. Theoretical limits: what a passive cryptoprocessor cannot do#

A famous joke in the trusted-computing community: the TPM cannot make a compromised OS uncompromised. It can only make sure that nothing else helped.

Three impossibility-style results follow from the architecture itself, regardless of which of the five realizations you pick.

7.1 The TPM is a Root of Trust for Storage and Reporting, not Execution#

The Core Root of Trust for Measurement -- the immutable code that bootstraps the measurement chain -- lives in firmware, not in the TPM. The TPM cannot detect that the wrong code measured itself; it can only refuse to release sealed material when the PCRs do not match the stored policy. If the CRTM is compromised (or a downstream measurement is forged before extension), the TPM has no way to know.

Stronger guarantees require an active root of trust: a Dynamic Root of Trust for Measurement, where the CPU enters a known good state late in the boot and re-measures from there. Intel TXT, AMD SVM-SKINIT, and Microsoft's System Guard Secure Launch ^[44] on Secured-core PCs all implement this. The TPM is a participant in DRTM; on its own, it is not sufficient.

7.2 TPM-only BitLocker has a structural lower bound#

The VMK must enter RAM during Trusted Boot before the user authenticates. This is not a bug; it is the threat-model definition of "TPM-only." Therefore any attacker who intercepts the VMK at the moment of release defeats TPM-only BitLocker, regardless of TPM strength. This is what every dTPM bus-sniffing attack actually exploits -- not a weakness of the TPM, but the structural condition that the key must traverse the boot path.

Microsoft's countermeasures documentation ^[45] names the mitigation in plain terms: preboot authentication. Adding TPM+PIN raises the bound to "guess the PIN against intact anti-hammering" -- but only as long as the TPM's anti-hammering counter cannot be exfiltrated. faulTPM violates that condition for AMD fTPM. On a Pluton or hardened dTPM, anti-hammering still holds, and a sufficiently random PIN closes the bound.

The complexity of guessing an $n$-digit PIN against intact anti-hammering ^[45] with a per-failure delay $\Delta t$ is approximately $\frac{1}{2} \cdot 10^n \cdot \Delta t$ in the average case. For $n = 8$ and $\Delta t \geq 1\text{s}$ this is roughly $5 \times 10^7$ seconds, or about 1.6 years. For $n = 4$, it is hours.

7.3 Once a key is unsealed, it lives in the OS's address space#

A runtime-compromised OS reads any key the TPM has unsealed for it. The TPM defends against the offline attacker (disk theft, post-shutdown tamper) and the pre-OS attacker (boot-time integrity violation that fails the unseal). It does not defend against a privileged runtime attacker. This is a general impossibility, not a TPM weakness; no passive cryptoprocessor can decide whether the OS asking to unseal a key is itself trustworthy at the moment it asks.

This is why VBS, Credential Guard, and DRTM exist as separate disciplines: they answer "what protects the unsealed key once it is in RAM?" by isolating the key inside a VTL1 enclave or by re-measuring the OS after launch. The TPM is a participant; it is not the answer.

The TPM defends against the offline attacker and the pre-OS attacker. It does not defend against a runtime-compromised OS. This is by design, and is the most a passive cryptoprocessor can do. Stronger guarantees require an active component (DRTM, VBS, hypervisor isolation) -- and none of those are the TPM.

What would an ideal TPM look like? On-die (no bus), in an isolated TEE shared with nothing else, with the host-firmware-update path replaced by an OS-channel update path, with high-assurance certification depth, with an authenticated wire protocol always on, and with native support for post-quantum primitives. No shipping TPM today satisfies all six properties. Pluton plus future PQC firmware updates is the closest existing trajectory; it is on-die, isolated, OS-channel-updated, and Rust-implemented, but it does not yet expose PQC primitives and its certification depth is still evolving.

If the TPM cannot defeat a runtime-compromised OS by design, and the best fTPM can be extracted in three hours, where is the security frontier actually moving?

8. Open problems: PQC, supply chain, and trust centralization#

On August 13, 2024, NIST finalized FIPS 203 (ML-KEM) ^[47], FIPS 204 (ML-DSA) ^[48], and FIPS 205 (SLH-DSA) ^[49] -- the first federal post-quantum cryptography standards. ML-DSA-87's public keys are 2,592 bytes. A typical TPM has 6 to 32 KiB of NV memory total. The math gets uncomfortable quickly.

8.1 Post-quantum migration#

The NIST Post-Quantum Cryptography project page ^[50] describes the timeline: "In August 2024, NIST released its principal PQC standards ... Under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier." That is the deadline driving every TPM roadmap, and the August 14, 2024 Federal Register notice ^[51] made it formal U.S. policy.

Three concrete obstacles. First, the TCG algorithm registry has not yet normatively added ML-KEM, ML-DSA, or SLH-DSA; a TCG PQC working group exists, but its output is in flight. The Microsoft TPM 2.0 reference code ^[52] tracks TCG: the V1.83 release notes describe it as "the first revision in sync with Trusted Computing Group 1.83," and that revision still does not expose PQC algorithm IDs. The Fraunhofer SIT Post-Quantum Cryptography for TPM ^[53] programme has prototyped PQC primitives inside reference TPM stacks, but those changes are research artefacts, not normative TCG output.

Second, the constrained NV-memory budget on a typical TPM cannot hold many simultaneous PQC keys at the larger parameter sets. Quick arithmetic against ML-DSA-87 (FIPS 204): 2,592-byte public key plus 4,896-byte private key plus protocol overhead pushes a single persistent key blob past 7.5 KiB. A 16-KiB-NV TPM can hold at most two persistent ML-DSA-87 slots before exhausting NV. The larger SLH-DSA-256s signatures (29,792 bytes per FIPS 205 Table 2) ^[49] routinely exceed the typical 1-4 KiB response-buffer cap (TPM_PT_MAX_RESPONSE_SIZE in the PC Client Platform TPM Profile ^[54]); the related TPM_PT_NV_BUFFER_MAX (the maximum NV read/write chunk) is in the same order of magnitude and complicates persistent-storage cases as well. The chip cannot return such a signature in a single command without fragmentation extensions. PQC support on commodity TPMs is not just a software upgrade; it is an NV-budget renegotiation.

Third, hybrid signing schemes (composite RSA + ML-DSA, or ECDSA + ML-DSA) are well-defined for transitional certificates. The IETF LAMPS WG draft on composite ML-DSA signatures ^[55] specifies "combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448" for X.509 PKIX. The TLS hybrid key-exchange draft ^[56] does the same for TLS 1.3 handshakes. Neither defines a hybrid TPM2_Sign profile, and no shipping Windows TPM exposes one.

Microsoft's Quantum Safe Security blog (August 2025) ^[57] describes the broader effort -- "Our PQC effort began in 2014 when we published research on post-quantum algorithms ... We participated in four submissions to the original 2017 NIST PQC call and one submission to the current call" -- but is silent on Pluton-firmware PQC support specifically.

The architectural punchline: Pluton's Windows-Update firmware delivery channel is the only realization that can plausibly add a PQC primitive across the deployed fleet without a hardware refresh. Every other realization will need new silicon to ship native PQC.

8.2 The supply-chain trust of EK certificates#

The Microsoft TPM key attestation documentation ^[26] describes the trust-chain assumption plainly: the requestor proves "to a CA that the RSA key in the certificate request is protected by either 'a' or 'the' TPM that the CA trusts." That trust is anchored on the EK certificate the chip's vendor issued at manufacture. A vendor-CA compromise therefore equals collapse of TPM-bound device identity for an entire OEM cohort.

The 2017 ROCA incident is the canonical event for why this matters. In February 2017, Matúš Nemec, Marek Sýs, Petr Švenda, Dušan Klinec, and Vashek Matyáš at Masaryk University ^[58] disclosed to Infineon a flaw in its RSA key-generation library that drastically reduced the entropy of generated keys and made factoring tractable. The NVD entry for CVE-2017-15361 ^[59] is precise about scope: "The Infineon RSA library 1.02.013 in Infineon Trusted Platform Module (TPM) firmware ... mishandles RSA key generation, which makes it easier for attackers to defeat various cryptographic protection mechanisms via targeted attacks, aka ROCA. Examples of affected technologies include BitLocker with TPM 1.2, YubiKey 4 (before 4.3.5) PGP key generation, and the Cached User Data encryption feature in Chrome OS." The Wikipedia summary ^[60] reports the team's own estimate that the bug "affected around one-quarter of all current TPM devices globally."

The Estonian e-ID program -- about 750,000 cards issued since 2014 ^[61], all using the affected Infineon chip -- had to be re-enrolled. Microsoft published advisory ADV170012 ^[62] on the same coordinated disclosure date. There is still no scalable revocation mechanism for individual EK certificates: vendor-level revocation breaks every device whose EKpub was issued by that vendor's CA, and ADCS-template OEM-pinning limits scope but does not solve in-scope CA compromise. Pluton centralizes one part of trust (Microsoft as firmware signer); EK certificate issuance for the silicon is unchanged, and supply-chain integrity remains a per-vendor question.

8.3 Attestation freshness in zero-trust networks#

A TPM Quote proves "this device booted clean," not "this device is currently clean." Microsoft Intune's default device-compliance check-in is on the order of hours; Microsoft Entra's Continuous Access Evaluation documentation ^[63] specifies the upper-bound numerics: "By default, access tokens are valid for one hour ... The goal for critical event evaluation is for response to be near real time, but latency of up to 15 minutes might be observed because of event propagation time."

A 15-minute revocation window for critical events is good. But it propagates signed policy decisions, not fresh TPM measurements. A device that was clean at boot, was compromised five minutes ago, and just made a request now will pass CAE if its existing access token is valid. Closing that window requires either much shorter token lifetimes, runtime attestation (TCG DICE, Project Cerberus), or a hypervisor-mediated re-measurement -- and none of them are the TPM.

DPAPI-NG, the CNG-layer successor to classic DPAPI that Windows uses to encrypt secrets to a set of authorization principals, is a useful test case. The DPAPI-NG documentation ^[64] describes the API as "secure[ly] shar[ing] secrets (keys, passwords, key material) and messages by protecting them to a set of principals." The protection-descriptor grammar ^[65] permits five descriptor keywords -- SID, SDDL, LOCAL, WEBCREDENTIALS, CERTIFICATE -- across three logical authorization classes (AD-forest groups, web credentials, certificate-store entries). Notably absent: any literal TPM=true clause. DPAPI-NG can be backed by a TPM-bound CNG key, but the authorization is expressed in principal terms, not in TPM terms. The TPM is a key-residence property, not a policy primitive at this layer -- the right architectural choice, but it means TPM-bound DPAPI-NG inherits the freshness limits of whatever principal authorization decides who is currently authorized.

8.4 The Pluton political question#

Centralizing firmware on a single Microsoft signing key is a deliberate trade-off, not an oversight. The benefit is the patch path: a Pluton firmware vulnerability becomes a Windows Update release rather than a multi-quarter OEM capsule rollout. The cost is that the chip's trust anchor is now a Microsoft signing key, in a way that even the most conservative dTPM is not. The market response in 2022 was openly mixed.

In March 2022, The Register obtained vendor statements ^[66] from Dell, Lenovo, and HP. Dell's reply was unusually direct: "Pluton does not align with Dell's approach to hardware security and our most secure commercial PC requirements." Lenovo deployed the chip but disabled it: "[ThinkPads] will not support Microsoft Pluton at launch ... But ThinkPads introduced in January with AMD Ryzen 6000 processors will include Pluton as it's present in those AMD chips, though the feature will be disabled by default. AMD has provided an option for users to turn the feature on and off." PCWorld followed up ^[67] with Lenovo's articulated reasoning: "Pluton is disabled by default on 2022 Lenovo ThinkPad laptops using AMD Ryzen PRO 6000 Series processors because that's what Lenovo customers have asked for, the choice to enable or not."

Matthew Garrett -- who later contributed the upstream Linux kernel support for the Pluton TPM CRB interface in Linux 6.3 (merged February 2023, released April 2023) ^[68] -- published the closest thing to a public engineering analysis of Pluton's controllability. His April 2022 reverse-engineering write-up ^[69] of the ASUS ROG Zephyrus G14 BIOS documents two firmware-level disable mechanisms on AMD Ryzen 6000 platforms: an x86-firmware "do not communicate" toggle, and a PSP directory entry 0xB BIT36 soft-fuse that "will NOT put HSP hardware in disable state, to disable HSP hardware, you need setup PSP directory entry 0xB, BIT36 to 1." Garrett's caveat is honest: "My interpretation of this is that it doesn't directly influence Pluton, but disables all mechanisms that would allow the OS to communicate with it." It is not a multi-signer proposal. There is no public peer-reviewed proposal for multi-signer or open-source Pluton firmware.

The unresolved engineering question: whether a multi-signer model is feasible without losing the timely-update property that motivated Pluton in the first place. The answer is genuinely unknown. The political question -- whether one signing key on the world's PC fleet is the right cost for the Windows-Update patch latency it enables -- is no longer a technical argument. It is a procurement-policy and procurement-jurisdiction argument, and high-assurance fleets are deciding both ways.

The TPM was supposed to be the part of the system you didn't have to trust anyone for. Twenty-five years later, the trust question is back -- and the answer is now political.

9. A Windows practitioner's TPM reference#

What does this mean for the engineer running Get-Tpm on Monday morning? Three concrete things: discovery, choosing a form factor, and avoiding the pitfalls.

9.1 Discovery#

Three commands establish ground truth on any Windows 11 device. Get-Tpm returns presence, ownership, and command-availability state. Get-TpmEndorsementKeyInfo returns the EK public and certificate. tpm.msc opens the Microsoft Management Console snap-in. The TCG event log lives at C:\Windows\Logs\MeasuredBoot\*.log and contains the per-PCR measurement history for every boot. Microsoft's BitLocker page ^[14] documents the protector model that pairs with the TPM state.

// Demonstrates the logic of:
//   Get-Tpm
//   (Get-BitLockerVolume -MountPoint 'C:').KeyProtector
//
// Mirrors the PowerShell decision tree without requiring a real TPM.

const tpm = {
TpmPresent: true,
TpmReady: true,
ManufacturerVersion: '7.2.0.1',
PhysicalPresenceVersionInfo: '1.3',
};

// Sample KeyProtector list as PowerShell would return it.
const protectors = [
{ KeyProtectorType: 'Tpm' },
{ KeyProtectorType: 'RecoveryPassword' },
// Uncomment to model TPM+PIN:
// { KeyProtectorType: 'TpmPin' },
];

function classify(tpm, protectors) {
if (!tpm.TpmPresent) return 'no-tpm';
if (!tpm.TpmReady) return 'tpm-not-ready';

const types = protectors.map(p => p.KeyProtectorType);
const hasPin = types.includes('TpmPin') || types.includes('TpmPinStartupKey');
const hasStartupKey = types.includes('TpmStartupKey');
const hasRecovery = types.includes('RecoveryPassword');

if (hasPin) return 'tpm-plus-pin';
if (hasStartupKey) return 'tpm-plus-startup-key';
if (types.includes('Tpm')) return 'tpm-only';
return 'no-tpm-protector';
}

const verdict = classify(tpm, protectors);
console.log('TPM present:', tpm.TpmPresent);
console.log('TPM ready  :', tpm.TpmReady);
console.log('Configuration:', verdict);
if (verdict === 'tpm-only') {
console.log('WARN: TPM-only is vulnerable to bus-sniffing on dTPM.');
console.log('Mitigation: enable TPM+PIN with PIN length >= 8.');
}
console.log('Recovery key escrowed:', protectors.some(p => p.KeyProtectorType === 'RecoveryPassword'));

9.2 Choosing a TPM form when the OEM gives you a choice#

A short decision tree, distilled from the SOTA analysis above:

• Opportunistic theft, low-skill attacker. Default TPM-only is acceptable but not ideal. TPM+PIN with at least 8 random digits closes the bus-sniffing window on dTPM and the low-PIN-entropy window on AMD fTPM.
• Determined targeted adversary. TPM+PIN is necessary but not sufficient. Add FIDO2 or smart-card preboot authentication where supported, and prefer Pluton or hardened dTPM over commodity AMD fTPM for the device class.
• Compliance-driven. Discrete TPM with EAL4+ / FIPS 140-2 certification is still the easiest procurement story. Verify the OEM has not enabled Pluton-as-TPM if the auditor's checklist requires a discrete chip.
• Cloud workload. Azure Trusted Launch with vTPM ^[42] is the default for Gen2 VMs and underwrites Confidential VM offerings.
• Surface Copilot+, AMD Ryzen 6000+, Intel Core Ultra 200V, Snapdragon X. Pluton-as-TPM ^[39] is the OEM default in many SKUs; verify the Pluton firmware is current via Windows Update.

9.3 Five common pitfalls#

The other four pitfalls in brief: firmware updates change PCR[0] and PCR[7], so suspend BitLocker before applying them; dual-boot Linux extends PCRs differently than Windows, so PCR-only sealing breaks under it -- escape with TPM+PIN; Windows does not enable parameter encryption on the BitLocker boot path, so the actual mitigation against dTPM bus sniffing is preboot authentication, not "TPM hardening"; and Windows Hello silently falls back to no-TPM credential storage if the TPM is unhealthy, so periodically check Get-Tpm on enrolled devices. ※ "Anti-hammering" is the persistent rate-limit counter the TPM enforces against authValue and policy-PIN failures. It survives reboots and only resets after a long lockout period.

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

The TPM does exactly what it was designed to do, no more. Which is exactly enough -- if you understand what "exactly" means.

10. FAQ and closing#

A handful of questions get asked again and again about the TPM. The answers do not always match the marketing.

Return to June 24, 2021. The PR backlash about a Trusted Platform Module made the chip visible for the first time to a consumer audience that had owned one for a decade. The technical rationale Microsoft gave was four words long; the actual rationale is the rest of this article.

A passive cryptoprocessor designed in 1999 quietly became the load-bearing pillar of half of Windows security. Twenty-five years of engineering refined a single primitive -- measure, extend, seal, quote -- into something one chip could underwrite. Twenty-five years of attacks, from a $40 FPGA on an LPC bus to a voltage glitch against the AMD PSP, argued empirically about how passive that chip can be allowed to be. The current state of the art is on the CPU die, in Rust, signed by Microsoft, patched through Windows Update -- and post-quantum migration is the next argument.

The TPM is not a checkbox. It is the point at which Windows decided integrity must be measurable. It is not a panacea -- the runtime-compromised OS still wins once the key is unsealed -- but it is a primitive, with a clean boundary. Now you know what it can prove, and what it cannot. The chip is the cheapest part of the system. The cost was twenty-five years of getting it right.