Parag Mali - tag: hardware-security

Apple Secure Enclave vs Microsoft Pluton: Two Roads to Hardware Root of Trust

noreply@paragmali.com (Parag Mali) — Thu, 14 May 2026 00:00:00 GMT

**Apple Secure Enclave and Microsoft Pluton solve the same problem -- keeping your keys, biometrics, and disk-encryption secrets safe even when the operating system is compromised -- by way of two different silicon strategies.** Apple gives the SEP its own physical CPU core, its own L4-derived microkernel (sepOS), and a mailbox API that no app can bypass. Microsoft drops Pluton onto the SoC die as a TPM 2.0-compatible subsystem patched through Windows Update. The differences shape everything downstream: who can patch the firmware, what attacks remain in scope, and which APIs developers actually call. This article walks through the architectures, the API surfaces, the published attacks (checkm8, LPC sniffing, faulTPM), and the cross-platform standards (FIDO2/WebAuthn) that paper over the divide.

1. The bus that taught everyone a lesson

In 2021, a researcher at Pulse Security wired a forty-dollar FPGA to the LPC bus of a Microsoft Surface Pro 3 and a Lenovo laptop, captured a handful of bytes as the machines powered on, and pulled the BitLocker Volume Master Key out of the air. Then they decrypted the drives. They wrote the whole thing up, with photos of the soldering and an open-source sniffer named lpc_sniffer_tpm (Pulse Security: Sniff, there leaks my BitLocker key [@pulse-tpm-sniff]).

The hardware was working exactly as designed.

That is what makes the story interesting. The Trusted Platform Module released the disk-encryption key the moment the boot configuration matched its sealed policy. It then handed the key, in cleartext, to the CPU over a physical wire on the motherboard. Anyone who could touch that wire could read the key. The chip, the spec, the OS -- all of them did precisely what the standard required. The threat model just never accounted for somebody putting probes on a laptop.

This is the problem hardware-rooted security has spent twenty years trying to dig itself out of. If you trust software, malware wins. If you trust software-plus-discrete-TPM, the bus wins. If you trust software-plus-firmware-TPM, the host operating system's privileged-mode bugs win. Every layer you add closes one class of attack and opens another.

Key idea: Hardware roots of trust exist because no purely software-defined boundary can survive an attacker who runs code at the same privilege level you do. The only way out is to put the secrets somewhere your main CPU literally cannot read.

Apple and Microsoft both reached the same conclusion roughly a decade apart, and built almost opposite answers. Apple shipped the Secure Enclave Processor (SEP) with the A7 chip in the iPhone 5s in September 2013 [@apple-sep-chapter] -- a dedicated ARM core inside the application SoC, running its own microkernel, talking to the rest of the phone through a hardware mailbox. Microsoft announced Pluton in November 2020 [@ms-pluton-announce], but had been shipping Pluton-class silicon since the original Xbox One in 2013 [@ms-pluton-learn]; the Windows version is an on-die security subsystem that pretends to be a TPM 2.0 chip and accepts firmware updates over Windows Update.

Both companies looked at the same threat -- a curious adversary with a screwdriver, an OS-level rootkit, or a $40 logic analyzer -- and decided the answer was to move the keys off the bus. They just disagreed about where to put them.

A piece of silicon that the rest of a system anchors its security claims to. Keys generated inside the RoT never leave; measurements taken by the RoT are signed by it; software running outside the RoT cannot rewrite the RoT's behavior. The "root" is the part the rest of the trust chain reduces down to. A cryptoprocessor specified by the Trusted Computing Group. TPM 2.0 -- the current version, published in 2014 and revised since [@tcg-tpm2] -- defines Platform Configuration Registers (PCRs), an Endorsement Key burned at manufacture, key creation and sealing primitives, and the `TPM2_Quote` command for remote attestation. A TPM can be discrete (its own chip), firmware (running inside another security subsystem), or virtual.

This article is the comparison nobody quite writes, partly because both vendors prefer to talk about themselves and partly because the technologies look superficially similar. They are not. The architectures differ. The threat models differ. The patch channels differ. The developer APIs differ enough that the same security goal -- "store this key so nothing but the user's biometric can use it" -- produces wildly different code on each side. By the end of this you should know which one is in your device, why it is there, what it actually defends against, and where the academic literature has already poked holes.

flowchart LR subgraph Discrete["Discrete TPM (sniffable bus)"] CPU1[CPU] -- LPC/SPI --> TPM[Discrete TPM chip] end subgraph SEP["Apple SEP (separate core)"] AP[Application Processor] -- mailbox --> SEPCore[SEP core + sepOS] end subgraph Pluton["Microsoft Pluton (on-die subsystem)"] CPU2[CPU] -- on-die fabric --> PlutonSub[Pluton subsystem] end

The journey from "trust the OS" to "trust the silicon that even the OS cannot read" is the story of the last fifteen years of platform security. The Surface Pro 3 attack is what happens when you do half of it. Apple's and Microsoft's answers are what it looks like when you do all of it -- in two opposite ways.

2. Apple's answer: a small computer inside your phone

The Apple Secure Enclave Processor is a separate physical CPU core, on the same die as the application processor, with its own memory, its own boot ROM, its own operating system, and its own random number generator. Apple's own framing in the Platform Security Guide [@apple-sep-chapter] is that the SEP "provides the foundation for the secure generation and storage of the keys necessary for encrypting data at rest." That is what it does. How it does it is what is interesting.

2.1 What sits on the die

Inside an A-series or M-series SoC, the SEP is a distinct cluster. According to Apple's published architecture, it includes (Apple Platform Security: Secure Enclave [@apple-sep-chapter]):

A dedicated processor core (not a SMT thread, not a shared core) running at a lower clock than the application cores.
A Memory Protection Engine (MPE) that encrypts every cache line going to or from SEP-owned DRAM.
A True Random Number Generator (TRNG) seeded by silicon noise.
A hardware AES engine and a Public Key Accelerator (PKA) for ECC and RSA.
A boot ROM masked in silicon at fabrication time.
From A13 onward, a relationship with an external Secure Storage Component (SSC) [@apple-ssc] that provides monotonic counters and replay-protected non-volatile storage.

The lower clock speed is not an accident. Apple explicitly notes that the SEP "is designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks" (Apple Platform Security [@apple-sep-chapter]). Side-channel-resistance starts at the timing budget.

Apple's dedicated security coprocessor, introduced in the A7 SoC in September 2013 [@apple-a-series]. Each Apple-designed SoC since contains one SEP. It runs `sepOS`, an Apple customization of the L4 microkernel, and exposes its services only via a tightly defined mailbox interface from the application processor. The operating system the SEP runs. Apple describes it as "an Apple-customized version of the L4 microkernel" (Apple Platform Security: Secure Enclave [@apple-sep-chapter]). It is independent of iOS, iPadOS, or macOS, ships in the same firmware bundle as those operating systems, and is signed by Apple. The microkernel design constrains the trusted computing base and forces cross-service communication through IPC.

2.2 The boot chain, in order

When you press the power button, two CPUs come up at once. The application processor begins executing its boot ROM, and the SEP begins executing its own. They are independent boot processes that meet later, after both sides have verified their own firmware.

sequenceDiagram participant AP as Application Processor participant SEP as Secure Enclave Processor participant ROM as SEP Boot ROM (mask) participant Flash as System Storage Note over AP,SEP: Reset AP->>AP: Execute AP Boot ROM SEP->>ROM: Execute SEP Boot ROM ROM->>Flash: Load sepOS image ROM->>ROM: Verify signature against Apple root key alt Signature valid ROM->>SEP: Launch sepOS SEP->>SEP: Initialize MPE, derive UID-tangled keys else Signature invalid ROM->>SEP: Halt end AP-->>SEP: Mailbox handshake SEP-->>AP: Available services advertised

The SEP boot ROM is mask ROM. That phrase carries weight. It means the bits were etched into the silicon at fabrication and cannot be rewritten. Apple cannot patch the SEP boot ROM with a software update, even if Apple wants to. This is a feature -- nobody else can patch it either -- and a liability. We will return to it when we discuss checkm8.

After the SEP boot ROM verifies and launches sepOS, the SEP holds two values fused into the silicon at manufacture: a Unique ID (UID) and a Group ID (GID). The UID is per-device. The GID is per-product-family. Both are kept inside the SEP and never appear outside it. Keys derived from the UID are tangled to the specific piece of silicon; you cannot lift the wrapped key, move it to another phone, and unwrap it. The chip is physically the wrap-and-unwrap oracle.The UID is also why factory-reset really does erase your data. The data-protection key hierarchy roots at a key derived from the UID and a per-file random; rotate the right intermediate and every wrapped file becomes unrecoverable noise.

2.3 The Memory Protection Engine

The SEP's RAM is, physically, in the same DRAM module as everything else. A naive design would let the application processor read it. The MPE prevents that. Every cache line bound for SEP memory is encrypted with AES in XEX mode (a tweakable mode similar to disk-encryption XTS) and authenticated with a CMAC tag. The tweak includes the physical address, so an attacker cannot relocate ciphertext to a different location and have it still verify (Apple Platform Security: Secure Enclave [@apple-sep-chapter]).

Starting with the A11 SoC, the MPE added an anti-replay value per protected block, with the anti-replay tree rooted in dedicated on-die SRAM. The threat that introduces is: an attacker who can capture the encrypted DRAM contents at time T1 and overwrite the DRAM with that snapshot at time T2 -- a "store, rewind, replay" attack. Tree-rooted anti-replay defeats it because the root in SRAM does not match the old leaves the attacker re-injected.

The tweakable XEX construction has the property that two cache lines containing the same plaintext at different addresses produce different ciphertext, which prevents the pattern-leakage you get from ECB-style encryption. CMAC adds a 128-bit integrity tag.

From the A14 and M1 generation onward, the MPE handles two ephemeral keys: one for SEP-private data and one for data shared with the Secure Neural Engine (used during Face ID matching). The keys are regenerated at every reset, so even capturing the DRAM ciphertext across a reboot leaks nothing.

2.4 The Secure Storage Component

Anti-hammering -- the property that a passcode-guessing attacker is rate-limited and eventually locked out -- requires reliable monotonic state that the attacker cannot rewind. Mask ROM and on-die SRAM are not enough on their own because power loss erases SRAM. From the A13 SoC onward, Apple solves this by adding a separate chip on the logic board: the Secure Storage Component (SSC) [@apple-ssc].

The SSC is small, tamper-resistant, and only the SEP can talk to it. It stores monotonic counters and entropy values that the SEP uses to bind authenticated storage to wall-clock state. If you steal the phone, dump the encrypted blobs, "rewind" by overwriting the flash with an earlier copy, and try to brute-force the passcode again, the SSC's counters no longer match. Anti-hammering survives the rewind.

Note: A monotonic counter sounds easy until you remember that an attacker with the physical device can pull power at any instant, including in the middle of an increment. The SSC has to atomically commit counter updates while also defending against deliberate transient brown-outs. This is the kind of thing that takes a dedicated tamper-resistant chip rather than a software loop.

2.5 The mailbox API

Userspace apps never touch the SEP directly. The application processor reaches it through a hardware mailbox -- a small ring of registers and shared memory that defines the entire API surface from AP to SEP. The kernel exposes higher-level services on top: Touch ID and Face ID matching, Keychain entries flagged with kSecAttrTokenIDSecureEnclave [@apple-keychain], Data Protection class keys, App Attest signing, and so on.

The constraint is severe. The SEP exposes a fixed set of operations. No app, and no part of the OS, can ask the SEP to do something the firmware did not already implement. Compromise of the AP-side kernel does not produce an arbitrary-code-execution primitive on the SEP. It produces, at most, the ability to call SEP services from a hostile place -- and those services still require user authentication (FaceID, TouchID, passcode) before they release sensitive operations.This is the dual of the TPM 2.0 design philosophy. A TPM defines a wide command set in its spec; the firmware implements that command set; software calls those commands. The SEP defines a narrow service set bespoke to Apple's products; everything else is rejected.

Note: The SEP is not a generic crypto coprocessor. It is a small fixed-purpose computer that knows how to do exactly the operations Apple's platforms need, and nothing else. Its security comes from being deliberately less programmable than a TPM.

If you had to summarize what Apple built in one sentence: they put a second computer in the phone, gave it the keys, gave it a lock on its own door, and left a slot for messages to slide through. That is the design.

3. Microsoft's answer: kill the bus, keep the standard

Apple had the luxury of designing the application processor and the security processor together. Microsoft does not. Microsoft sells software that runs on AMD, Intel, and Qualcomm silicon, on chassis from Dell, HP, Lenovo, Acer, Asus, Microsoft itself, and a long tail of others. The discrete TPM 2.0 standard fixes a contract between Windows and a piece of trusted hardware that any vendor can implement. Pluton's job was to keep that contract while removing the parts that did not survive contact with reality.

The first part of reality Pluton kills is the bus.

3.1 The Xbox lineage

Microsoft did not invent Pluton for Windows. The architecture started in the original Xbox One, shipping in 2013 [@ms-pluton-learn], where it served as the security subsystem that prevented modchipping and verified the boot chain. The same architecture was extended to the Azure Sphere MT3620 microcontroller in 2018 [@ms-pluton-learn], aimed at IoT devices. The Windows variant -- the one most people mean when they say "Pluton" -- was announced in November 2020 [@ms-pluton-announce].

The first shipping Windows silicon containing Pluton was the AMD Ryzen 6000 series ("Rembrandt") in January 2022. Qualcomm Snapdragon 8cx Gen 3 and the Snapdragon X family followed in 2023-2024. Intel's first Pluton-bearing CPU was Core Ultra Series 2 ("Lunar Lake") in late 2024. As of the current Microsoft documentation, the supported matrix is "AMD Ryzen 6000/7000/8000/9000 and Ryzen AI Series; Intel Core Ultra 200V Series, Ultra Series 3; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series" (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]).This is a deployment claim. Pluton's presence on these CPUs is documented by the silicon vendors and Microsoft. Whether Pluton is enabled by default on a given laptop varies by OEM. Practitioners verifying real fleets need to confirm via Windows' Device Manager and tpm.msc whether the active TPM advertises the Microsoft Pluton manufacturer ID rather than a discrete vendor.

3.2 What sits on the die

Pluton is a security subsystem placed inside the SoC, not on a separate chip on the motherboard. That single architectural decision eliminates the LPC/SPI bus that defeats discrete TPMs. Microsoft's framing in the announcement post: the design targets attacks "where an attacker can steal or temporarily gain physical access to a PC ... on the communication channel between the CPU and TPM" (Microsoft Security Blog [@ms-pluton-announce]).

Microsoft-authored security subsystem integrated into the SoC die of supported AMD, Intel, and Qualcomm processors. Pluton presents a TPM 2.0 interface to Windows but adds firmware-update via Windows Update and capsule, on-die placement (no external bus to sniff), and a Microsoft-maintained codebase that Microsoft describes as "Rust-based" from 2024 onward [@ms-pluton-learn] on AMD and Intel platforms. Microsoft's name for keys that are "never exposed outside the protected hardware, even to the Pluton firmware itself" (Microsoft Security Blog, 2020 [@ms-pluton-announce]). Conceptually equivalent to Apple's UID-tangled keys: a hardware boundary that even the firmware running on top cannot cross.

Inside the die, Pluton runs its own small processor (the vendors do not publish the ISA in customer-facing docs), with its own ROM, on-die RAM, hardware crypto engines, and a hardware-confined key store. It exchanges messages with the host through a mailbox interface analogous to SEP's, but the higher-level wire protocol it speaks back to the host is TPM 2.0.

3.3 TPM 2.0 as the personality, not the limit

Pluton implements the TPM 2.0 command set. That means BitLocker, Windows Hello, Credential Guard, System Guard, Measured Boot, and Device Health Attestation all work against Pluton with no modifications -- they think they are talking to a TPM 2.0 chip, and they are (Microsoft Pluton as TPM, Microsoft Learn [@ms-pluton-as-tpm]).

TPM 2.0 compatibility is the compromise that buys Microsoft adoption. The entire Windows security stack was already designed against the TCG TPM 2.0 wire protocol. Forcing it onto a new API would have required years of platform engineering. Forcing it onto a new API and getting OEMs to adopt the new chip would have required forever.

You could read the Pluton design as "TPM 2.0 with a software-update channel." That is mostly right and is how the documentation usually describes it. But Pluton also supports Pluton-specific paths beyond TPM 2.0 -- the Microsoft Learn documentation [@ms-pluton-learn] refers to Pluton-rooted credentials and attestation flows that ride alongside the TPM personality. The TPM interface is the lowest common denominator, not the ceiling. flowchart TD subgraph Windows["Windows OS"] BL[BitLocker] WH[Windows Hello] CG[Credential Guard] DHA[Device Health Attestation] end subgraph Pluton["Pluton subsystem on SoC"] TPMpers["TPM 2.0 personality -- (PCRs, EK, AK, Quote, Seal)"] MSrooted["Microsoft-rooted services -- (Pluton credentials, MS-signed firmware)"] end BL --> TPMpers WH --> TPMpers CG --> TPMpers DHA --> TPMpers DHA --> MSrooted WH --> MSrooted

3.4 The patch channel

This is the design feature Microsoft most emphasizes and where the philosophical break with Apple is most visible. Pluton firmware can be updated through two paths (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]):

UEFI capsule update. The Pluton firmware lives on the system's SPI flash and is loaded during early boot. A capsule update -- delivered via the same UEFI mechanism that updates BIOS -- can replace it.
Dynamic loading via Windows Update. Microsoft can ship a new Pluton firmware blob through Windows Update; the OS loader picks it up the next time the subsystem comes online.

Apple's update model is essentially the first path with a different label. The SEP firmware ships inside the iOS/macOS image bundle, signed by Apple, and is loaded at boot. There is no Windows-Update-style ambient channel separate from the OS image.

Patchable. By Microsoft. Through the channel users already trust. This is the single biggest practical advantage Pluton has over discrete TPMs, and the single biggest political problem.

The structure of this difference is what makes the Apple-vs-Microsoft comparison sharp. Apple controls the entire silicon, OS, and update channel. The patch path is fast because everything is one vendor. Microsoft does not control the silicon -- AMD, Intel, and Qualcomm do -- but they wrote the firmware, signed it, and route it through Windows Update. The patch path is fast because Microsoft has been delivering OS-level updates to a billion machines for a quarter century.

3.5 Rust as the firmware base

In 2024 Microsoft began shipping Pluton firmware on AMD and Intel with what the documentation calls "a Rust-based firmware foundation given the importance of memory safety" (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). This is, as far as we can tell from primary sources, the most prominent shipping production use of Rust inside an x86 platform security subsystem. It addresses the most common class of TPM firmware bugs, which historically have been C memory-safety issues -- bounds errors, use-after-frees, integer overflows.

Note: Rust eliminates the spatial and temporal memory-safety bugs that dominate CVE counts in C-based firmware. It does not prevent logic bugs, side-channel leaks, or fault-injection vulnerabilities. The faulTPM work, discussed in Section 7, exploits the underlying voltage rail rather than firmware bugs -- and the same physics apply whether the firmware is in C or Rust.

If the SEP's design philosophy is "small fixed-purpose computer," the Pluton design philosophy is "in-die TPM 2.0 we can actually patch, written carefully enough that we will not have to patch it often." Two different bets about which property mattered most.

4. The tightly-coupled vs SoC-integrated trade-off

So far we have two architectures: SEP as a separate physical core, Pluton as an on-die subsystem. They sound different. They are different. But "separate core" and "on-die subsystem" both refuse the discrete-TPM design where the security chip is off the SoC and reachable over a motherboard bus. Why did both vendors converge there, and what is the trade-off between SEP-style and Pluton-style integration?

4.1 What both reject

The discrete TPM 2.0 model is the baseline. A separate chip, often a Nuvoton, Infineon, or ST device on the motherboard [@pulse-tpm-sniff], connected to the platform via LPC, SPI, or I²C. The TCG spec it implements is excellent. The physical placement is the problem.

Pulse Security's attack is the canonical demonstration. With lpc_sniffer_tpm on a $40 FPGA, they probed the LPC bus of a Surface Pro 3 as it booted, captured the bytes the TPM returned for the unsealed Volume Master Key, and used those bytes to decrypt the disk (Pulse Security: TPM Sniffing [@pulse-tpm-sniff]). The TPM was working correctly. The bus was the problem. There is a mitigation -- pre-boot PIN or USB key, so the VMK is bound to something not on the wire -- but the default BitLocker configuration on most enterprise hardware does not enable it.

The class of physical-access attacks in which an adversary attaches probes to the motherboard bus carrying TPM responses, captures the cleartext key material the TPM legitimately returns, and uses it directly. Defended against by either eliminating the external bus (Pluton, SEP) or by requiring authenticated/encrypted sessions plus pre-boot user authentication (TPM 2.0 parameter encryption, BitLocker TPM+PIN).

Both SEP and Pluton refuse to expose that bus. The keys never appear on an external wire. That is the structural property both architectures buy by being on the SoC.

4.2 Tightly-coupled (SEP) vs subsystem-on-die (Pluton)

After agreeing on "no external bus," the two diverge sharply on what "on the SoC" should look like.

flowchart TD subgraph SEPDie["Apple SoC (A14, M1, M2, etc.)"] SEPCore["SEP core -- own voltage -- own clock -- own ROM"] MPE["Memory Protection Engine"] APCore["Application processor cores"] SEPCore -- mailbox --> APCore SEPCore --> MPE end subgraph PlutonDie["AMD/Intel/Qualcomm SoC"] PSub["Pluton subsystem -- (may share voltage rail -- with security die area)"] PSP["Vendor security subsystem -- (AMD PSP / Intel CSME)"] Cores["Application cores"] PSub -- on-die fabric --> Cores PSub -.runs on top of.-> PSP end

The SEP is a separate physical core with its own clock, its own voltage rail, and crucially no shared microarchitecture with the application processor. That last point matters because the family of cross-thread, cross-core, and frequency-scaling side channels -- Meltdown, Spectre, Foreshadow, Hertzbleed, and their cousins -- generally requires the attacker code to be co-resident on the same physical pipeline or share a microarchitectural resource. The SEP simply does not share execution resources with potentially hostile code on the application cores (Apple Platform Security: Secure Enclave Processor [@apple-sep-chapter]).

Pluton-on-AMD is implemented inside the AMD Platform Security Processor environment. Pluton-on-Intel is implemented inside Intel's Converged Security and Management Engine. These are pre-existing vendor security subsystems Microsoft layered Pluton atop. The Pluton subsystem is logically separate, with its own firmware and its own key store. Whether it has a fully separate physical voltage rail and clock domain from the application cores is not something the public documentation states clearly, and the answer almost certainly varies by silicon partner.This is a place where the comparison is hardest to make crisply. Apple has a single answer because Apple makes one SoC family. Microsoft has three answers because Pluton lives inside whatever security subsystem AMD, Intel, or Qualcomm already provide. The detail-level guarantees vary.

4.3 The SGX cautionary tale

There is a third design point worth flagging because both vendors implicitly chose against it: putting the trusted execution environment inside the application CPU cores themselves. Intel SGX, introduced in 2015 [@intel-sgx], did exactly that. Enclaves were memory regions with hardware access control inside the same cores running ordinary software.

SGX was a beautiful idea and an academic catastrophe. Foreshadow, ZombieLoad, SgxPectre, Plundervolt, and a long sequence of related attacks reused the side-channel-rich microarchitecture of modern Intel cores to leak enclave contents. Intel deprecated SGX on most consumer processors in 2022 [@intel-sgx-deprecation], retaining it on server SKUs for confidential computing scenarios where the threat model is different.

The lesson is something both Apple and Microsoft seem to have absorbed: a trusted execution environment that shares any microarchitectural state with the workloads it must protect from is structurally compromised, because microarchitecture is too rich and too leaky to perfectly isolate. The SEP rejects this by living on its own core. Pluton rejects it by living in a separate subsystem.

Arm TrustZone, introduced in Arm v7 around 2008 [@arm-trustzone], pioneered the "secure world / normal world" split inside a single core. TrustZone is closer to SGX than it is to SEP or Pluton in this respect: secure world and normal world share the same physical pipeline. TrustZone influenced both SEP and Pluton in the sense that "you need a separate execution environment for security code" became table stakes; both companies then moved that environment off the application core entirely.

4.4 The trade-off in one sentence

A dedicated core (SEP) maximises side-channel resistance and minimises attack surface, at the cost of vendor proprietary lock-in and zero portability. An on-die subsystem (Pluton) preserves the TPM 2.0 standard, ships on three silicon vendors, and inherits the security guarantees of the underlying vendor security subsystem -- whose history, as we will see, is less reassuring than Apple's monopoly on its own silicon.

Key idea: SEP wins on isolation. Pluton wins on portability. Neither wins on both. The choice you make at the SoC level constrains every API, every patch path, and every threat-model claim downstream.

5. The APIs developers actually call

Architectures are interesting. What ships in production code is what determines whether developers use these things correctly. The API surfaces are wildly different, and the difference matters.

5.1 Apple: SecKey, App Attest, LocalAuthentication

On Apple platforms, the SEP is exposed through a handful of frameworks. The most common entry point is SecKey in the Security framework, with key attributes that bind the key to the SEP:

kSecAttrTokenIDSecureEnclave makes the key SEP-resident.
kSecAttrAccessControl with LAContext adds biometric or passcode gating.
kSecAttrIsPermanent puts it in the Keychain [@apple-keychain].

The key itself never leaves the SEP. The application receives an opaque handle. Asking the framework to sign a message turns into a mailbox call to the SEP, which evaluates the access-control policy (e.g., "the user must FaceID-authenticate within the last five seconds") and either signs or refuses.

{` // This is a conceptual model of what happens when iOS code asks the SEP // to sign a message with a key whose private half lives inside the SEP. // The real code is Swift + Security.framework; this JS captures the logic.

function generateSEPKey(accessControl) { // SEP generates the keypair internally const priv = sepRandomBytes(32); // never leaves SEP const pub = ecP256ScalarMul(priv, BASE_G); const blob = aesKeyWrap(sepUIDDerivedKey, priv); return { publicKey: pub, handle: opaque(blob), policy: accessControl }; }

const k = generateSEPKey({ requireBiometric: true }); console.log("Public key returned to the app:", k.publicKey); console.log("Private key location: inside SEP, never accessible to app code"); `}

Beyond SecKey, the SEP underpins:

LocalAuthentication -- Face ID / Touch ID matching happens inside the SEP. The biometric template never leaves the SEP, and the application is only told yes/no.
DeviceCheck and App Attest -- documented in the Apple Platform Security Guide [@apple-platform-security]. App Attest gives each app installation a SEP-rooted asymmetric key whose certificate chains to Apple's CA, letting servers verify that a sign-up came from a genuine app on a genuine Apple device.
Data Protection / FileVault -- per-file class keys are wrapped under SEP-held intermediate keys.
Apple Pay -- payment credentials are SEP-resident and gated on biometric/passcode authentication.

Apple's hardware-backed app integrity service [@apple-platform-security]. Each install of each app receives a unique SEP-resident key whose attestation certificate, signed by Apple, lets a back-end server verify that the request originates from a non-tampered installation. The closest cross-platform analogue is Google Play Integrity API; the closest discrete-TPM analogue is TPM 2.0 attestation, but App Attest is more strongly bound to the specific app installation.

5.2 Microsoft: TBS, NCrypt, Pluton-rooted credentials

On Windows, the TPM 2.0 personality means Pluton is reached through the same APIs as any TPM:

TPM Base Services (TBS) -- the low-level Win32 API for sending TPM 2.0 commands.
CNG (Cryptography Next Generation) with NCrypt and the Microsoft Platform Crypto Provider -- the higher-level key API that asks "store this key in the TPM, gated on the user's PIN."
BCryptDecrypt / BCryptSignHash as the in-process crypto API on top.

The DPAPI key-protection model -- file/blob protection rooted in user logon credentials -- has a CNG variant documented as CNG DPAPI [@ms-cng-dpapi] that integrates with TPM-rooted hierarchies. Above that sit the consumer-facing systems: BitLocker for disk encryption [@ms-bitlocker], Windows Hello for credential storage, Credential Guard for isolating LSA secrets in a virtualization-based security enclave, and Microsoft Entra ID conditional access for cloud sign-in.

The TCG TPM 2.0 Library Specification [@tcg-tpm2] defines the command set, object hierarchy, and key-handling semantics of TPM 2.0 chips. Commands include `TPM2_CreatePrimary`, `TPM2_Create`, `TPM2_Load`, `TPM2_Seal`, `TPM2_Unseal`, `TPM2_Quote`, and `TPM2_Certify`. Both discrete TPMs and Pluton implement this command set. flowchart LR subgraph Apple["Apple application stack"] App[App] --> Sec["Security.framework -- (SecKey, SecAccessControl)"] App --> LA["LocalAuthentication -- (LAContext)"] App --> DC["DeviceCheck / App Attest"] Sec --> Mailbox[SEP mailbox] LA --> Mailbox DC --> Mailbox Mailbox --> SEPSvc[SEP services] end subgraph MS["Windows application stack"] WApp[App] --> NCrypt["CNG / NCrypt"] WApp --> Hello["Windows Hello"] WApp --> Entra["Entra ID / Health Attestation"] NCrypt --> TBS["TPM Base Services"] Hello --> TBS Entra --> TBS TBS --> Pluton["Pluton (TPM 2.0 personality)"] Entra --> PlutonMS["Pluton MS-rooted services"] end

5.3 What the API shape tells you

The SEP API forces every call into the small set of operations the SEP firmware implements. There is no TPM2_PolicyLocality(2) equivalent or TPM2_PolicyOR combinator on the SEP. You ask for a key, you ask for a signature, you ask for a biometric match, and that is mostly the surface. From a developer's point of view, the SEP feels like a very small set of well-defined building blocks.

The TPM 2.0 API, by contrast, is enormous. There are several hundred commands. The TPM has policy expressions, sessions, hierarchies (storage, endorsement, platform, owner), and a half-dozen attestation primitives. This expressiveness was the right call for an open standard -- the TCG had to accommodate every conceivable use case across two decades. It also means that "wrote TPM 2.0 code correctly" is a measurable engineering skill rather than a default.

Note: On Apple platforms, prefer kSecAttrTokenIDSecureEnclave with kSecAccessControl rather than rolling your own key handling. On Windows, prefer CNG with Microsoft Platform Crypto Provider over raw TBS unless you specifically need a TPM command not exposed by CNG. Both vendors put their good defaults in the higher-level APIs.

5.4 A note on what is not exposed

Neither platform exposes the device's per-silicon root key to applications. On Apple, the UID is sealed inside the SEP; on Microsoft, the Pluton Endorsement Key is unique per chip but applications interact only with the AKs (Attestation Keys) derived from it. This is deliberate: per-device permanent keys, if exposed, enable cross-service tracking. The exposed primitives are either per-app/per-installation (App Attest), per-session (TPM2_Quote with a fresh AK), or ephemeral (a freshly-generated SEP key).

That choice maps to a privacy property we will pick up in the next section: how each platform answers "prove this is a real device" without becoming "track this specific user across every service."

6. Identity, attestation, and the privacy problem

The deepest difference between Apple and Microsoft is not architectural. It is the answer each one gives to a question that sounds simple: what does it mean to prove a device is real?

6.1 Why attestation is hard

A naive answer is: burn a unique identifier into every chip and have the chip sign messages with the corresponding private key. That works for proof. It also creates a per-device pseudonym that every service can recognise and correlate. The naive answer is a surveillance disaster.

A better answer keeps the unforgeability of "this signature came from a real device" and adds an unlinkability property: the signature does not identify which device, only that it is genuine. This is what cryptographers call anonymous attestation, and the canonical construction is DAA.

A class of cryptographic protocols that let a hardware token sign messages in a way that proves it belongs to a group of legitimate devices without revealing *which* device. Introduced by Brickell, Camenisch, and Chen in 2004 [@brickell-2004-daa] as part of the TPM 1.2 specification work, with the elliptic-curve variant ECDAA standardized for TPM 2.0. See the Wikipedia overview [@daa-wikipedia] for the protocol skeleton.

The mathematics of DAA rests on group signatures with selective linkability. A device runs the join protocol once with a group issuer (the "Privacy CA" or analogous authority) and receives a credential. It can then prove, via a Camenisch-Lysyanskaya-style signature of knowledge, that it holds such a credential without revealing which one. With ECDAA, the join and signing operations are roughly the cost of a couple of elliptic-curve multiplications.

The privacy property comes with caveats. Verifiers can opt into "basename" linkability, where signatures from the same device addressed to the same service are linkable -- letting a service recognise a returning user without letting it correlate across services. The math has been deployed in TPM 2.0 since the 2014 spec.

6.2 The Microsoft path: TPM 2.0 attestation plus Microsoft-rooted services

Pluton inherits TPM 2.0's attestation primitives. The standard flow:

Generate an Attestation Key (AK) inside the TPM, with a private half that never leaves.
Certify the AK to a Privacy CA (or via ECDAA) using the Endorsement Key.
Hash the boot configuration into Platform Configuration Registers (PCRs) during measured boot.
Have the relying party send a fresh nonce.
Issue TPM2_Quote(AK, PCR_mask, qualifying_data=nonce).
Send the quote, the AK certificate, and the boot event log to the relying party.
The relying party replays the event log, checks that the replayed PCRs match the quoted ones, validates the AK certificate chain, and validates the signature.

attest(nonce, pcr_mask):
    AK = TPM2_Create(parent=EK, type=signing)
    AK_cert = privacy_CA.certify(AK_pub, EK_cert)    # or ECDAA group sig
    quote = TPM2_Quote(AK, pcr_mask, qualifying_data=nonce)
    return (quote, AK_cert, event_log)

verify(quote, AK_cert, event_log, expected_pcrs):
    assert privacy_CA.verify(AK_cert)
    assert ECDSA_verify(AK_cert.pub, quote.sig, quote.body)
    assert quote.qualifying_data == nonce
    assert replay_log(event_log) == quote.pcrs == expected_pcrs

That covers raw TPM 2.0. Microsoft layers on top a service called Device Health Attestation that does the verifier work as a cloud service, supplying Reference Integrity Manifests for known-good Microsoft-signed boot states. Microsoft Entra ID conditional access policies can then refuse sign-in to devices whose Pluton-signed health attestation does not match an expected baseline (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]).The interesting privacy property here is that ECDAA-grade unlinkability is available through TPM 2.0, but Microsoft's deployed services tend to use Privacy-CA-style flows where the AK certificate is well-defined and reusable. Whether a given Microsoft attestation flow is anonymous-unlinkable or pseudonymous-linkable is a per-service detail rather than a platform property.

6.3 The Apple path: rooted in Apple's CA, scoped per app

Apple's DeviceCheck and App Attest [@apple-platform-security] take a different approach. App Attest gives each installation of each app a unique SEP-resident key. The corresponding attestation certificate chains to Apple's CA. Apps prove integrity to their own back-end servers by having the server send a nonce, the SEP signing the nonce with the per-install key, and Apple's CA chain validating that the key was issued on a genuine Apple device.

The privacy property is scoped differently from DAA. The key is per-installation, which means uninstalling and reinstalling the app generates a new key with no link to the old one. Across different apps on the same device, the keys are independent -- so two apps cannot collude with their respective back-ends to detect they are on the same phone. The trade-off: there is no formal anonymity within a group; the key is identifiable to its single installation, but that installation is fresh each install.

DeviceCheck is older and weaker. It gives an app a two-bit value the developer can set per device, retrievable on future runs. It is fraud-signal infrastructure, not cryptographic proof.

DAA is a group-signature scheme; Apple's App Attest is a per-installation public-key scheme certified by Apple. They are not the same primitive. DAA gives "I am in this group of devices" without revealing which device. App Attest gives "I am this specific installation, and Apple says it is genuine." The privacy distinction matters when the threat is correlation across services rather than correlation within a single service.

6.4 Where the two converge: FIDO2/WebAuthn

Both platforms expose their hardware-backed credentials through a single cross-platform standard: FIDO2/WebAuthn. When a browser asks "create a credential bound to this origin, hardware-resident if possible," the underlying operating system asks SEP or Pluton to generate the key. The resulting public-key credential, signed by the device's attestation key, is what the relying party verifies (FIDO Alliance [@fido-alliance]).

sequenceDiagram participant Browser participant OS as OS Authenticator participant HW as SEP or Pluton participant RP as Relying Party RP->>Browser: Challenge nonce, RP ID Browser->>OS: navigator.credentials.create() OS->>HW: Generate key bound to RP ID + user gesture HW-->>OS: Public key + attestation OS-->>Browser: Public key + signed attestation Browser->>RP: Registration response Note over RP: Stores public key RP->>Browser: Authentication challenge Browser->>OS: navigator.credentials.get() OS->>HW: Sign challenge (user gesture) HW-->>OS: Signature OS-->>Browser: Assertion Browser->>RP: Authentication response RP->>RP: Verify signature with stored pubkey

FIDO2/WebAuthn is the most boring and most important fact about modern hardware roots of trust: from the application's point of view, you no longer need to know whether you are talking to SEP or Pluton or a discrete TPM. The same JavaScript runs on all of them. We will return to FIDO2 in Section 8.

Note: Attestation is where Apple and Microsoft diverge most sharply on privacy philosophy. Microsoft uses TPM 2.0 with anonymous-group cryptography available but not always deployed. Apple uses per-installation keys rooted at Apple's CA. FIDO2/WebAuthn is the layer where both meet the developer at the door.

7. What has actually broken

Architecture is a story you tell about a system. Attacks are the system's reply. Both SEP and Pluton have a public attack history; reading it carefully is the fastest way to understand the real threat model rather than the marketing one.

7.1 checkm8 and the unpatchable boot ROM

In late 2019, the researcher axi0mX published ipwndfu [@ipwndfu], an exploit against a use-after-free in the SecureROM USB DFU stack of Apple SoCs from A5 through A11. The advisory carries CVE-2019-8900 [@nvd-checkm8] and CERT/CC VU#941987 [@cert-checkm8]. Because SecureROM is mask ROM -- etched into the silicon, immutable -- Apple cannot patch it. The only mitigation was new silicon. A12 and later are immune; earlier devices are permanently affected.

What checkm8 buys an attacker is application-processor code execution at boot time, on a device they have physical access to. That is significant. It enables forensically sound extraction tooling -- the Elcomsoft writeup walks through exactly which iPhone models and iOS versions are supported [@elcomsoft-checkm8]. It also covers the Apple T2 chip used in 2018-2020 Intel Macs [@apple-a-series], which is built on the same A10-family silicon.

But checkm8 does not, by itself, break SEP secrets. The SEP is still gated by the device passcode and the data-protection class keys. An attacker with checkm8 can run code on the AP, but they still need the passcode to unlock the user's protected data (CERT/CC VU#941987 [@cert-checkm8]). The forensic value of checkm8 comes from being able to brute-force passcodes more effectively, capture keyboard state, and access classes of data not bound to a passcode -- not from extracting SEP-held keys directly.

Note: If your organization still has 2018-2020 Intel Macs (T2-bearing) in service, they remain physical-access-attackable. The exploit is mature, the tooling is public, and the silicon will never be patched. For high-value users, retire T2 hardware in favor of Apple Silicon Macs (M1 and later, which use A14-derived SoCs immune to checkm8) (Elcomsoft: using checkm8 [@elcomsoft-checkm8]).

The Pangu team's "Blackbird" SEPROM exploit, presented at MOSEC 2019, reportedly compromised SEPROM on A10/A10X devices. Apple has not published a detailed advisory for that work and the original presentation materials are not in the verified-sources list, so we mention it only by way of acknowledging that even SEP boot ROMs have a finite security lifetime. The architectural point stands: any unpatchable ROM becomes a permanent liability when a bug is found in it.

7.2 LPC sniffing and discrete TPMs

We opened with this attack and it deserves a second pass in the context of Pluton's design. The Pulse Security writeup [@pulse-tpm-sniff] demonstrates extraction of the BitLocker Volume Master Key from a Microsoft Surface Pro 3 (TPM 2.0) and a Lenovo laptop (TPM 1.2) using a $40 FPGA on the LPC bus. The attack requires physical access for under an hour and modest soldering skill.

This is the textbook case where Pluton is structurally better than discrete TPMs: there is no external bus to sniff because the security subsystem lives on the SoC die. The same attack against a Pluton-enabled CPU is not just hard, it is geometrically impossible. There is no bus to attach probes to.

That is not the same as "Pluton is unattackable" -- it just means this specific attack class is closed.

7.3 faulTPM and the AMD PSP

The most consequential publication on Pluton-adjacent silicon is Werling, Buhren, Jacob, and Seifert's 2023 USENIX WOOT paper "faulTPM" [@faultpm]. The attack: voltage fault injection against AMD's Platform Security Processor (PSP), the TEE on which AMD's fTPM runs, on Zen 2 and Zen 3 CPUs. The result: full extraction of the fTPM key derivation seed. With that seed, the attackers decrypted all sealed objects regardless of PCR policy or anti-hammering, and recovered the BitLocker VMK on a Lenovo Ideapad. The reproducible attack code is PSPReverse/ftpm_attack on GitHub [@faultpm-repo].

Several careful observations:

The published attack targets non-Pluton AMD fTPM. Pluton-on-AMD is a separate code path; faulTPM as published does not directly extract Pluton state.
Pluton-on-AMD runs in the PSP environment. The underlying TEE that faulTPM compromises is the same TEE Pluton-on-AMD rides on. Whether the additional hardening Pluton adds is sufficient to defeat fault injection at the PSP level is an open empirical question.
There is no published voltage-glitch attack against Microsoft Pluton specifically as of May 2026 in the verified sources surveyed. Absence of evidence is not evidence of absence; serious researchers are reportedly working on it.

A physical attack class in which the attacker briefly reduces or perturbs the supply voltage to a target chip at a precisely timed moment, causing it to mis-execute an instruction in a controlled way. With sufficient practice, VFI can be used to skip authentication checks, leak intermediate values, or corrupt key derivation. Defenses include redundant voltage sensors, double-execution of sensitive operations, and physically separating the voltage domain of the security subsystem -- mitigations Apple alludes to for SEP and Microsoft alludes to for Pluton, but neither vendor publishes a complete defensive model. If your adversary is a state-level laboratory with \$50K of equipment and a few hours of physical access, no commodity hardware root of trust on the market today is fully resistant to fault injection. The realistic question is "how much does extracting the key cost, and is that cost above the value of what is protected?" For consumer threat models, faulTPM is exotic; for high-value enterprise or dissident use cases, it is in scope.

7.4 What is not known to be broken

Modern SEP (A14+/M-series) has no publicly disclosed extraction attack as of the May 2026 verified sources reviewed. The combination of dedicated core, MPE with anti-replay, lower clock, and SSC-backed replay protection has held up. This is consistent with -- but does not prove -- the architectural claim that the dedicated-core design closes the side-channel and co-execution attack surface.

Pluton with the 2024+ Rust firmware foundation has no publicly disclosed direct extraction attack. The faulTPM family of attacks remains an open concern at the PSP layer; the LPC bus class is closed by design; firmware bugs are reduced (not eliminated) by the move to memory-safe code.

flowchart TD A["Attack class"] --> B{"Discrete TPM"} A --> C{"AMD fTPM"} A --> D{"Pluton"} A --> E{"Apple SEP A14+"} B --> B1["LPC sniffing: yes (Pulse Security)"] B --> B2["Firmware bug: rare patches"] C --> C1["faulTPM: full extraction"] C --> C2["Patches: BIOS only"] D --> D1["LPC sniffing: not applicable"] D --> D2["faulTPM-like on PSP: open"] D --> D3["Patches: Windows Update + capsule"] E --> E1["checkm8 on A5-A11: AP code exec"] E --> E2["Direct SEP extraction A14+: none public"] E --> E3["Patches: iOS/macOS update, mask ROM never"]

The honest summary is that as you move from discrete TPMs to fTPMs to Pluton to SEP, the attack surface shrinks but the residual attacks get more expensive rather than disappearing. The faulTPM line is still the academic state of the art in showing this.

8. Cross-platform standards: the layer where the divide gets papered over

If you are a web developer in 2026 and a user asks "how do I sign into your site with my Touch ID or my Windows Hello fingerprint?" the answer is the same in either case: WebAuthn. The standard does not care which hardware root of trust the OS happens to expose underneath.

8.1 FIDO2/WebAuthn as the lingua franca

The FIDO Alliance [@fido-alliance] defines the protocols. WebAuthn is the W3C JavaScript API; CTAP (Client to Authenticator Protocol) is the underlying transport between the browser/OS and the authenticator. The authenticator can be a USB security key, a phone, a built-in platform authenticator backed by SEP or Pluton, or something else entirely. The relying party sees the same registration and authentication ceremony in all cases.

The handful of properties WebAuthn guarantees -- origin binding, user gesture, fresh signature per challenge -- are independent of the silicon underneath. The handful of properties it does not try to guarantee -- "is this device freshly compromised by a kernel rootkit" -- are not fixable at the protocol layer either; that is what attestation extensions are for.

8.2 Where attestation extensions vary

WebAuthn defines optional attestation extensions that let a relying party request a hardware-backed proof that the authenticator is genuine. Apple's attestation through WebAuthn rides on App Attest infrastructure; Microsoft's rides on TPM 2.0 attestation. The receipts differ in format and certificate chain, but the higher-level question "does the public key come from genuine hardware" gets answered on both platforms.

For most relying parties, the cross-platform truth is simpler than the underlying mechanics: ask for a hardware-backed credential, accept the WebAuthn response, validate the signature, and let the platform handle what kind of silicon was involved.

WebAuthn looks like it should be the climax of the article. From an architecture perspective, it is the anticlimax. The whole point is that, at the application layer, SEP and Pluton are interchangeable. That is what the standard is for. The differences resurface only when you care about device-class attestation or about the privacy property of the attestation key -- both of which are extension-level concerns rather than core-protocol concerns.

8.3 TPM 2.0 as the other lingua franca

TPM 2.0 itself plays this role in non-web contexts. Enterprise tools that need to attest a device's boot state -- Microsoft Entra ID conditional access, MDM compliance evaluators, Linux remote attestation frameworks -- speak TPM 2.0. Pluton exposes the TPM 2.0 wire protocol, so these tools work unchanged (Microsoft Pluton as TPM, Microsoft Learn [@ms-pluton-as-tpm]).

Linux on Apple Silicon (Asahi) currently cannot use SEP for analogous attestation; Apple does not expose the SEP to non-Apple operating systems, and there is no TPM 2.0 emulation. This is a real gap for users who want Apple hardware with a non-Apple OS.

8.4 The Android third corner

This article is about Apple vs Microsoft, but a complete picture must mention that Android has its own hardware root of trust story rooted in Trusty/TEE-style designs on ARM TrustZone plus discrete StrongBox elements on Pixel-class hardware. Cross-platform mobile development frequently abstracts SEP and Android StrongBox under a common interface (e.g., React Native's keychain modules), and the privacy and attestation properties of the two systems are not identical but rhyme. Google Play Integrity API plays the role App Attest plays on iOS.

Note: At the application layer, the right question is not "SEP or Pluton" but "are you using WebAuthn or TPM 2.0 or App Attest at the right point in the trust path." The platform-specific differences sit beneath those interfaces, and the standards are explicitly designed to be the place developers can stop caring.

9. Deployment dynamics: who ships what, where, when

The two industries have different shapes, and that shapes the deployment story.

9.1 Apple: vertical integration, total reach

Every shipping Apple device since the iPhone 5s contains a SEP, by virtue of every shipping Apple SoC containing one. That includes (Apple Platform Security: Secure Enclave [@apple-sep-chapter]):

iPhone 5s and later (A7+)
iPad Air and later
Apple Watch Series 1 and later
Apple TV HD and later
HomePod and HomePod mini
Apple Vision Pro
All Apple Silicon Macs (M1, M2, M3, M4 families)
All Intel Macs from 2018 to 2020 (via the T2 chip)

There is no SKU differentiation. There is no "Pro vs Air" split on whether security hardware is present. You buy a current-generation Apple device, you get the SEP. This is the upside of vertical integration: deployment by default.

The downside is that nothing else gets the SEP. Linux on Apple Silicon -- the Asahi Linux project -- cannot use the SEP for keychain operations, FileVault wrapping, or attestation. Apple does not expose the SEP outside of macOS, iOS, iPadOS, watchOS, tvOS, and visionOS. The hardware is universal in Apple's product line and absent everywhere else.

9.2 Microsoft: open multivendor, opt-in adoption

Pluton ships in silicon Microsoft does not make. That changes the deployment story in two ways:

Vendor availability. As of the current Microsoft documentation [@ms-pluton-learn], Pluton is present in AMD Ryzen 6000 and later, Intel Core Ultra Series 2 and later, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series. Anything older still uses discrete TPM 2.0 or vendor fTPM.
OEM enablement. The chip can be physically present and disabled in UEFI. Microsoft has been pushing OEMs to ship Pluton enabled by default on Copilot+ PCs, but the universe of laptops is heterogeneous, and the practitioner answer is "check tpm.msc to see what manufacturer ID is reported."

Default-enabled-on-shipping-hardware is documented for Surface Laptop 7 and Surface Pro 11 Copilot+ PCs. Various Lenovo ThinkPad Z, Dell Latitude, and HP EliteBook configurations follow (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). On other devices Pluton may be present but disabled in firmware, falling back to discrete TPM or vendor fTPM.This is a deployment claim that ages quickly. The shipping matrix shifts every six to twelve months as new SoCs come to market and OEMs rev their UEFI defaults. The verification workflow is the same regardless: Get-PnpDevice and tpm.msc on the actual hardware tell you what is active.

9.3 The patch-channel difference, made concrete

Apple ships SEP firmware inside its OS update. When the user installs iOS 19.4 or macOS 16.2, the bundle includes a new sepOS image; the device verifies and loads it during the next boot (Apple Platform Security [@apple-platform-security]).

Microsoft ships Pluton firmware through Windows Update and UEFI capsules. The OS-driven path lets Microsoft push a firmware refresh to billions of machines without OEM cooperation. The capsule path covers the case where the firmware is needed during early boot before Windows itself is in control.

Discrete TPMs occupy the third position: firmware updates exist but require an OEM-issued utility that few users ever run. This is why most enterprise TPMs in the field run firmware from 2020 or earlier.

Note: A serious bug in a discrete TPM chip is, in practice, never fully fixed because the patch never reaches the bulk of deployed devices. A serious bug in Pluton can be patched globally inside a Patch Tuesday cycle. A serious bug in SEP can be patched globally inside an iOS/macOS minor release. The same bug class produces three different incident-response time scales.

9.4 The economic and political layer

Apple controls every step from sand to support page. The benefit is consistency. The cost is that Apple decides what the SEP can and cannot do, with no externally visible audit, and the customer cannot verify the firmware. For the Apple-customer market, that has not been a deal-breaker.

Microsoft controls the Pluton firmware. The benefit is that one team's engineering effort propagates across three silicon vendors and thousands of OEM SKUs. The cost is that the OS update channel and the security update channel collapse into one Microsoft-controlled flow. Critics describe this as platform lock-in; supporters describe it as the only way to actually patch the silicon at scale. Both readings have evidence behind them.

The same patch channel that protects users from unpatched silicon bugs is the patch channel a hypothetical compelled-update scenario would use. There is no commodity product that gives the device owner an independent veto on root-of-trust firmware updates.

This is a real open problem, not a fictional one. The Trusted Computing Group has a notion of "owner-authorized" TPM hierarchies; Azure Sphere uses a three-key model in which device owner, vendor, and Microsoft all hold signing capabilities for different scopes. Nothing in the commodity consumer space has yet shipped a model where the device owner can veto a vendor-signed firmware update on the security subsystem.

10. Where this goes next

The honest answer is that the immediate future is more of the same with three new pressures.

10.1 Post-quantum migration

The cryptographic primitives currently rooted in both platforms -- ECDSA P-256 in the SEP, RSA-2048 and ECDSA in TPM 2.0 -- are not post-quantum-safe. NIST standardized ML-KEM and ML-DSA in FIPS 203 and FIPS 204 in 2024 (the NIST publication URLs are outside our verified-source set, so this paragraph states the timeline at the policy level only). Migrating hardware-fused attestation roots to post-quantum schemes is genuinely hard because the silicon-burned UID-equivalent keys are baked at fabrication time and cannot easily be replaced.

The likely path: hardware retains agility at the wrapping layer (the unique chip key) while the attestation key types evolve. TPM 2.0 already supports algorithm agility in the spec, which is the kind of foresight you only appreciate a decade after it was added. SEP's key wrapping is bespoke; Apple has not published a PQC migration plan in the verified sources reviewed.

This is a place where the comparison gets uncertain. Both vendors will need to migrate. Neither has shipped a primary post-quantum-rooted attestation flow in their public 2026 documentation as far as we can verify.

10.2 Confidential computing convergence

The same silicon technologies that build SEP and Pluton are now powering confidential computing -- AMD SEV-SNP, Intel TDX, ARM CCA. These extend the "untrusted host kernel" threat model from disk encryption and credential storage to entire virtual machines. The trust roots of confidential computing currently live in the same chips' security subsystems: AMD's PSP holds SEV-SNP attestation keys; Intel's CSME, working with TDX, holds equivalent keys.

Pluton-on-Intel and Pluton-on-AMD will likely inherit responsibilities here as Microsoft consolidates more of the security subsystem under the Pluton name. Apple has not publicly signaled equivalent ambitions for SEP on the server -- Apple's server presence is mostly internal.

10.3 The AI agent identity problem

This is the next decade's question. When your laptop runs an autonomous AI agent that signs cloud API requests on your behalf, what attests to the agent's identity? The current architectures attest to the device and to user gestures, not to the agent. There is no shipping primitive in either SEP or Pluton that says "this signature came from agent X running on device Y, gated by user policy Z that the user actually consented to."

A defensible reading is that both vendors are moving slowly toward agent-bound credentials, but neither has published a clean primitive. This is an open design space. We mark it as a place to watch rather than a place where shipping products have answers.

There is no shipping commodity hardware root of trust with simultaneously: post-quantum attestation, owner-vetoable updates, independently audited firmware, and agent identity. There may not be one for a decade. The current architectures -- SEP and Pluton -- are the strongest commodity options available, and they are still incomplete relative to the design space.

10.4 The convergence that probably will not happen

People periodically suggest that Apple should expose the SEP via TPM 2.0 for cross-platform compatibility, or that Microsoft should ship a dedicated security core like SEP. Neither is likely. Apple's value proposition rests on vertical integration; opening the SEP to non-Apple operating systems would dilute it. Microsoft's value proposition rests on multi-vendor compatibility; mandating a SEP-style dedicated core would fragment their silicon partner relationships.

The structural diversity is here to stay. FIDO2/WebAuthn and TPM 2.0 are how the two systems will continue to interoperate without converging on a single hardware architecture. That is fine. It is even, arguably, good -- a monoculture would be worse for security than a duopoly with different threat-model trade-offs.

Key idea: The interesting question for the next decade is not whether Apple or Microsoft picks a different silicon strategy. It is whether the cross-platform standards layer -- WebAuthn, TPM 2.0, FIDO2 -- evolves fast enough to expose new security primitives (post-quantum attestation, agent identity, owner-vetoable updates) before any one vendor ships proprietary equivalents.

11. Frequently asked questions

Pluton presents a TPM 2.0 personality to Windows -- so BitLocker, Windows Hello, Credential Guard, and TPM-aware enterprise tools work unchanged -- but it is also more than a TPM 2.0. It exposes Microsoft-rooted services beyond the TCG spec, accepts firmware updates through Windows Update rather than only OEM utilities, lives on the SoC die rather than the motherboard (closing the LPC sniffing attack class), and -- from 2024 -- runs a Rust-based firmware foundation on AMD and Intel platforms (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). Two reasons. First, the SEP was designed before TPM 2.0 became the relevant cross-platform standard for Apple's product mix; SEP's API surface is bespoke to Apple's frameworks (`SecKey`, App Attest, LocalAuthentication, Keychain [@apple-keychain]). Second, exposing the SEP via TPM 2.0 would mean making the SEP usable from non-Apple operating systems on Apple hardware -- which is not how Apple ships its platforms. The SEP's lack of TPM 2.0 personality is a deliberate product decision, not a technical limitation. No -- not directly. Checkm8 (CVE-2019-8900) [@nvd-checkm8] exploits the SecureROM USB DFU stack on A5-A11 Apple SoCs and the T2 chip in 2018-2020 Intel Macs, giving an attacker with physical access application-processor code execution at boot. The SEP itself remains gated by the device passcode and the data-protection class keys (CERT/CC VU#941987 [@cert-checkm8]). The forensic value of checkm8 is the ability to mount passcode brute-force more effectively and access classes of data not bound to a passcode, not direct SEP-key extraction. Yes. The Pulse Security TPM-sniffing attack [@pulse-tpm-sniff] works because the discrete TPM returns the Volume Master Key over an external motherboard bus that an attacker can probe. Pluton lives on the SoC die; there is no external bus to attach probes to. The attack is structurally impossible against Pluton-rooted BitLocker. On laptops with discrete TPMs, the mitigation remains BitLocker with pre-boot PIN or USB key authentication. The published faulTPM attack [@faultpm] targets AMD's fTPM running in the AMD Platform Security Processor (PSP) on Zen 2 and Zen 3 CPUs, not Pluton specifically. However, Pluton-on-AMD is implemented atop the same PSP environment, so the underlying TEE is fault-attackable in principle. There is no publicly disclosed Pluton-targeted voltage-glitch attack as of May 2026 in the verified sources reviewed; whether Pluton's additional hardening blocks the fault-injection class is an open empirical question. For most purposes, no. FIDO2/WebAuthn [@fido-alliance] hides the difference at the API layer -- the same browser code talks to a SEP-backed credential on iOS/macOS and a Pluton-backed credential on Windows. You care about the difference when you need device-class attestation (Apple's App Attest vs Microsoft's Device Health Attestation), when privacy of the attestation key matters (Microsoft offers ECDAA-grade options via TPM 2.0; Apple offers per-installation keys), or when you need to support Linux on Apple Silicon (where neither path is available). Not in any current shipping commodity product. Apple devices ship SEP and no TPM 2.0; Windows devices ship Pluton, discrete TPM, or vendor fTPM but no SEP. The closest historical case is the Apple T2 chip in 2018-2020 Intel Macs [@apple-a-series]: the Mac ran macOS rooted at the T2 SEP, but if you booted Windows on the same hardware via Boot Camp, the T2 still provided the secure-boot anchor though Windows did not interact with it as a TPM.

12. Closing observation

There is a temptation, when comparing two designs as deeply considered as SEP and Pluton, to declare one the winner. Resist that temptation. The two architectures answer different questions for different markets, and the differences are exactly where each one shines. SEP is what you build when you own the silicon, the OS, and the patch channel. Pluton is what you build when you control the OS and the patch channel but need to ride on three other companies' silicon.

The closing observation worth keeping is the one Pulse Security demonstrated by accident: most hardware security failures are not failures of the math. They are failures of the physical placement and the patch flow. SEP and Pluton both close the historical bus-sniffing attack class. They both retain a slow channel for fault-injection research to chip away at. They both depend on the device owner trusting the vendor's signing infrastructure. The next big shift -- if it comes -- will probably be in who controls the patch channel, not in the silicon itself.

That is the bet to watch.

Pluton: A TPM On Silicon Microsoft Can Patch

noreply@paragmali.com (Parag Mali) — Sat, 09 May 2026 00:00:00 GMT

**Microsoft Pluton is the architectural answer to a TPM threat model that broke between 2019 and 2024.** It moves the TPM onto the application SoC die, runs Microsoft-authored Rust firmware on a dedicated TEE, and ships updates through Windows Update -- closing every attack surface that defeated discrete TPM (Andzakovic 2019), Intel PTT (TPM-Fail 2019), and AMD fTPM (faulTPM 2023). Each design choice retires a 2014-2024 attack class and places a new trust in Microsoft: silicon supply chain, firmware compiler, signing key, update channel. The chip is the cheapest part of the system; the cost is a single Microsoft signing key as the trust anchor for every Pluton-equipped Windows 11 client.

1. The question Microsoft answered architecturally before the prior article posed it

"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." That was the closing line of the previous article in this series [@prior-tpm-in-windows]. The counterintuitive fact: by the time that question was asked, Microsoft had been shipping its architectural answer to it for twelve years already, inside an Xbox.

The Xbox One launched in November 2013 with an on-die, Microsoft-signed security processor and a Microsoft-controlled firmware update path. Microsoft's own announcement seven years later named the lineage explicitly: "the Pluton design was introduced as part of the integrated hardware and OS security capabilities in the Xbox One console released in 2013 by Microsoft in partnership with AMD" [@ms-pluton-blog-2020]. The November 17, 2020 announcement that Pluton would ship on Windows PCs was not the introduction of a new design. It was a decision to apply a console design pattern to the general-purpose PC, with all the political and supply-chain consequences that come with that decision.

The prior article ended with three sets of broken engineering. A NZ$40 iCE40 FPGA on an LPC bus defeats discrete TPM in the time it takes a laptop to finish Trusted Boot [@andzakovic-2019-tpm-sniffing]. A network packet defeats Intel PTT through a 5-hour timing side channel against the ECDSA implementation in CSME [@tpmfail-microsite]. A few hours of physical access defeats AMD fTPM via a voltage glitch on the SVI2 power-management bus, walking out with the entire fTPM internal state [@jacob-2023-faultpm]. All three are documented in the prior article's section 5 and will not be re-derived here.

This article is what those three results forced into shape. Microsoft's reply is structural: move the TPM onto the SoC die so the bus disappears; run it on a dedicated TEE so a faulTPM-class glitch cannot drop everything; rewrite the firmware in a memory-safe language so the next decade of TPM-Fail-class CVEs has somewhere shorter to live; and route updates through Windows Update so the patch latency stops being measured in OEM-capsule quarters and starts being measured in Patch Tuesday weeks. Each design choice closes a specific 2014-2024 attack class. Each design choice also names a new trust. The bus is closed by trusting the silicon supply chain. The TEE is dedicated by trusting Microsoft's chip-level isolation. The firmware is memory-safe by trusting Microsoft's compiler and SDLC. The update path is fast by trusting Microsoft's signing key and Windows Update infrastructure. That is the article in five sentences.

The route from here is historical, then technical, then practical. Section 2 traces the design pattern from Xbox One (2013) through Project Sopris (2015), the Seven Properties of Highly Secure Devices paper (2017), Project Cerberus (2017), and Azure Sphere (2018). Section 3 shows why every other architectural option for "where the TPM lives" was systematically broken in public between 2019 and 2024. Section 4 walks the five generations of Microsoft security silicon side by side. Section 5 takes the four design choices in the November 17, 2020 announcement one at a time. Section 6 lists what is shipping in 2026, who has it on by default, and how to verify. Section 7 puts Pluton next to Apple's Secure Enclave Processor, Google's Titan M2 / OpenTitan, Caliptra, and the still-shipping Project Cerberus. Section 8 is what Pluton still cannot do, including the worked example of CVE-2025-2884. Section 9 is the open problems Pluton has named but not solved. Section 10 is the Monday-morning checklist. Section 11 is the FAQ and the closing.

Key idea: A single design pattern -- on-die security processor, Microsoft-signed firmware, online firmware updates -- migrating across product domains for thirteen years until it lands on the general-purpose PC. That migration is the subject of this article. Its cost is the subject of its closing.

gantt title Microsoft on-die security silicon 2013-2025 dateFormat YYYY-MM axisFormat %Y section Lineage Xbox One on-die security processor :2013-11, 2018-12 Project Sopris (Codename 4x4) :2015-01, 2017-04 Seven Properties paper (MSR-TR-2017-16) :2017-03, 2017-12 Project Cerberus (OCP) :2017-11, 2025-12 Azure Sphere (MT3620, Pluton MCU) :milestone, 2018-04, 1d section Pluton on PC November 17 2020 announcement :milestone, 2020-11, 1d AMD Ryzen 6000 first silicon :milestone, 2022-01, 1d Linux 6.3 tpm_crb merged :milestone, 2023-02, 1d Caliptra 1.0 (parallel path) :milestone, 2024-04, 1d Rust-based firmware foundation :2024-01, 2026-12 section Stress test CVE-2025-2884 (TCG ref code OOB) :milestone, 2025-06, 1d

Where did the design pattern come from, and why was it ready for the PC in 2020 and not earlier?

2. Origins -- Xbox One (2013), Sopris (2015), Seven Properties (2017), Cerberus (2017), Azure Sphere (2018)

The November 2020 announcement is retroactive. The design dates to Xbox One in 2013; the name "Pluton" first appears publicly in April 2018, in an Azure Blog post on the Azure Sphere MCU [@azure-blog-anatomy-secured-mcu]. The five-year gap is the architecture maturing from "console-only thing the SoC team built" to "thing Microsoft Research thinks every device should have."

2013 -- Xbox One

A console adversary has full physical access, unlimited time, and an economic incentive measured in hundreds of thousands of pirated units. Microsoft and AMD co-designed the Xbox One SoC with an on-die security subsystem, Microsoft-signed firmware, and a hardware-enforced separation between the Game OS and the System OS. The 2020 Pluton announcement [@ms-pluton-blog-2020] names the lineage explicitly. The architectural shape that the Pluton-on-PC program would later put under TCG TPM 2.0 wire compatibility was already running in production at consumer-console scale by 2014. The motivation matters because it is the only domain where Microsoft had hands-on experience deploying an on-die security processor against an adversary who owned the hardware. (Note: that the design was driven specifically by RGH-class console-modding adversaries is architectural inference, not a Microsoft statement.)

2015 -- Codename 4x4 / Project Sopris

In 2015, a small team in Microsoft AI+Research NExT, led by Galen Hunt, began exploring whether the same architectural shape could secure a $4 microcontroller [@msr-blog-azure-sphere]. The internal codename was Codename 4x4 -- a reference to the technical requirements that the chip would have at least 4 MB of RAM and 4 MB of Flash [@msr-blog-azure-sphere]. The Microsoft Research blog post is the surviving primary source on Sopris [@msr-blog-azure-sphere].The "Codename 4x4" name was internal team shorthand. Hunt's MSR Blog post records both the meaning and the constraint: "This was the origin of the project, internally called 'Codename 4x4', referring to the technical requirements that the chip will have at least 4 MB of RAM and 4 MB of Flash" [@msr-blog-azure-sphere]. The point was not the storage budget; the point was that a $4 MCU must afford the same architectural properties as a console SoC.

March 2017 -- Seven Properties of Highly Secure Devices

Hunt, George Letey, and Edmund Nightingale published The Seven Properties of Highly Secure Devices as Microsoft Research Technical Report MSR-TR-2017-16 in March 2017 [@msr-2017-seven-properties]. The paper makes a single normative claim: "This paper makes two contributions to the field of device security. First, we identify seven properties we assert are required in all highly secure devices" [@msr-2017-seven-properties]. The seven are: hardware-based root of trust, small trusted computing base, defense in depth, compartmentalisation, certificate-based authentication, renewable security, and failure reporting. Property #6 is the one the rest of this article turns on. Renewable security via online firmware updates is precisely the property that distinguishes Pluton-on-PC from a 2014 dTPM. The chip is allowed to be wrong, as long as the chip can be made right again, fast.

A 2017 Microsoft Research framework (Hunt, Letey, Nightingale; MSR-TR-2017-16) listing the architectural properties any "highly secure device" must satisfy: hardware-based root of trust, small TCB, defense in depth, compartmentalisation, certificate-based authentication, *renewable security via online updates*, and failure reporting [@msr-2017-seven-properties]. Renewable security is the property the Pluton-on-PC update path operationalises; it also names the new trust the program places in Microsoft.

November 9, 2017 -- Project Cerberus

Microsoft announced Project Cerberus at the OCP Summit on November 9, 2017 [@siliconangle-2017-cerberus]. Kushagra Vaid, then Microsoft Azure GM, described the architecture as "a cryptographic microcontroller running secure code which intercepts accesses from the host to flash over the SPI bus (where firmware is stored), so it can continuously measure and attest these accesses to ensure firmware integrity" [@siliconangle-2017-cerberus]. Microsoft contributed a five-PDF specification set to OCP under Project Olympus [@ocp-cerberus]: Architecture Overview, Challenge Protocol, Firmware Update, Host Processor Firmware Requirements, and Processor Cryptography. The reference implementation lives at Azure/Project-Cerberus on GitHub [@azure-cerberus-github] -- platform-agnostic core, FreeRTOS and Linux ports, "designed to be a hardware root of trust (RoT) for server platforms" [@azure-cerberus-github]. Microsoft Learn describes Cerberus as "a NIST 800-193 compliant hardware root-of-trust with an identity that cannot be cloned" [@ms-learn-cerberus] [@nist-sp-800-193]. This was Microsoft's first public commitment to publishing a hardware-RoT design and to running it in production at fleet scale.

Cerberus matters here for what it cannot do, not what it can. It is a discrete chip. It needs board area, a BOM line, and per-OEM design-in cost. It works on a $20,000 server motherboard. It does not work on a $700 ultrabook -- and putting it on one would reintroduce the very external-bus surface that Andzakovic 2019 showed to be sniffable [@andzakovic-2019-tpm-sniffing]. Cerberus solves the server problem definitively. It does not solve the PC problem, and its existence makes the PC-side need explicit.

April 16, 2018 -- Azure Sphere preview at RSA 2018

Hunt's announcement of Azure Sphere at the 2018 RSA Conference is the first public, named appearance of "Pluton." The Azure Blog launch post promised "custom silicon security technology from Microsoft, inspired by 15 years of experience and learnings from Xbox, to secure this new class of MCUs and the devices they power" [@azure-blog-2018-azure-sphere]. The companion Anatomy of a Secured MCU post is the first technical description: "our Pluton Security Subsystem is the heart of our security story" [@azure-blog-anatomy-secured-mcu]. Three components, one trust anchor: the MediaTek MT3620 MCU with the Pluton subsystem on die; the Microsoft-managed Linux-based Azure Sphere OS; and the Azure Sphere Security Service (AS3) cloud, which signed firmware updates and consumed device attestations. Wikipedia records the general-availability date as February 24, 2020 [@wikipedia-azure-sphere], also describing Pluton as "a Microsoft-designed security subsystem that implements a hardware-based root of trust for Azure Sphere" [@wikipedia-azure-sphere].

Each chip includes custom silicon security technology from Microsoft, inspired by 15 years of experience and learnings from Xbox, to secure this new class of MCUs and the devices they power. -- Galen Hunt, Azure Blog, April 16, 2018 [@azure-blog-2018-azure-sphere]

By April 2018, Microsoft had three architectural pieces in production. Xbox One proved the on-die security processor. Project Cerberus proved that Microsoft could publish an open RoT design and operate the back end at hyperscale. Azure Sphere proved that the Pluton block could be licensed onto a third-party SoC, attested to a Microsoft-operated cloud service, and serviced over the air. None of those three pieces was on a Windows PC.

flowchart LR Xbox[Xbox One 2013
on-die security processor
console form factor] Sopris[Project Sopris 2015
4 MB RAM + 4 MB Flash
research prototype] Seven[Seven Properties 2017
MSR-TR-2017-16
renewable security] Cerberus[Project Cerberus 2017
discrete RoT
server BMC] Sphere[Azure Sphere 2018
Pluton-on-MCU
MediaTek MT3620] PC[Pluton-on-PC 2020
general-purpose Windows PC] Xbox --> Seven Sopris --> Seven Seven --> Sphere Xbox --> Sphere Cerberus --> PC Sphere --> PC

Microsoft had a working architecture by 2018. Why did it take until November 17, 2020 to put it on a PC, and what changed between 2018 and 2020 that made the PC mandatory?

3. The threat model that closed every other door (2019-2024)

The answer to "what changed between 2018 and 2020" is that, between 2019 and 2024, every alternative architecture for where the TPM lives was systematically broken in public. Not by intention. By research. By the time Microsoft made the November 17, 2020 announcement, Pluton-on-PC was the only architectural option that simultaneously closed the bus, contained the TEE blast radius, and gave Microsoft a fast firmware-patch path. This section is the prior article's section 5, recast as the story Microsoft was watching unfold while the Pluton design was being prepared for PC.

March 13, 2019 -- Andzakovic's $40 LPC sniffer

Denis Andzakovic, working at Pulse Security, published an end-to-end attack on the Trusted Boot path of an HP business laptop [@andzakovic-2019-tpm-sniffing]. A NZ$40 iCE40 FPGA, seven wires (LFRAME, LAD0-LAD3, LCLK, GND) soldered to the LPC bus between the CPU and the discrete TPM, the BitLocker Volume Master Key falling off the wire in plaintext during boot. The prior article walks the bit-level details. What matters here is that the November 17, 2020 Pluton announcement names this attack class as motivation: "attackers have begun to innovate ways to attack [the TPM], particularly in situations where an attacker can ... gain physical access to a PC ... target[ing] the communication channel between the CPU and TPM" [@ms-pluton-blog-2020]. Discrete TPM as a class is broken against a determined adversary with physical access. The bus is the surface.

November 12, 2019 -- TPM-Fail

Daniel Moghimi and colleagues published TPM-Fail later in 2019 [@tpmfail-microsite]: timing side channels in the ECDSA implementation in Intel PTT (CVE-2019-11090) and the STMicro ST33 dTPM (CVE-2019-16863). Local key recovery in 4-20 minutes; remote, over the network, in approximately 5 hours. The fixes shipped as firmware patches. The lesson Microsoft took from TPM-Fail is not in the bug, it is in the deploy mechanism. PTT lives in CSME; CSME ships through the OEM's UEFI capsule path. ST33 lives behind the TPM vendor's signed flash and ships through the OEM's UEFI capsule path. The OEM UEFI capsule path is measured in quarters to years for high-volume client OEMs. A fix existed but the deploy mechanism was insufficient. This is the architectural lesson that the next generation has to internalise: the patch path is part of the security property.The deploy-mechanism lesson is the one that gets quietly swallowed into Pluton's design. The bug count in firmware-TPM territory is not zero; it is steady. What changes is whether a fix can reach the fleet before its dwell time becomes a procurement problem. TPM-Fail's structural lesson is therefore not "ECDSA timing leaks" -- it is "the channel that delivers the fix is the security property that matters."

April 28, 2023 -- faulTPM

Hans Niklas Jacob, Christian Werling, Robert Buhren, and Jean-Pierre Seifert published faulTPM: Exposing AMD fTPMs Deepest Secrets at IEEE EuroS&P 2023 [@jacob-2023-faultpm]. "In this paper, we analyze a new class of attacks against fTPMs: Attacking their Trusted Execution Environment can lead to a full TPM state compromise. We experimentally verify this attack by compromising the AMD Secure Processor" [@jacob-2023-faultpm]. The mechanism: a voltage glitch on the SVI2 power-management bus, against the AMD PSP (an ARM TrustZone Cortex-A5 inside modern Ryzen SoCs [@wikipedia-amd-psp]), in 2-3 hours of physical access. The output: the entire fTPM internal state, including the EK and any sealed material.

The structural failure in faulTPM is not the glitch. It is that the PSP is a shared TEE. The same coprocessor that runs the fTPM service also runs SEV memory-encryption setup, secure-boot enforcement, and platform initialisation. One fault drops everything. Shared-TEE fTPM is broken because the TEE is shared. The architectural conclusion that this forces is hard: a fTPM that lives next to memory-encryption services, alongside boot-policy enforcement, in a coprocessor that also handles fuse provisioning, is not separable in failure. To restore TEE isolation, you need a dedicated TEE.

The architecture cascade

Three results in five years close every architectural option Microsoft had on the PC.

Realization	Structural failure	First public proof	What survives the failure
Discrete TPM (LPC / SPI)	External bus is sniffable	Andzakovic 2019 [@andzakovic-2019-tpm-sniffing]	Hardened dTPM with encrypted bus (TPM 2.0 ENC sessions); not retrofittable to existing fleets
Intel PTT in CSME	Slow OEM UEFI capsule patch path	TPM-Fail 2019 [@tpmfail-microsite]	The cryptographic primitive; not the deploy channel
AMD fTPM in PSP	Shared TEE -- one fault drops everything	faulTPM 2023 [@jacob-2023-faultpm]	The compatibility surface; not the secrets the chip held
Pluton on the SoC die	(subject of sections 5-8)	--	--

The reasoning chain that lands the design is short. dTPM is broken because the bus is sniffable. Shared-TEE fTPM is broken because the TEE is shared. Therefore: dedicated TEE on the SoC die, with a deploy channel that is not the OEM UEFI capsule. That is Pluton-on-PC. On-die is not a Microsoft engineering preference. It is the only shape left after every other architecture has been broken in public.

flowchart TD dTPM[Discrete TPM
external LPC/SPI bus] PTT[Intel PTT
fTPM inside CSME] fTPM[AMD fTPM
fTPM inside PSP] AND[Andzakovic 2019
\$40 FPGA bus sniff] TF[TPM-Fail 2019
5-hour ECDSA recovery] FT[faulTPM 2023
SVI2 voltage glitch] Forced[On-die dedicated TEE
OS-channel update path
= Pluton-on-PC] dTPM --> AND PTT --> TF fTPM --> FT AND --> Forced TF --> Forced FT --> Forced

Note: By 2024, all three production options for the TPM realization had been defeated by public research. dTPM by the bus surface (Andzakovic 2019). Intel PTT by the patch latency of CSME (TPM-Fail 2019). AMD fTPM by the shared-TEE blast radius (faulTPM 2023). On-die is not an aesthetic choice; it is the only architectural shape left after every other option has been demonstrably broken. The "Pluton design" is the negative space these three results leave behind.

If Microsoft had a working on-die-RoT architecture as early as 2013, and the threat model demanded it on PC by 2020, why did Microsoft go through Cerberus and Azure Sphere first? What did each generation contribute that the previous one could not?

4. Five generations of Microsoft security silicon

Microsoft's path to Pluton-on-PC was not linear. The architecture took shape across five generations of Microsoft security silicon -- three direct predecessors, the PC deployment itself, and one parallel path. Each generation contributed a piece the next one needed. The shape of Pluton-on-PC was determined by what Xbox One was, what Cerberus could not be on a client, what Azure Sphere proved at scale, and what Caliptra would later make visible as a choice rather than a technical necessity.

Note: This article counts Microsoft on-die security-silicon programs (Generations 3-7 = Xbox One, Cerberus, Azure Sphere Pluton, Pluton-on-PC, Caliptra). The prior article counts TPM realisations (Generations 1-3 = standalone hardware TPM, firmware TPM, on-die TPM) [@prior-tpm-in-windows]. The two schemes share an index space but count different things. Project Cerberus appears as Generation 4 here even though it is discrete (not on-die), because the count is over Microsoft security-silicon programs, not over TPM realisations.

A hardware element that anchors three separable services: Root of Trust for Storage (the chip can hold private keys that never leave it), Root of Trust for Reporting (the chip can sign attestations of its own state and of code it measured), and Root of Trust for Measurement (the chip records integrity hashes of code as it loads). The TPM 2.0 specification names all three; Pluton, Apple SEP, Caliptra, and OpenTitan implement subsets and combinations of them.

Generation 3 -- Xbox One on-die security processor (2013)

Existence proof. Microsoft and AMD co-designed the Xbox One SoC with an on-die security subsystem [@ms-pluton-blog-2020]. Console signing key. Hardware-enforced separation between Game OS and System OS. The Xbox One demonstrated, at consumer-console scale, that Microsoft and a chip vendor could ship an on-die security processor that survived a determined adversary with full physical access. Limitation: console-only. No TCG TPM 2.0 wire surface. Microsoft did not commit publicly that this design would ever leave the Xbox.

Generation 4 -- Project Cerberus (November 9, 2017)

Discrete RoT chip on the server BMC. NIST SP 800-193 alignment [@ms-learn-cerberus] [@nist-sp-800-193]. Open spec at OCP [@ocp-cerberus]; reference implementation on GitHub [@azure-cerberus-github]. Architecturally the inverse of Pluton: external chip, separate flash interception, dedicated authority. That shape is right for a server motherboard. That shape is wrong for a $700 ultrabook -- BOM cost, board area, and per-OEM design-in cost rule it out, and reintroducing an external bus would re-expose the very Andzakovic-class surface the program is trying to close. Cerberus is not a rejected design; it is the server-side answer that runs alongside the client-side answer Pluton would later be. The two coexist in the November 17, 2020 announcement, which describes Cerberus as "providing a secure identity for the CPU that can be attested by Cerberus" [@ms-pluton-blog-2020]. Server-side RoT and client-side RoT compose; they do not compete.

Generation 5 -- Azure Sphere Pluton MCU (April 2018)

The first public, named appearance of "Pluton." MediaTek MT3620 SoC; Linux-based MCU OS; Azure Sphere Security Service in the cloud [@azure-blog-2018-azure-sphere] [@azure-blog-anatomy-secured-mcu]. "Our Pluton Security Subsystem is the heart of our security story" [@azure-blog-anatomy-secured-mcu]. Three things became operationally proven in this generation. First, Microsoft-designed on-die security IP could be licensed to a third-party SoC and taped out under another vendor's process. Second, Microsoft-operated cloud-side firmware servicing was viable at MCU scale. Third, the Seven Properties mapped cleanly onto the silicon-plus-firmware-plus-cloud triple. Limitation: MCU-class power and instruction set; not Windows; product retiring in 2027.The precision matters. The design pattern -- on-die security processor, Microsoft-signed firmware, cloud or OS-channel updates -- dates to Xbox One in 2013. The name "Pluton" first appears publicly in the April 2018 Anatomy of a Secured MCU Azure Blog post [@azure-blog-anatomy-secured-mcu]. The 2020 PC announcement uses the name retroactively for the 2013 design. When narrating: the design is Xbox-era, the name is Azure-Sphere-era.

Generation 6 -- Pluton on Windows-PC SoCs (November 17, 2020)

The subject of section 5. Brief hand-off here. Microsoft, AMD, Intel, and Qualcomm announced that the Pluton design would ship on Windows-PC SoCs [@ms-pluton-blog-2020]. AMD Ryzen 6000 was the first silicon to actually ship, at CES 2022 [@phoronix-2022-amd-ryzen-pluton]. Microsoft Learn currently lists AMD Ryzen 6000 / 7000 / 8000 / 9000 / Ryzen AI; Intel Core Ultra 200V Series, Ultra Series 3, and Series 3; and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series [@ms-learn-pluton]. This is the generation the rest of the article lives in.

Generation 7 -- Caliptra 1.0 (April 2024)

Open-source datacenter Root of Trust. Co-designed by Microsoft, Google, AMD, and NVIDIA. Specification, RTL, ROM, and runtime all public on CHIPS Alliance [@caliptra-github] [@caliptra-spec]. "Caliptra targets datacenter-class SoCs like CPUs, GPUs, DPUs, TPUs. It is the specification, silicon logic, ROM and firmware for implementing a Root of Trust for Measurement (RTM) block inside an SoC" [@caliptra-github]. Caliptra is not a successor to Pluton. It is a parallel path, and that distinction is what makes Caliptra structurally important for this article: it makes the single-signer choice in Pluton visible as a choice, not a technical necessity. Caliptra exists. The single-signer property of Pluton-on-PC is therefore not the only design that 2024 hardware can support; it is the one Microsoft chose for the client.

The five generations side by side:

Generation	Year	On-die?	Discrete?	Open RTL?	Multi-signer?	Trust anchor	Where it ships
3 -- Xbox One sec proc	2013	Yes	No	No	No	Microsoft (Xbox CA)	Xbox One console
4 -- Project Cerberus	2017	No	Yes	Yes (spec/RI)	No (per-deployment signer)	Microsoft Azure CA (operator)	Server BMC
5 -- Azure Sphere Pluton	2018	Yes	No	No	No	Microsoft (AS3)	MCU (MediaTek MT3620)
6 -- Pluton-on-PC	2020	Yes	No	No	No	Microsoft (Windows Update)	Windows 11 client SoCs
7 -- Caliptra 1.0	2024	Yes	No	Yes	Multi-vendor by deployment	Per-chip integrator	Datacenter SoCs

flowchart TD Gen3[Gen 3: Xbox One 2013
existence proof at scale] Gen4[Gen 4: Cerberus 2017
open spec + NIST 800-193] Gen5[Gen 5: Azure Sphere 2018
Pluton-on-MCU + cloud servicing] Gen6[Gen 6: Pluton-on-PC 2020
TCG TPM 2.0 surface + Windows Update] Gen7[Gen 7: Caliptra 2024
open-source datacenter RoT] Gen3 -->|console-only existence| Gen5 Gen3 -->|client-side
architecture| Gen6 Gen4 -->|server-side
composes with Gen 6| Gen6 Gen4 -->|open governance
refined into| Gen7 Gen5 -->|MCU-scale to PC-scale| Gen6 Gen6 -.parallel path.-> Gen7

What, exactly, makes Generation 6 different from the four generations that came before it -- and what new trust does each of its design choices ask the reader to place in Microsoft?

5. The breakthrough -- on-die plus dedicated TEE plus Rust plus Windows Update

The November 17, 2020 announcement [@ms-pluton-blog-2020] is shorter than its consequences suggest. It makes four design choices explicit. Each one closes a specific architectural gap that 2014-2024 had opened. Each one also names a new trust that is now placed in Microsoft. This section walks the four choices, the gap each one closes, and the trust each one creates.

Design choice 1 -- on-die SoC integration

There is no off-package bus between the CPU and the Pluton block. The November 2020 announcement names this property as the structural answer to the bus-sniffing class: "attackers have begun to innovate ways to attack [the TPM], particularly in situations where an attacker can ... gain physical access to a PC ... target[ing] the communication channel between the CPU and TPM" [@ms-pluton-blog-2020]. With Pluton, that communication channel is silicon, not a board trace. Andzakovic-class attacks have nothing to attack [@andzakovic-2019-tpm-sniffing].

The new trust: the silicon supply chain. Microsoft licenses the IP block; AMD, Intel, and Qualcomm tape it out on TSMC or another foundry; the OEM integrates the resulting SoC into a finished product. None of those steps is on the public record at the bit level. (See open problem 5 in section 9 -- supply-chain integrity beyond firmware signing.)

Design choice 2 -- dedicated TEE, not shared

Pluton is not the same coprocessor that runs SEV memory encryption (AMD) or CSME runtime services (Intel). It is a separate block on the SoC die, with its own ROM, its own firmware, and its own boundary. faulTPM-class attacks on the AMD PSP do not transitively drop Pluton secrets [@jacob-2023-faultpm], because Pluton is not running inside the PSP. The structural failure that defeated AMD fTPM -- one fault drops everything because the TEE is shared -- does not apply to Pluton-as-Pluton. (AMD-Ryzen-6000-class chips can ship Pluton silicon next to the existing PSP-based fTPM; the OEM picks which the host advertises as the system TPM via the Pluton (HSP) BIOS toggle and PSP-directory 0xB BIT36 soft fuse Garrett 2022 documents [@garrett-2022-pluton-rev]. Windows TBS exposes one TPM at a time. On systems the OEM exposes as fTPM, faulTPM-class attacks remain valid; on systems exposed as Pluton-as-TPM they no longer reach the chip's secret state.)

The new trust: Microsoft's chip-level isolation engineering. The TEE is dedicated only because Microsoft and the chip vendor agreed to dedicate it. There is no public peer-reviewed audit demonstrating that the Pluton boundary is bit-for-bit non-shared with PSP / CSME on shipping silicon. The independent CHES 2024 study TPMScan [@tpmscan-2024] [@tpmscan-iacr] sampled 78 TPM 2.0 versions across 6 vendors, and the IACR TCHES record states explicitly that the corpus "include[s] recent Pluton-based iTPMs" alongside dTPM, fTPM, and earlier iTPM variants from Microsoft, AMD, Intel, Infineon, ST, and Nuvoton [@tpmscan-iacr]. The paper's per-vendor findings centre on RSA / ECDSA nonce-leakage and command-timing observability across the corpus; the paper does not single Pluton out for a per-implementation audit, and it does not characterise Pluton's specific timing surface as worse or better than the iTPM cohort it sits in. The TPMScan study therefore places Pluton inside the audited iTPM population without singling it out -- a useful baseline, not a Pluton-specific clean bill of health.

Design choice 3 -- Microsoft-authored Rust firmware

Microsoft Learn states it explicitly: "Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation given the importance of memory safety" [@ms-learn-pluton]. Memory-safe firmware is a direct response to the firmware-CVE history -- TPM-Fail [@tpmfail-microsite], the long Intel ME / AMD PSP CVE backlog, and CVE-2025-2884 (worked example in section 8 below). The class of bug that a memory-safe runtime structurally rules out is large; it is not the entirety of the bug surface (logic bugs survive Rust), but it is the part that has driven the CVE economy in firmware-TPM territory for a decade.

Microsoft Learn commits to *"a Rust-based firmware foundation"* on 2024+ AMD and Intel platforms [@ms-learn-pluton]. Secondary technology press has named the runtime as Tock OS, the memory-safe embedded operating system maintained by an open community [@tock-github]. Tock is a plausible candidate -- it is the most mature publicly reviewed memory-safe embedded RTOS for the kind of constraints Pluton operates under. But Microsoft has not made the Tock attribution publicly. The honest reading is: Rust on the PC firmware path is committed; the specific runtime has not been named by Microsoft as of 2026. The reader who wants to track this should watch the Microsoft Learn Pluton page for an explicit runtime name.

The reason this hedge matters: "Pluton runs Tock" is widely repeated in tech press, and the difference between "memory-safe Rust embedded OS" and "specifically Tock" is the difference between an architectural commitment and a procurement choice. Both are interesting, but they are not the same statement.

Garrett's April 2022 reverse-engineering [@garrett-2022-pluton-rev] documented that the Pluton firmware blob on the 2022 AMD Ryzen 6000 BIOS he disassembled was an ARM image derived from the TCG TPM 2.0 reference code (section 6 carries the verbatim quote and section 8 carries the CVE-2025-2884 connection). That is the 2022 firmware on a 2022-vintage chip; it is not the 2024+ Rust runtime. Both observations are consistent: the 2022 ARM blob is what existed on the first silicon, and the 2024+ Rust runtime is what Microsoft Learn now commits to. CVE-2025-2884 (section 8) reaches this firmware exactly through the TPM 2.0 reference-code derivation Garrett identified.

The new trust: Microsoft's compiler and SDLC. The chip ships running code that Microsoft authored. Whatever the compiler optimised away, whatever the test suite did not catch, whatever subtle un-unsafe-block reasoning passed code review -- that becomes the property of the chip's trust anchor.

Design choice 4 -- Windows Update servicing path

Microsoft Learn: "Pluton platform supports loading new firmware delivered through operating system updates" [@ms-learn-pluton]. The change in shape is this: from quarters-to-years (the OEM UEFI capsule rollout that TPM-Fail had to crawl through) to days-to-weeks (the Patch Tuesday cadence that already delivers Windows kernel updates to roughly 1.4 billion endpoints, the deployment scale Microsoft itself reports for Windows monthly active devices). Microsoft has not published a numerical SLA for Pluton firmware delivery; this article will not assert one. The change in channel is the architectural fact.

The new trust: Microsoft's signing key and Windows Update infrastructure. Whoever can sign for the Windows Update channel can, in principle, push firmware to every Pluton chip the channel reaches. This is the same trust that already underwrites the rest of Windows; Pluton extends it to the chip itself.

The trust shift, named explicitly

Pull the four choices together. Each closes a specific 2014-2024 attack class -- bus, shared-TEE, firmware-CVE, OEM-capsule patch latency. Each names a new trust placed in Microsoft -- silicon supply chain, chip-level isolation engineering, compiler and SDLC, signing key and Windows Update infrastructure. On-die alone is not the breakthrough. The breakthrough is the combination.

The November 2020 announcement also commits to a property beyond TCG TPM 2.0: SHACK. "Pluton also provides the unique Secure Hardware Cryptography Key (SHACK) technology that helps ensure keys are never exposed outside of the protected hardware, even to the Pluton firmware itself" [@ms-pluton-blog-2020]. The TCG TPM 2.0 specification requires that keys be non-exportable from the chip; SHACK extends the boundary one ring inward, naming a class of keys that the firmware running on Pluton itself cannot read. This is Microsoft's claim that Pluton offers a stronger property than the TCG TPM 2.0 spec requires. Verifying that claim from outside Microsoft requires source access Microsoft has not published.

A Pluton property named in the November 17, 2020 announcement [@ms-pluton-blog-2020]; Microsoft's claim that Pluton's non-exportability boundary extends one ring inside the TCG TPM 2.0 boundary, so keys are unreadable even by Pluton firmware. See the §5 prose paragraph above for the verbatim Microsoft quote and the article's hedge that no external peer-reviewed validation of SHACK exists as of 2026.

How the chip boots and how the chip gets patched

The boot-and-attest sequence below is the public shape of how Pluton starts and how new firmware reaches it. The exact ROM-to-FMC-to-runtime chain is generic to on-die RoT designs (Caliptra exposes this shape openly in its source [@caliptra-github]); Pluton's specific protocol details are not all on the public record, so the diagram captures the architectural shape rather than a Microsoft-internal protocol.

sequenceDiagram participant SoC as SoC reset participant ROM as Pluton ROM participant FMC as Pluton FMC participant RT as Pluton runtime participant Win as Windows + WU SoC->>ROM: power-on, Pluton enters ROM ROM->>ROM: verify FMC signature against on-die public key ROM->>FMC: hand off after measurement FMC->>FMC: verify runtime signature FMC->>RT: hand off, runtime exposes TPM 2.0 CRB RT-->>Win: TPM 2.0 commands over CRB Win->>Win: Patch Tuesday delivers signed Pluton blob Win->>RT: stage new firmware via OS update channel RT->>FMC: queue new runtime, reboot to apply FMC->>FMC: verify new runtime signature, commit

The detection logic that follows is the structural shape of the Get-Tpm PowerShell query that section 10 will revisit. It is mocked here to make the four-letter MSFT check explicit.

{// Mock of the Windows TPM Base Services (TBS) manufacturer query. // Real Get-Tpm reads ManufacturerIdTxt from the TPM 2.0 capability // response and matches the four-character ASCII manufacturer. const manufacturers = { 'MSFT': 'Microsoft Pluton', 'INTC': 'Intel PTT (firmware TPM in CSME)', 'AMD ': 'AMD fTPM (firmware TPM in PSP)', 'IFX': 'Infineon discrete TPM', 'STM': 'STMicro discrete TPM', 'NTC': 'Nuvoton discrete TPM', }; function classify(mfr) { return manufacturers[mfr] || 'Unknown / non-TCG TPM'; } console.log('MSFT =>', classify('MSFT')); console.log('INTC =>', classify('INTC')); console.log('AMD =>', classify('AMD ')); console.log('IFX =>', classify('IFX'));}

Key idea: The Pluton breakthrough is the combination, not on-die alone. On-die plus dedicated TEE plus memory-safe firmware plus OS-channel updates -- four design choices, each closing a different 2014-2024 attack class, each placing a new trust in Microsoft. The chip is the cheapest part of the system. The cost is what those four trusts add up to.

What is actually shipping in 2026? Hardware lists, default-on / default-off behavior, vendor pushback that survived from 2022 into 2026 -- the gap between marketing claim and shipping reality.

6. Pluton in 2026 -- what is shipping, where, and how to verify

The 2020 announcement is now five and a half years old. The 2022 first-silicon shipment is four. What is the actual fleet shape in 2026?

The Microsoft-published hardware list

The current Microsoft Learn Pluton page enumerates the supported silicon: AMD Ryzen 6000, 7000, 8000, 9000, and Ryzen AI; Intel Core Ultra 200V Series, Ultra Series 3, and Series 3; and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series [@ms-learn-pluton]. Every chip on that list ships with Pluton silicon present on the die. Present and enabled by default are not the same property, which is the point of the next subsection.

Default-on versus default-off varies by OEM SKU

The first x86 silicon to ship with Pluton was AMD Ryzen 6000 "Rembrandt", at CES 2022. Phoronix's launch coverage [@phoronix-2022-amd-ryzen-pluton] confirms that the CES 2022 keynote disclosed the integration. The vendor responses that followed in March 2022 set the OEM-by-OEM posture that the fleet still reflects in 2026. The Register obtained vendor statements [@register-2022-pluton]. Lenovo deployed the chip on AMD Ryzen 6000 ThinkPads but disabled it: "AMD Ryzen 6000 ThinkPads will include Pluton as it's present in those AMD chips, though the feature will be disabled by default"; Intel-powered ThinkPads "will not support Microsoft Pluton at launch"; the Snapdragon 8cx Gen 3 Lenovo X13s did include Pluton [@register-2022-pluton]. Dell's reply was the most direct: "Pluton does not align with Dell's approach to hardware security and our most secure commercial PC requirements" [@register-2022-pluton] [@pcworld-2022-pluton]. HP declined to comment.

The 2024 inflection is the Copilot+ PC program. Microsoft Surface and Qualcomm Snapdragon X Elite / Snapdragon X Series Copilot+ devices ship Pluton enabled by default [@ms-learn-pluton]. This is the first product class where retail-bought Windows 11 hardware turns Pluton on at the factory.The 2024 Copilot+ inflection is the first time a high-volume consumer Windows-PC SKU ships Pluton on by default. Prior to Copilot+, Pluton was either off (Lenovo AMD Ryzen 6000 ThinkPads), absent (Dell), or behind a BIOS toggle the user had to find. Copilot+ collapses the discoverability problem because Windows 11 itself depends on the secure-boot and credential-protection primitives that Pluton hosts when the OEM has enabled it.

Linux 6.3 -- February 20, 2023

The standard TCG Command Response Buffer (CRB) interface that Pluton exposes is reachable from Linux. Phoronix records the merge: "Linus Torvalds merged to Linux 6.3 Git the TPM CRB support for Microsoft's controversial Pluton security co-processor" [@phoronix-2023-pluton-linux63] [@kernel-org-pluton-merge]. The driver author was Matthew Garrett [@kernel-org-pluton-merge]. Pluton-as-TPM is now reachable from non-Windows operating systems via the standard TCG CRB transport. This constrains -- although it does not eliminate -- the "Microsoft-only black box" narrative. The chip speaks the open TCG wire protocol that any operating system can talk to.

Garrett's reverse-engineering -- April 2022

Matthew Garrett's April 2022 disassembly of the Asus ROG Zephyrus G14 BIOS [@garrett-2022-pluton-rev] yielded two facts that matter for the rest of this article. First, the user-controllable BIOS Pluton (HSP) toggle on AMD Ryzen 6000 may not be a hardware power-down. Garrett's reading: "PSP directory entry 0xB BIT36 ... if bit 36 is set, the PSP tells Pluton to turn itself off and will no longer send any commands to it" [@garrett-2022-pluton-rev]. The toggle is a soft fuse. Inventory queries that report "Pluton present" do not always distinguish enabled from soft-disabled. Second, "there's a blob starting at 0x0069b610 that appears to be firmware for Pluton -- it contains chunks that appear to be the reference TPM2 implementation, and it broadly decompiles as valid ARM code" [@garrett-2022-pluton-rev]. The Pluton firmware blob is, on the silicon Garrett looked at, an ARM image derived from the TCG TPM 2.0 reference code. That is the observation that makes CVE-2025-2884 (section 8) reachable inside Pluton firmware too.

On AMD Ryzen 6000 / 7000 / 8000 platforms, the OEM can set PSP directory entry 0xB bit 36 in the AMD-firmware part of the BIOS to instruct the PSP to *"tell Pluton to turn itself off"* [@garrett-2022-pluton-rev]. This is a soft fuse, not a hardware power-down. The host's TPM advertisement (`Get-Tpm`) does not always distinguish enabled-Pluton from soft-disabled-Pluton; verification requires inspecting the BIOS-level Pluton (HSP) toggle directly, or correlating against the Plug-and-Play device list.

Note: Garrett's PSP-directory soft-fuse documentation [@garrett-2022-pluton-rev] is the practical pitfall of any 2026 Pluton procurement audit. An OEM can ship AMD Ryzen 6000 / 7000 / 8000 silicon with Pluton soft-disabled at boot. Inventory queries that count "Pluton-present" SKUs without correlating against the BIOS-level Pluton (HSP) toggle will overcount by an unknown margin. Section 10 walks the practical detection path.

The fleet shape, in one comparison table:

Platform	First shipped	Default state at launch	Vendor posture today	Linux support
AMD Ryzen 6000 mobile	January 2022 [@phoronix-2022-amd-ryzen-pluton]	Off on Lenovo ThinkPad [@register-2022-pluton]; Dell declined [@pcworld-2022-pluton]	Per-OEM; soft-fuse trap on Lenovo	Linux 6.3 CRB driver [@phoronix-2023-pluton-linux63]
AMD Ryzen 7000 / 8000 / 9000 / Ryzen AI	2023-2025	Per-OEM SKU	Microsoft Learn lists as supported [@ms-learn-pluton]	Same CRB driver
Intel Core Ultra 200V / Series 3	2024-2025	Per-OEM SKU	Microsoft Learn lists as supported [@ms-learn-pluton]	Same CRB driver
Snapdragon 8cx Gen 3 (Lenovo X13s)	2022	On at launch [@register-2022-pluton]	Shipping	Same CRB driver
Snapdragon X Series Copilot+ PCs	2024	On by default [@ms-learn-pluton]	Microsoft + Qualcomm core program	Same CRB driver
Microsoft Surface Copilot+	2024	On by default [@ms-learn-pluton]	First-party Microsoft hardware	Same CRB driver

flowchart LR AMD[AMD Ryzen 6000-9000
+ Ryzen AI] Intel[Intel Core Ultra 200V
Series 3] Qualcomm[Qualcomm Snapdragon
8cx Gen 3 + X Series] Lenovo[Lenovo
ThinkPad / X13s] Dell[Dell
commercial] HP[HP
commercial] Surface[Microsoft Surface
Copilot+] OEMx[Snapdragon X
Copilot+ OEMs] Off[Default off
at launch] Vendor[Vendor declined
to ship] On[Default on
at retail] AMD --> Lenovo AMD --> Dell AMD --> HP Intel --> Lenovo Qualcomm --> Lenovo Qualcomm --> Surface Qualcomm --> OEMx Lenovo -->|2022 Ryzen 6000| Off Dell -->|"does not align"| Vendor HP -->|declined comment| Vendor Lenovo -->|X13s 8cx Gen 3| On Surface --> On OEMx --> On

The detection logic for the Garrett soft-fuse trap, mocked here so the structural shape is explicit:

{// Mock of the PSP directory entry 0xB inspection that Garrett 2022 // documented. Real verification reads the AMD-firmware bytes off the // SPI flash; this demonstrates the bit-36 check that decides // "enabled" vs "soft-disabled". function plutonState(plutonPresent, pspDir0xB_BIT36) { if (!plutonPresent) return 'absent'; if (pspDir0xB_BIT36 === 1) return 'soft-disabled'; // PSP told to silence Pluton return 'enabled'; } console.log('Pluton present, BIT36=0 =>', plutonState(true, 0)); console.log('Pluton present, BIT36=1 =>', plutonState(true, 1)); console.log('No Pluton silicon =>', plutonState(false, 0));}

Pluton is not the only on-die security processor in 2026. Apple has the Secure Enclave Processor. Google has Titan M2. The OCP coalition has Caliptra. How does Pluton compare, and what does the comparison reveal about Microsoft's design choices?

7. Competing approaches -- Apple SEP, Google Titan M2, OpenTitan, Caliptra, Cerberus

Pluton is not alone. The platforms below are its nearest analogues -- the strongest evidence that Microsoft's design choices were choices, not technical necessities.

Apple Secure Enclave Processor

Apple's Apple Platform Security documentation describes SEP as "a dedicated secure subsystem integrated into Apple [SoC] ... isolated from the main processor to provide an extra layer of security" [@apple-sep]. By deployment count it is the most mature single-vendor on-die security processor on the planet -- shipping in every iPhone since the iPhone 5s (2013), every iPad since iPad Air, and every Apple-silicon Mac [@apple-sep] [@wikipedia-apple-silicon]. The architecture has matured generation by generation: a Boot ROM as the hardware root of trust; an Apple-customised L4 microkernel; a Memory Protection Engine that combines AES-XEX with CMAC and an anti-replay tree on A11 / S4 and later; a Boot Monitor on A13 and later that hashes the loaded image and updates the SCIP (System Coprocessor Integrity Protection) settings before transferring control; and on A14 / M1 and later, the Memory Protection Engine "supports two ephemeral memory protection keys" -- one for SEP-private data and a second one shared with the Secure Neural Engine [@apple-sep].

The trade-off versus Pluton is not the architecture -- it is the governance model. Apple owns the silicon, the operating system, the signing key, and the device. The multi-signer political question never arises because there is only one signer for every layer of the stack. The cost: complete lock-in. The Apple T2 line, which shipped in 2017-2020 Intel Macs as a discrete A10-derived security chip running bridgeOS, inherited the A10 Boot ROM [@wikipedia-apple-t2]. The A10 Boot ROM has the structurally important property that no Boot-ROM-resident bug can be patched without silicon respin -- which the checkm8 / blackbird class of jailbreaks demonstrated end-to-end. T2 was discontinued June 5, 2023 [@wikipedia-apple-t2]. The lesson is direct: renewable security (Seven Properties #6) is not optional. Even Apple's vertically integrated stack pays the price when a generation ships without it.

A dedicated secure subsystem integrated into Apple [SoC] ... isolated from the main processor to provide an extra layer of security. -- Apple, *Apple Platform Security* [@apple-sep]

Google Titan M / Titan M2 and OpenTitan

Google announced Titan M with the Pixel 3 launch in October 2018 [@pixel-3-titan-m]: "This year, with Pixel 3, we're advancing our investment in secure hardware with Titan M, an enterprise-grade security chip custom built for Pixel 3..." [@pixel-3-titan-m]. Titan M2 followed with Pixel 6 in October 2021 [@pixel-6-titan-m2]. Both are discrete or in-package security chips on Pixel for Android Verified Boot, StrongBox-grade key storage, anti-rollback, and lock-screen verification. Both are Google-vertical: Google designs the chip, Google operates the cloud back end, Google ships the OS.

OpenTitan is the open-source descendant. Hosted by lowRISC, it is "the first open source project building a transparent, high-quality reference design and integration guidelines for silicon root of trust (RoT) chips" [@opentitan-home]. RISC-V Ibex core; hardware AES, HMAC, KMAC, and OTBN big-number engines; full RTL, ROM, and verification stack public; Apache 2.0 license. OpenTitan reached commercial availability on February 13, 2024 [@opentitan-commercial] -- the first open-source silicon project to do so. The press release names the nine coalition members verbatim: "Google, Winbond, Nuvoton, zeroRISC, Rivos, Western Digital, Seagate, ETH Zurich and Giesecke+Devrient, hosted by the non-profit lowRISC CIC" [@opentitan-commercial]. OpenTitan is the closest existing answer to "what would an open-source Pluton look like?" -- but as of 2026 it is discrete or in-package, not on-die in an application SoC.The lowRISC press release is precise on a point that secondary press has frequently flubbed. lowRISC is the host organisation for OpenTitan; it is not a member of the nine. The nine commercially announced coalition members on February 13, 2024 are Google, Winbond, Nuvoton, zeroRISC, Rivos, Western Digital, Seagate, ETH Zurich, and Giesecke+Devrient [@opentitan-commercial]. The distinction matters because lowRISC's role is governance, not deployment.

Caliptra

The OCP coalition's open-source datacenter Root of Trust. Specification, RTL, ROM, FMC, and runtime are public on CHIPS Alliance [@caliptra-github] [@caliptra-spec]. Founders: Microsoft, Google, AMD, NVIDIA. Google Cloud's Caliptra-1.0 announcement reports: "the Caliptra specification and open-source hardware and software implementation is complete, reaching the revision 1.0 milestone." The Google Cloud post adds that the Caliptra IP block is being integrated by member companies into chips expected in the market in 2026. Caliptra targets "datacenter-class SoCs like CPUs, GPUs, DPUs, TPUs" [@caliptra-github]. It is not a Pluton substitute on Windows clients -- the form factor is different and the threat model assumes server-side operators.

The instinct, on reading that Caliptra is open-source and multi-vendor, is to ask why Microsoft does not just put Caliptra into the next Surface. Three reasons. First, form factor: Caliptra is a datacenter-SoC IP block; the integration target is a CPU / GPU / DPU / TPU package on a \$20,000 server motherboard, not a \$700 ultrabook. Second, signer model: Caliptra is multi-vendor *by deployment*, but each Caliptra-equipped chip still has *one* signer -- the integrating chip vendor (AMD signs AMD's Caliptra firmware; NVIDIA signs NVIDIA's). The choice of signer moved; the count of signers per chip did not. Third, threat model: Caliptra's RTM serves a server attestation flow ending at a fleet operator (Google, Microsoft, NVIDIA, the rack owner), not a client BitLocker flow that has to survive a powered-off laptop on an airport conveyor belt.

Caliptra is the right counter-design to the governance of Pluton, not its form factor. It is what makes the single-signer-per-chip choice in Pluton-on-PC visible as a choice, not a technical necessity. That visibility is the whole reason this section exists.

Project Cerberus -- still in production

Cerberus has not been retired. Microsoft Learn describes it as "a NIST 800-193 compliant hardware root-of-trust with an identity that cannot be cloned" [@ms-learn-cerberus] [@nist-sp-800-193] running in Azure datacenters; the GitHub reference implementation [@azure-cerberus-github] is actively maintained. In the November 2020 Pluton announcement, Microsoft framed Cerberus as the server-side counterpart to Pluton's client-side root of trust [@ms-pluton-blog-2020] -- the two are designed to compose, with Pluton providing the per-CPU identity that an upstream Cerberus chip (or Caliptra-equipped server) can attest. The distinction between Pluton-as-client-RoT and Cerberus-as-server-RoT is operational, not architectural rivalry.

The cross-design comparison

Dimension	Pluton-on-PC	Apple SEP	Google Titan M2	Caliptra	Cerberus
Physical location	On-die in application SoC	On-die in Apple SoC	Discrete or in-package on Pixel	On-die in datacenter SoC	Discrete on server BMC
Trust anchor	Microsoft (chip-firmware signer)	Apple (vertical)	Google (vertical)	Per-chip integrator	Operator (Microsoft on Azure)
Update channel	Windows Update [@ms-learn-pluton]	iOS / macOS update	Android / Pixel update	Server-side platform update	OEM / operator update
Firmware language	Rust (2024+) [@ms-learn-pluton]	Apple-customised L4 [@apple-sep]	Not publicly disclosed	Open-source firmware [@caliptra-github]	C / C++ (open) [@azure-cerberus-github]
Open source	Closed	Closed	Closed (driver public)	Open (RTL + firmware)	Open (RI on GitHub)
Multi-signer	Single	Single	Single	Multi-vendor by deployment	Per-deployment
Standards exposure	TCG TPM 2.0 over CRB	Apple-private	Android Verified Boot, StrongBox	Caliptra spec; SPDM 1.3 in 2.0	NIST SP 800-193
Best-known structural attack	None peer-reviewed Pluton-specific (TPMScan corpus only [@tpmscan-2024])	T2 inherits A10 Boot ROM (checkm8) [@wikipedia-apple-t2]	None public on Titan M2	Reviewed open-source RTL	Mature; deployed since 2017
Best suited for	Windows 11 client procurement	Apple devices	Pixel devices	Datacenter SoC integration	Server BMC RoT
Form factor	General-purpose PC	Apple devices	Pixel phones	Datacenter SoCs	Server motherboards

The political question made architectural. Caliptra and OpenTitan answer "what would multi-signer / open-source look like?" in the datacenter. Apple SEP demonstrates that the single-vendor / single-signer model is operationally durable at consumer scale -- but only when the vendor owns the entire stack. Pluton sits in the awkward middle: single-signer but multi-OEM, closed-firmware but open-Linux-driver, on-die but the chip vendor is not the firmware vendor. That middle position is what makes the procurement debate hard, and it is what makes the open problems in section 9 unresolved.

Pluton is the strongest on-die RoT for Windows clients in 2026, with the fastest patch cadence, the broadest hardware list, and the most mature design pedigree. What can it still not do?

8. What Pluton still cannot do

Two structural limits inherited from the prior article, and a third that is specific to single-signer on-die firmware. The first two say what no on-die RoT can do. The third says what no Microsoft-only-signer RoT can do. The worked example is CVE-2025-2884.

Limit 1 -- RTS+RTR, not RTE

A passive cryptoprocessor -- including Pluton -- cannot detect that the wrong code measured itself. It can only refuse to release sealed material when PCRs do not match the stored policy. The prior article's section 7.1 [@prior-tpm-in-windows] walks the bit-level reasoning. On-die does not change this. Pluton implements Root of Trust for Storage and Root of Trust for Reporting; it does not implement a Root of Trust for Execution that runs the code outside the chip on the reader's behalf.

Limit 2 -- The VMK transits OS RAM at unseal

The Volume Master Key must enter RAM during Trusted Boot, and once unsealed it lives in OS-controlled memory. An attacker who reads OS RAM at the release moment, or any time after, defeats TPM-only BitLocker regardless of TPM strength (prior article sections 7.2 and 7.3 [@prior-tpm-in-windows]). Pluton's on-die location eliminates the dTPM bus surface; it does not change which side of the unseal boundary the VMK lives on. This is why Virtualization-Based Security, Credential Guard, DRTM, and System Guard Secure Launch exist as complements, not substitutes, to the TPM/Pluton primitive.

Limit 3 -- Single-signer revocation impossibility

This is the new one. State the result precisely: if the on-die RoT firmware can only be authenticated by a single signer S, then the chip's trust anchor cannot be retired without bricking the chip's firmware-update path, regardless of whether S is compromised, coerced, or jurisdictionally constrained. This is not a cryptographic impossibility. It is a key-management impossibility. Revocation requires either (a) a second trust anchor provisioned at chip manufacture and held outside S's control -- i.e., multi-signer at the chip level, not just at the deployment level -- or (b) physical replacement of the silicon. Caliptra and Cerberus weaken the failure mode by moving the signer to the integrating chip vendor or to the operator, but they do not eliminate it; each chip still has one signing root.

A key-management (not cryptographic) impossibility: a chip whose firmware-authentication root has one signer in ROM cannot have that signer retired without bricking the firmware-update path or replacing the silicon. Pluton-on-PC silicon shipping today bakes a Microsoft-rooted public key into ROM. See the §8 prose paragraph above and the Callout below for the precise statement of conditions and the operational reasoning (FIDO2 / threshold-signature analogues; §5 trust-shift cross-anchor).

Note: There is no cryptographic objection to multi-signer RoT firmware. The math has been understood since the FIDO2 multi-credential work, and threshold signatures have been a primitive for decades. The objection is operational: replacing public keys after the chip is in the field requires either fab-time multi-signer or hardware replacement. Section 5 named the choice; this Callout names what makes it hard to undo.

Worked example -- CVE-2025-2884

On June 10, 2025, NVD published CVE-2025-2884 [@cve-2025-2884]. The CERT/CC coordination ticket is VU#282450 [@cert-cc-vu-282450]. The vulnerability is an out-of-bounds read in the CryptHmacSign function of the TCG TPM 2.0 reference implementation, Level 00, Revision 01.83 (March 2024). The CERT/CC document describes the impact: "An authenticated local attacker can send malicious commands to a vulnerable TPM interface, resulting in information disclosure or denial of service of the TPM" [@cert-cc-vu-282450].

Crucially for attribution, the CERT/CC ticket is explicit about who reported it and who wrote it up: "Thanks to the reporter, who wishes to remain anonymous. This document was written by Vijay Sarvepalli" [@cert-cc-vu-282450]. The reporter is anonymous; the CERT/CC document author is Vijay Sarvepalli. Tech press accounts that have attributed the disclosure to Quarkslab are incorrect; the primary CERT/CC record is dispositive.The Quarkslab attribution that some 2025 tech-press accounts use for CVE-2025-2884 is contradicted by the primary CERT/CC record VU#282450, which says verbatim: "Thanks to the reporter, who wishes to remain anonymous. This document was written by Vijay Sarvepalli" [@cert-cc-vu-282450]. The reporter is anonymous. The document author is Vijay Sarvepalli. This article uses that attribution and only that attribution.

Multiple downstream products are affected. Intel published Security Advisory SA-01209 [@intel-sa-01209]. Siemens published SSA-628843 [@siemens-ssa-628843]. The libtpms project assigned CVE-2025-49133 [@cve-2025-49133] for its own derivative; the upstream fix landed in libtpms commit 04b2d8e9 [@libtpms-commit-04b2d8e9]. The TCG itself coordinated VRT0009 [@tcg-vrt0009-advisory] and a TPM 2.0 Library Specification v1.83 errata (cited via NVD as the verifiable mirror -- the TCG site returns 403 to non-browser User-Agents).

Why this is the right worked example for Pluton. Garrett's April 2022 reverse-engineering [@garrett-2022-pluton-rev] documented that the Pluton firmware blob in the AMD Ryzen 6000 BIOS is "firmware for Pluton -- it contains chunks that appear to be the reference TPM2 implementation, and it broadly decompiles as valid ARM code." The Pluton firmware blob is an ARM image derived from the TCG TPM 2.0 reference code. So a CryptHmacSign OOB read in the TCG reference code was present in Pluton firmware too, on the silicon Garrett looked at, until the firmware was rebuilt against the patched reference implementation. On-die location did not stop the bug from existing.

What did matter for outcomes was the dwell time before the vulnerable code was replaced. The structural change that distinguishes Pluton from a 2014 dTPM is not "where the chip is" but "who can patch it, and how fast." A discrete TPM with the same bug would wait for the dTPM vendor to push a firmware build, the OEM to package a UEFI capsule, the OEM to test it across its product lines, and the user to install it. Microsoft's Pluton patch path is the Windows Update channel -- the same channel that already delivers kernel updates to roughly 1.4 billion endpoints on a Patch Tuesday cadence. Section 5 design choice 4 walked the channel-shape change and the no-SLA hedge; this is what makes the channel the security property that matters here.

Realization	Patch path	Approximate latency	Bottleneck
Discrete TPM	dTPM vendor build -> OEM UEFI capsule	Quarters to years	OEM fleet test + per-OEM rollout
Intel PTT (CSME)	Intel ME firmware -> OEM UEFI capsule	Months to quarters	OEM UEFI capsule path (TPM-Fail lesson)
AMD fTPM (PSP)	AMD AGESA -> OEM UEFI capsule	Months to quarters	Same OEM UEFI capsule path
Pluton-on-PC	Microsoft signs -> Windows Update	Days to weeks (no published SLA)	Microsoft signing key + WU infrastructure

flowchart TD Ref[TCG TPM 2.0 reference
Level 00 Rev 01.83
March 2024] CVE[CVE-2025-2884
CryptHmacSign OOB read
NVD published 2025-06-10] Pluton[Pluton firmware
ARM blob
per Garrett 2022] Intel[Intel SA-01209] Siemens[Siemens SSA-628843] Libtpms[libtpms
CVE-2025-49133
commit 04b2d8e9] TCG[TCG VRT0009
+ TPM 2.0 v1.83 errata] Ref --> CVE CVE --> Pluton CVE --> Intel CVE --> Siemens CVE --> Libtpms CVE --> TCG

Key idea: Pluton's structural advantage is the patch path, not the silicon location. CVE-2025-2884 demonstrates that on-die location does not stop a TCG-reference-code bug from existing on a Pluton chip. What changes between a 2014 dTPM and a 2025 Pluton is not "where the chip is" but "who can patch it, and how fast." On-die is necessary but not sufficient. The breakthrough is the update path. The cost of the update path is the political question section 1 promised.

If single-signer revocation is impossible, what would multi-signer Pluton look like? And what other open problems does this design choice leave unsolved?

9. Open problems Pluton has named but not solved

Five concrete open problems sit in front of any 2026 reader of the Pluton design. Each is mapped below to the closest existing partial result. None has a public solution.

Open problem 1 -- Multi-signer firmware for on-die client RoTs

No public proposal exists for multi-signer Pluton on a Windows client. Caliptra moves the signer to the integrating chip vendor [@caliptra-github], so the count of signers per chip remains one even when the count per deployment is many. There is no public proposal for two simultaneous signers on a single client RoT (e.g., Microsoft and a sovereign signer; or AMD and Microsoft for a Pluton-on-AMD chip). The closest existing analogues live elsewhere -- IETF KEYTRANS for transparency-logged keys [@ietf-keytrans-wg], HSM-cluster split-signing for operational continuity -- but none has a hardware-RoT counterpart that has shipped. The unresolved engineering question, named in the prior article's section 8, is whether multi-signer can be added without losing the timely-update property that motivated Pluton in the first place.The IETF KEYTRANS working group [@ietf-keytrans-wg] is the closest active venue for the multi-signer thread, although KEYTRANS is concerned with end-user identity-key transparency rather than firmware-signing keys. The transparency-log primitive is the same (a Merkle tree of signed claims, auditable by independent verifiers); the hardware-RoT integration is missing. A reader interested in the multi-signer thread should track KEYTRANS and the OpenTitan / Caliptra governance discussions in parallel.

Open problem 2 -- Regulatory jurisdiction of single-signer firmware

Pluton's signing key is, in effect, a US export-controlled artifact. The EU Cyber Resilience Act entered into force on December 10, 2024, with the bulk of its security obligations applying from December 11, 2027 and reporting obligations applying from September 11, 2026 [@eu-commission-cra]; from the 2027 date it will require demonstrable security properties for products with digital elements, without specifying who the signer must be. Sovereign fleets -- the German Federal Office for Information Security (BSI), Singapore, Switzerland -- have varying postures on whether a non-domestic RoT is acceptable. Read in 2026, the Dell and Lenovo statements of March 2022 [@register-2022-pluton] [@pcworld-2022-pluton] are the first public push-back along this axis. The procurement debate is not technical; it is jurisdictional. There is no current proposal for a Pluton variant that satisfies a non-US sovereign procurement requirement.

The EU Cyber Resilience Act entered into force on December 10, 2024 [@eu-commission-cra]. Reporting obligations apply from September 11, 2026; the main security obligations apply from December 11, 2027 [@eu-commission-cra]. CRA does not name signers; it requires demonstrable security properties, vulnerability handling, and update channels for products sold into the EU. A single-signer foreign-rooted RoT can satisfy CRA. Whether it satisfies *sovereign* procurement requirements is a separate question.

The German BSI's Common Criteria PP-0084 protection profile [@bsi-pp-0084] (used historically for Infineon SLB 9670 / 9672 dTPMs) bakes in expectations of the chip-supplier governance that a US-rooted Pluton does not satisfy without a parallel certification path. Switzerland's federal IT procurement, Singapore's CSA, and a number of EU member-state ministries take comparable positions. None of these is a formal ban on Pluton; all of them are formal preferences that procurement officers must navigate.

The architectural fix -- a sovereign signing-root variant of Pluton -- has not been publicly proposed by Microsoft. The economic incentives for such a variant are not obviously favourable: every additional signer adds operational cost to the Windows Update path that Pluton's design specifically optimises. The procurement market is, as of 2026, deciding both ways, and the 2022 Dell statement is the most-cited public datapoint of a vendor declining to take the bet.

Open problem 3 -- SPDM 1.3 component attestation on PC

Pluton attests the host SoC. It does not yet attest individual components -- NICs, NVMe SSDs, PCIe accelerators -- on Windows clients. The DMTF's Security Protocol and Data Model (DSP0274) is the wire protocol for component-to-component attestation: a publication cadence of 1.3.0 in June 2023, 1.3.2 in September 2024, and 1.3.3 in December 2025 [@dmtf-dsp0274]. The Caliptra MCU project's Rust SPDM responder design page is the most explicit public reference for what an SPDM 1.3 endpoint looks like inside an on-die RoT: SPDM is "a protocol designed to ensure secure communication between hardware components by focusing on mutual authentication and the establishment of secure channels over potentially insecure media... using X.509v3 certificates" [@caliptra-mcu-spdm], with a fixed message inventory (GetVersion, GetCapabilities, NegotiateAlgorithms, GetDigests, GetCertificate, Challenge, GetMeasurements, KeyExchange, Finish) carried over an MCTP transport binding. Caliptra 2.0's RTL design freeze in October 2024 [@caliptra-ocp-2024-news] commits SPDM as part of the Caliptra Subsystem reference stack: "Reference Stack: MCTP PLDM, SPDM" [@caliptra-ocp-2024-news]. That is the server-side commitment.

The PC-client equivalent is not on the public record as of May 2026. Microsoft Learn's Pluton page does not mention SPDM, DSP0274, MCTP, or component attestation [@ms-learn-pluton]. There is no Microsoft-published Windows feature or Pluton-firmware milestone that names "SPDM responder" or "component attestation on PC" as a roadmap deliverable. The architectural question -- whether Pluton becomes the platform's SPDM responder, whether each component (NVMe controller, Wi-Fi card) is its own responder and Pluton aggregates the evidence, or whether Windows Defender System Guard owns the Windows-side appraiser -- is not answered by any published Microsoft document on the public record as of May 2026. The closest existing reference design lives in chipsalliance/caliptra-mcu-sw (Rust SPDM responder, X.509-anchored mutual auth), and the most likely standards venues for a PC-client profile are the DMTF SPDM WG (the wire protocol owner) and the OCP Security WG (the appraisal-framework owner). Until Microsoft publishes a Windows-feature surface that owns the SPDM responder on PC, "Pluton attests the host SoC, period" is the article's honest description of the 2026 state.

Open problem 4 -- Pluton-Caliptra interoperation

A Pluton-rooted client should, in principle, be able to attest to a Caliptra-rooted server in a single end-to-end protocol with both roots of trust visible in the resulting evidence chain. The wire-protocol candidates exist and are largely standardised. What is missing is the composite-attestation profile that wires them into a single client-to-server flow.

The candidate stack as of May 2026 lives across three SDOs and one OCP project. The DMTF owns SPDM 1.3 for component-to-component attestation [@dmtf-dsp0274] [@caliptra-mcu-spdm]. The IETF Remote Attestation Procedures (RATS) Working Group owns the architectural primitives for what an evidence-and-results message contains: RFC 9711 (April 2025, Standards Track) is the Entity Attestation Token (EAT), a CBOR Web Token (CWT) or JSON Web Token (JWT) form for "an attested claims set that describes the state and characteristics of an entity" [@ietf-rfc9711]; draft-ietf-rats-corim-10 (in WG Last Call as of March 2026) is the Concise Reference Integrity Manifest, the appraisal-time profile for "Endorsements and Reference Values in CBOR format" [@ietf-corim]; draft-ietf-rats-msg-wrap-23 (in the RFC Editor queue since December 2025) is the Conceptual Message Wrapper, a CBOR-tag / JWT / CWT / X.509-extension envelope for composing evidence, attestation results, endorsements, and reference values across protocols [@ietf-msg-wrap]. The full RATS WG document inventory at datatracker.ietf.org/wg/rats/documents/ shows additional active drafts on multi-verifier composition, posture-assessment, EAR (an evidence-appraisal-results profile), and PKIX key attestation [@ietf-rats-wg-docs]. The OCP Security WG owns the third-party appraisal framework: OCP S.A.F.E. v2.0 (March 2026) added explicit CoRIM SFR support and is the public mechanism by which a fleet operator certifies that a vendor's firmware-appraisal evidence has been independently audited [@ocp-safe-framework]. Caliptra 2.0's reference stack already wires SPDM, MCTP, and PLDM [@caliptra-ocp-2024-news]; the Caliptra MCU Rust responder shows the SPDM endpoint shape [@caliptra-mcu-spdm].

What is missing is a single published profile that walks the chain end to end: a Pluton-rooted Windows client emits a Get-Tpm-derived attestation (Pluton acting as evidence producer); the network carries CMW-wrapped evidence with a CoRIM endorsement set the verifier consumes; the verifier emits an EAT-formatted attestation result; a Caliptra-rooted server consumes the result and gates fleet membership. Each leg has a draft. No public SDO document binds them into a single Pluton-Caliptra composite-attestation profile with reference implementations on both ends. The natural venue is a joint DMTF SPDM WG and OCP Security WG profile, with IETF RATS as the architectural reference; the natural reference implementation pair is chipsalliance/caliptra-mcu-sw on the responder side and a Windows-feature surface (which Microsoft has not named publicly) on the client side. Until that joint profile exists and ships reference implementations, Pluton-Caliptra interoperation in 2026 is two roots-of-trust deployed, with no published end-to-end protocol that visibly carries both signatures into a single evidence chain.

Open problem 5 -- Supply-chain integrity beyond firmware signing

The Pluton signing root protects firmware integrity after the chip ships. Listing the supply-chain steps in chronological order makes the residual trust gap concrete: (1) the IP-licensing handshake from Microsoft to AMD / Intel / Qualcomm; (2) tape-out and process-design-kit integration at TSMC; (3) wafer fabrication; (4) per-vendor package assembly; (5) OEM motherboard integration; (6) OEM firmware integration (BIOS / UEFI vendor code that surrounds the Pluton block); (7) retail distribution. None of these steps is presently attested by Pluton itself; the on-die signing root is applied at step 6 and exercised from step 7 onward, but steps 1-5 are out of band of the chip's RoT.

The closest existing partial answer is a layered combination of three primitives. First, DICE -- TCG's Device Identifier Composition Engine -- gives every component a Hardware Root of Trust (HRoT) which uniquely identifies the component and attests component firmware [@tcg-dice], anchored by a per-die Unique Device Secret (UDS) that derives a Compound Device Identifier (CDI) per layer; the Open Profile for DICE v2.6 [@open-dice] is the reference profile and explicitly cites the TCG normative parent. DICE answers step 4-5 (per-package and per-board identity) provided the integrator provisions a UDS on the die. Second, SPDM 1.3 [@dmtf-dsp0274] [@caliptra-mcu-spdm] is the wire protocol that surfaces those DICE identities to a verifier at runtime: a per-component SPDM responder (carried over MCTP / PLDM in Caliptra 2.0's stack [@caliptra-ocp-2024-news]) emits a measurement set tied to its CDI. Third, OCP S.A.F.E. (Security Appraisal Framework and Enablement) v2.0 [@ocp-safe-framework] is the third-party-audit framework that lets a fleet operator certify that a Device Vendor's firmware was assessed by a Security Review Provider; the v2.0 March 2026 revision explicitly added CoRIM SFR support, wiring S.A.F.E. into the IETF RATS appraisal stack [@ietf-corim]. Together, DICE + SPDM + S.A.F.E. answer "is each component what its vendor said it was, and has the firmware been independently appraised?"

What is not built is the verifier infrastructure that consumes that evidence end to end. There is no public per-component-EK transparency log analogous to Certificate Transparency for the web PKI; there is no Pluton-rooted client-side appraiser that consumes per-component SPDM evidence and gates Windows boot on it; there is no shipping fleet-side hardware-bill-of-materials (HBOM) audit pipeline that ingests S.A.F.E. reports and Caliptra-rooted server attestations together. The supply-chain trust is named by DICE + SPDM + S.A.F.E.; it is not operationalised end to end on a 2026 Windows 11 client. The honest framing is: Pluton's signing root closes step 6 and step 7; DICE + SPDM + S.A.F.E. are the public standards that, if implemented in the Windows feature stack, would close steps 4-5; steps 1-3 (IP licensing, tape-out, wafer) remain out of band of any of the public standards above.

The 10-property scoreboard for an ideal client-PC on-die RoT

Five open problems converge onto a single scoreboard. This article's SOTA review enumerates ten properties an ideal client-PC on-die Root of Trust in 2026 would satisfy (expanding the prior article's six TPM-ideal properties [@prior-tpm-in-windows] with multi-signer governance, public RTL, native PQC, and component attestation): (1) on-die location with no off-package bus; (2) an isolated TEE shared with nothing else; (3) memory-protected DRAM with AES + authenticated + anti-replay protection; (4) OS-channel firmware updates; (5) memory-safe firmware language; (6) multi-signer firmware authentication; (7) public RTL and verification flow; (8) native post-quantum primitives (ML-DSA, ML-KEM); (9) component attestation across PCIe / NVMe / NIC via SPDM 1.3; (10) high-assurance certification depth (Common Criteria EAL4+ and FIPS 140-3). No shipping method satisfies all ten; the matrix below shows where each design sits.

Property	Pluton-on-PC 2026	Apple SEP (A14/M1+)	OpenTitan (Earl Grey / Darjeeling)	Caliptra 2.0 (RTL freeze Oct 2024)	Cerberus (current production)
1. On-die, no bus	Yes [@ms-pluton-blog-2020]	Yes [@apple-sep]	Discrete or in-package	Yes [@caliptra-github]	No (discrete on BMC)
2. Isolated TEE	Yes (dedicated)	Yes [@apple-sep]	Yes (whole chip)	Yes (RTM block)	Yes (whole chip)
3. AES + authenticated + anti-replay DRAM	Not on public record	Yes (A14/M1+) [@apple-sep]	Limited (chip-internal SRAM)	N/A (no DRAM responder role)	N/A (server BMC)
4. OS-channel firmware updates	Yes (Windows Update) [@ms-learn-pluton]	Yes (iOS / macOS) [@apple-sep]	Project-managed	Server platform updates	OEM / operator updates
5. Memory-safe firmware	Yes (Rust 2024+) [@ms-learn-pluton]	Apple-customised L4 [@apple-sep]	Rust runtime in OpenTitan codebase	Rust [@caliptra-github] [@caliptra-mcu-spdm]	C / C++ [@azure-cerberus-github]
6. Multi-signer	No (Microsoft only)	No (Apple only)	No (per-deployment)	Multi-vendor by deployment, single per chip [@caliptra-github]	Per-deployment signer
7. Public RTL and verification	No	No	Yes [@opentitan-home] [@opentitan-commercial]	Yes [@caliptra-github]	Yes (reference impl) [@azure-cerberus-github]
8. Native PQC (ML-DSA, ML-KEM)	No public commitment date	No public commitment date	On roadmap [@opentitan-home]	Yes (RTL freeze incl. Dilithium + Kyber) [@caliptra-ocp-2024-news]	No
9. Component attestation (SPDM 1.3)	No (open problem 3)	Apple-private equivalents	Not yet	Yes (Reference Stack: MCTP PLDM, SPDM) [@caliptra-ocp-2024-news] [@caliptra-mcu-spdm]	NIST SP 800-193 framing [@ms-learn-cerberus]
10. EAL4+ and FIPS 140-3	No equivalent posture in 2026 [@bsi-slb-9670-cc]	Not pursued for SEP	In assessment	Not pursued	Some certifications via OEM
Properties satisfied	4 (1, 2, 4, 5)	4 (1, 2, 3, 4)	2 (5, 7)	3 (5, 7, 8) -- on track for 9	1-2 (7 + partial 9)

The matrix says two things at once. First, no shipping on-die RoT in 2026 satisfies more than four of the ten properties; the scoreboard is sparse on purpose. Second, the closest trajectory to the ten-property ideal is not any single design; it is the union of Pluton's properties (1, 2, 4, 5), Caliptra's open RTL and PQC commitments (7, 8, 9), and OpenTitan's open RTL (7). A hypothetical Pluton variant that adopted Caliptra-style multi-signer governance, OpenTitan-style RTL transparency, and the Caliptra 2.0 SPDM responder reference stack would satisfy 1, 2, 4, 5, 6, 7, 8, 9 -- eight of the ten -- with high-assurance certification (10) the residual procurement question. That hypothetical Pluton has not been publicly proposed by Microsoft. It is, however, the design the matrix names as the destination if all five open problems above were closed.

The shape of the unanswered question

Open problem	Why it matters	Closest existing partial result	Outstanding gap
Multi-signer client RoT	Single-signer revocation impossibility	Caliptra (multi-vendor by deployment, single-signer per chip) [@caliptra-github]	No two-signer-per-chip proposal for client
Regulatory jurisdiction	Sovereign procurement, EU CRA (in force Dec 10 2024, reporting from Sep 11 2026, main obligations from Dec 11 2027) [@eu-commission-cra]	March 2022 Dell / Lenovo posture [@register-2022-pluton] [@pcworld-2022-pluton]	No sovereign Pluton variant
SPDM 1.3 on PC	Component attestation beyond the SoC	Caliptra 2.0 reference stack with SPDM [@caliptra-ocp-2024-news] [@caliptra-mcu-spdm]	No PC-client SPDM responder named on Microsoft Learn
Pluton-Caliptra interop	Composite client-to-server attestation	RATS EAT [@ietf-rfc9711] + CoRIM [@ietf-corim] + CMW [@ietf-msg-wrap] + S.A.F.E. [@ocp-safe-framework]	No joint DMTF / OCP / RATS profile binding the chain end to end
Supply-chain integrity beyond firmware signing	Pre-ship trust (steps 1-5 of the chain)	DICE [@tcg-dice] [@open-dice] + SPDM [@dmtf-dsp0274] + S.A.F.E. [@ocp-safe-framework]	Verifier infrastructure (per-component-EK transparency, HBOM appraiser) not built

All five share the same shape. Pluton has narrowed but not eliminated structural classes of trust. On-die narrowed but did not eliminate the silicon supply chain trust. Microsoft-rooted firmware servicing narrowed but did not eliminate the firmware-signing trust. Component attestation, when it ships on PC, will narrow but not eliminate the per-component supply-chain trust. Each Pluton design choice trades one trust for another; the residual trusts are the ones the article cannot answer technically and must label politically.

On Monday morning, what does the Windows engineer reading this actually do?

10. The Pluton checklist for 2026

Five questions. Each has a one-paragraph answer and a verifiable command or check. The reader who skipped sections 6 and 8 will still avoid the most expensive mistake -- counting "Pluton present" as "Pluton enabled."

Q1 -- Is Pluton present on this device?

Get-Tpm in PowerShell reports ManufacturerIdTxt. The four-character ASCII manufacturer string distinguishes the realisation. MSFT is Pluton; INTC is Intel PTT; AMD (with trailing space) is AMD fTPM; IFX, STM, and NTC cover Infineon, STMicro, and Nuvoton discrete TPMs respectively. The prior article's section 9 [@prior-tpm-in-windows] documents the broader manufacturer-string discovery path. The new Pluton-specific check is the four-letter MSFT value.

Open PowerShell as administrator and run:

Get-Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion, TpmPresent, TpmReady

A ManufacturerIdTxt of MSFT indicates Microsoft Pluton. INTC is Intel PTT (the firmware TPM in CSME). AMD (with the trailing space) is AMD fTPM (the firmware TPM in the PSP). The same logic is captured in the JavaScript <RunnableCode> mock in section 5 above. For richer detail, run tpm.msc -- the Microsoft Management Console snap-in shows the full TPM identity.

Q2 -- Is Pluton enabled, not just present?

This is the §6 soft-fuse trap. On AMD Ryzen 6000 / 7000 / 8000 silicon, Get-Tpm returning MSFT proves Pluton is exposed as the TPM but does not, on its own, prove Pluton is enabled in firmware (§6's Definition + Callout walk the PSP directory 0xB BIT36 mechanism Garrett 2022 documents [@garrett-2022-pluton-rev]). The procurement-relevant action is to audit BIOS-level Pluton (HSP) toggles and correlate Get-Tpm's manufacturer string with Get-PnpDevice / Device Manager before counting an AMD-Ryzen-6000-class device as Pluton-protected. On Lenovo AMD Ryzen 6000 ThinkPads specifically, the launch posture was Pluton present but disabled by default [@register-2022-pluton] -- so a 2022 ThinkPad inventory query that finds Ryzen 6000 silicon will not, on its own, tell the operator whether Pluton is doing any work.

Q3 -- Is Pluton firmware current?

Microsoft publishes Pluton firmware via Windows Update [@ms-learn-pluton]. Microsoft does not publish a per-release notes feed for Pluton firmware, so the operator must rely on the general Windows Update history and the chip vendor's advisory feed (Intel SA-* for Intel-Pluton silicon; AMD's security bulletins for AMD-Pluton silicon). The procurement-relevant property is that the channel exists and ships. The procurement-relevant question is whether the operator's organisation is willing to depend on that channel.

Q4 -- When to prefer Pluton over dTPM, PTT, or AMD fTPM

Three procurement scenarios where Pluton is the right answer in 2026.

Default Windows 11 client procurement. Pluton on AMD Ryzen 6000 and later, Intel Core Ultra 200V Series and Series 3, and Snapdragon X Series [@ms-learn-pluton]. The Microsoft-supported configuration; the path of least administrative resistance; the only realisation that ships memory-safe firmware on the Patch Tuesday cadence.
Adversary model includes physical access. Andzakovic-class bus sniffing [@andzakovic-2019-tpm-sniffing], faulTPM-class voltage glitching [@jacob-2023-faultpm]. Pluton (on-die, dedicated TEE) closes both surfaces structurally.
Need fast firmware updates for security responses to TCG-reference-code bugs. CVE-2025-2884 is the worked example [@cve-2025-2884]. Pluton's Windows Update servicing is the only realisation in 2026 that does not depend on the OEM UEFI capsule path.

Q5 -- When to not prefer it

Three procurement scenarios where Pluton is not the right answer.

Regulated fleets requiring a non-US trust anchor. German BSI PP-0084-class procurement [@bsi-pp-0084], EU sovereign workloads. Hardened dTPM (Infineon SLB 9670 / 9672, STMicro ST33TPHF) has the certified posture [@bsi-slb-9670-cc]; Pluton has no equivalent EAL4+ certification path on the public record as of 2026 [@bsi-slb-9670-cc].
Air-gapped fleets that cannot accept Windows-Update-delivered firmware. Offline UEFI capsule servicing remains the only operationally feasible patch path; dTPM is the mechanically right choice for that fleet.
Multi-vendor sourcing requirements. dTPM has multiple silicon vendors (Infineon, STMicro, Nuvoton). Pluton has one signer per chip and only the AMD / Intel / Qualcomm silicon paths Microsoft has licensed. Datacenter operators who need multi-vendor sourcing should look at Caliptra [@caliptra-github] -- not a Pluton substitute on Windows clients, but the right answer for datacenter SoC procurement.

Choose Pluton when...	Choose dTPM (or Caliptra) when...
Default Windows 11 client procurement [@ms-learn-pluton]	Sovereign procurement (German BSI, EU sovereign)
Adversary model includes physical access	Air-gapped fleet, no Windows Update channel acceptable
Need Patch Tuesday firmware response cadence	Need EAL4+ / FIPS 140-3 certification posture today
Want memory-safe Rust firmware (2024+ silicon)	Need multi-vendor silicon sourcing
Want on-die dedicated TEE versus shared PSP/CSME	Datacenter SoC integration (Caliptra)

flowchart TD Start[Need a TPM/RoT in 2026?] Q1{Datacenter SoC?} Q2{Sovereign / non-US RoT required?} Q3{Air-gapped fleet?} Q4{Default Windows 11 enterprise?} Caliptra[Caliptra 1.0] DTPM[Hardened dTPM
Infineon SLB 9670/9672
or STMicro ST33TPHF] DTPMcap[Hardened dTPM
offline UEFI capsule path] Pluton[Pluton on AMD Ryzen 6000+
or Intel Core Ultra 200V+
or Snapdragon X Series] Start --> Q1 Q1 -->|Yes| Caliptra Q1 -->|No| Q2 Q2 -->|Yes| DTPM Q2 -->|No| Q3 Q3 -->|Yes| DTPMcap Q3 -->|No| Q4 Q4 -->|Yes| Pluton Q4 -->|No| DTPM

We started with the question Microsoft answered architecturally before the prior article posed it. Where does that leave the political question that even the architectural answer cannot resolve?

11. Frequently asked questions, and one more political question

The architectural answer to "what is the cost of letting Microsoft sign the chip's firmware?" is partial and has been answered by every section above. The remaining piece is a set of common misconceptions, then a closing tied to the prior article.

No. fTPM is a TPM 2.0 task running inside an existing TEE -- Intel CSME (PTT) or AMD PSP. Pluton is a *dedicated* IP block on the SoC die that does not share a TEE with anything else. The threat-model gap that faulTPM exposed [@jacob-2023-faultpm] only closes for Pluton-as-Pluton, not for fTPM running on Pluton-equipped silicon. AMD-Ryzen-6000-class chips can ship Pluton silicon next to the existing PSP-based fTPM; §5 documents the OEM-picks-one mechanism via the Pluton (HSP) BIOS toggle [@garrett-2022-pluton-rev], and faulTPM-class attacks remain valid only on systems the OEM exposes as fTPM. No. Pluton implements the TCG TPM 2.0 specification plus Microsoft-specific extensions like SHACK [@ms-pluton-blog-2020]. From Windows's perspective, Pluton *is* a TPM, with a different update story (Windows Update versus OEM UEFI capsule) and a different trust anchor (Microsoft as firmware signer). Whether the OEM exposes Pluton "as the TPM" or alongside a discrete TPM is an OEM choice [@ms-learn-pluton-as-tpm]: *"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, while having Pluton available to the system as a security processor for use cases beyond the TPM"* [@ms-learn-pluton-as-tpm]. No. Pluton firmware is Microsoft-authored and Microsoft-signed [@ms-learn-pluton]. Caliptra is Microsoft-co-contributed and open source [@caliptra-github] -- but Caliptra is datacenter-class, not a Pluton substitute on Windows clients. The closest open-source on-die RoT for clients is OpenTitan [@opentitan-home] [@opentitan-commercial], which as of 2026 is discrete or in-package, not on-die in an application SoC. Tock OS [@tock-github] is the most mature publicly reviewed memory-safe embedded RTOS that *could* host Pluton-class workloads; whether it is the actual runtime on Pluton-on-PC is not on the public record. No. Pluton centralises firmware *signing*, not key access. The November 17, 2020 announcement specifies SHACK -- Secure Hardware Cryptography Key -- which states that keys *"are never exposed outside of the protected hardware, even to the Pluton firmware itself"* [@ms-pluton-blog-2020]. Microsoft signs the firmware that runs on Pluton; the keys Pluton creates and seals stay inside Pluton. (The prior article's FAQ entry on this point [@prior-tpm-in-windows] makes the same observation about the underlying TPM 2.0 non-exportability property.) Three things, in order. First, no off-package bus to sniff -- Andzakovic-class attacks [@andzakovic-2019-tpm-sniffing] have nothing to attack on Pluton silicon. Second, Patch Tuesday-cadence firmware fixes for TCG-reference-code bugs -- CVE-2025-2884 [@cve-2025-2884] is the worked example; the Pluton Windows Update path collapses the dwell time that a discrete-TPM fix would otherwise spend in OEM UEFI capsule queues. Third, Microsoft-authored Rust firmware on 2024+ AMD and Intel silicon [@ms-learn-pluton]; the bug class that memory-safe firmware structurally rules out is large. The cost of all three is a Microsoft signing key as the chip's trust anchor. Pluton inherits the TCG TPM 2.0 algorithm-agility property the prior article documented in section 8.1 [@prior-tpm-in-windows]. Caliptra 2.0 has a stated commitment to ML-DSA and ML-KEM [@caliptra-github]; Pluton-firmware post-quantum migration tracks similar primitives, but no Microsoft public commitment to a specific date for a post-quantum Pluton firmware release exists in 2026. The point of the algorithm-agility property is that the migration is a firmware change, not a silicon respin -- which is precisely the property the Pluton update path is designed to operationalise. Generally no. Disabling Pluton on AMD Ryzen 6000+ via the BIOS toggle does not return the system to a *stronger* security posture; it returns it to AMD fTPM (or no TPM at all, depending on the OEM's BIOS design). The faulTPM-class attack surface that motivated the move to Pluton in the first place re-opens [@jacob-2023-faultpm]. The procurement scenarios in section 10 list the narrow cases where dTPM is the right answer; in those cases the right action is to procure dTPM-equipped silicon, not to disable Pluton on Pluton-equipped silicon.

A closing tied to the prior article

Return to the line that opened this article. "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" [@prior-tpm-in-windows]. The architectural answer to that question existed inside an Xbox before the question was asked. Twelve years of Microsoft security silicon -- Xbox One in 2013, Project Sopris in 2015, the Seven Properties paper in 2017, Project Cerberus in 2017, Azure Sphere in 2018, Pluton-on-PC in 2020, AMD Ryzen 6000 silicon in 2022, Linux 6.3 driver in 2023, Caliptra 1.0 in 2024, the CVE-2025-2884 dwell-time test in 2025 -- have shaped the on-die security processor on the modern Windows 11 client.

The article's own answer is direct. Pluton makes the political question concrete and unavoidable, but it does not resolve it. On-die closes the bus surface. Dedicated TEE closes the shared-TEE blast radius that defeated AMD fTPM. Memory-safe Rust firmware narrows the bug class that has driven the firmware-CVE economy for a decade. Windows Update collapses the patch latency from OEM-capsule quarters to Patch Tuesday weeks. Each design choice retires a 2014-2024 attack class. Each design choice places a new trust in Microsoft. The trust question is now visible at every level of the stack: silicon supply chain, firmware language, signing key, update channel, regulatory jurisdiction. It does not go away because Microsoft engineered the chip well. It goes from being a technical question to being a procurement question.

Pluton makes the political question concrete and unavoidable, but it does not resolve it.

The closing image is operational. An engineer running Get-Tpm on a Windows 11 laptop in 2026 reads a four-letter token in the manufacturer string. MSFT is what twelve years of Microsoft security silicon buys you. It is what closed the bus surface that the prior article's $40 FPGA exploited. It is what closed the shared-TEE surface that faulTPM extracted state from. It is what gives the Patch Tuesday channel something to deliver. It is also what places a single Microsoft signing key as the trust anchor for every Pluton-equipped Windows 11 client. That four-letter token is the article's subject, the prior article's epilogue, and the next decade's procurement question.

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

noreply@paragmali.com (Parag Mali) — Fri, 08 May 2026 00:00:00 GMT

The TPM (1.2 since 2007, 2.0 since 2014) is the hardware root of trust under almost every Windows security feature shipped since Vista -- BitLocker, Measured Boot, Credential Guard, Windows Hello, device attestation. Twenty-five years of engineering refined a single primitive (measure, extend, seal, quote) into something one chip could underwrite. Twenty-five years of attacks (Andzakovic 2019, TPM-Fail 2020, faulTPM 2023) have argued empirically about how passive that chip can be. The current state of the art -- Microsoft Pluton on the CPU die, Microsoft-signed Rust firmware (on 2024 AMD and Intel platforms) delivered via Windows Update -- closes the bus and the TEE attack surfaces, but centralizes firmware trust on Microsoft. Post-quantum migration is the next frontier.

1. The chip nobody asked for

On June 24, 2021, Microsoft announced Windows 11 [@ms-windows-experience-blog-2021] -- 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 [@ms-security-blog-windows11-2021]. 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 [@ms-learn-oem-tpm], 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.

A small, isolated cryptoprocessor that holds keys, performs cryptographic operations, and records integrity measurements -- usually on a separate package or block of silicon that the host operating system cannot read directly. The TPM is "passive": it executes commands sent to it but never reaches into the host's memory. The PC Health Check tool was pulled and re-released. Reddit and Hacker News spent a weekend arguing about whether Microsoft had effectively bricked older hardware to sell new licenses. Microsoft's reply -- that TPM-by-default produces measurable population-level security gains even when individual users do not understand it -- was correct, but never quite the rebuttal that a consumer audience could engage with. The politics of "Trusted Computing" had returned, twenty years after the original Stallman objection [@wikipedia-trusted-computing].

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 [@wikipedia-windows-2000] -- 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 [@ms-learn-cryptography-portal], 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" [@ms-learn-how-windows-uses-tpm]. That property cannot be retrofitted onto software-only storage.

Key idea: 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 [@wikipedia-tcg], 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 [@tcg-tpm-main-spec] appeared in 2003 [@wikipedia-tpm]. Atmel, Infineon, and STMicroelectronics built it [@wikipedia-tpm].

In parallel, Microsoft Research ran its own bet. Paul England, Butler Lampson, John Manferdelli, Marcus Peinado, and Bryan Willman [@england-2003-trusted-open-platform] 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 [@wikipedia-ngscb] 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.

In the early 2000s, Richard Stallman and the Free Software Foundation framed Trusted Computing as "treacherous computing" [@wikipedia-trusted-computing]: hardware secured "for its owner, but also against its owner." That objection has aged unevenly. The DRM concerns the FSF predicted did not dominate -- Hollywood never got the protected video paths it wanted on PCs. The trust-centralization concern has aged well: the modern Pluton debate raises a structurally similar question about who holds the signing key on the world's PC fleet, and the answer is now political rather than technical.

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 [@andzakovic-2019-tpm-sniffing]. 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 [@wikipedia-tpm] 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.

A TPM-internal register modified only by a one-way "extend" operation: $\text{PCR}_{\text{new}} = H(\text{PCR}_{\text{old}} \,\|\, \text{measurement})$. Static PCRs (0-15) cannot be rolled back without a full platform reset. TPM 2.0 also defines *dynamic* PCRs (16, 17-22, and 23 in the PC Client profile) that can be reset at specific localities via `TPM2_PCR_Reset`. DRTM uses PCRs 17-22 at locality 4 to re-launch a known measurement chain mid-run; PCRs 16 and 23 are resettable at lower localities for debug and application use. Either way, PCRs are the data structure that compresses a chain of measurements into a single attestable digest. The TPM's permanent identity key, generated at manufacture and accompanied by an EK certificate from the chip vendor's CA. The EK is non-migratable and is used during attestation to prove that a given key was generated inside a genuine TPM. It is also the privacy-sensitive part of TPM identity: the EK is unique to one chip, so unrestricted use of the EK in attestation reveals which physical machine you are. The root of the TPM's key hierarchy. In TPM 1.x there was exactly one SRK per chip, created during the "Take Ownership" ceremony. Every protected key in the hierarchy was a child of the SRK -- if you cleared the SRK, every key tied to it was lost. A restricted signing key the TPM uses to sign quotes of PCR values for a remote verifier. Naming changed with the spec: in TPM 1.x it was the Attestation Identity Key (AIK), a separate RSA key whose binding to a real TPM was asserted by a Privacy CA's certificate over the EK. In TPM 2.0 it is the Attestation Key (AK), a primary key in the Endorsement Hierarchy *derived from the same Endorsement Primary Seed as the EK* -- the AK is a sibling of the EK, not a copy, and it is certified by the EK rather than being an alias of it. Either way, the AIK/AK signs the quote; the EK never directly signs anything.

TPM 1.2 [@wikipedia-tpm], 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 [@wikipedia-ngscb] reached volume-license RTM in late 2006 and broad availability in early 2007, BitLocker [@ms-learn-bitlocker] (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 [@ms-learn-oem-secure-boot] 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 [@nist-sp-800-131a-r2] digital signatures starting in 2011. The 2017 SHAttered collision [@google-2017-shattered] 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.

Generation	Year	Hash	Asym	Hierarchies	Status
Software-only (LSA / PStore)	1996+ [@wikipedia-windows-nt-4]	varies	varies	n/a	NT 4.0 baseline; disk-readable wrapping keys
Software-only (DPAPI / EFS)	2000+	varies	RSA-1024 (EFS)	n/a	Defeated by offline disk theft and by SYSTEM compromise
TPM 1.1b	2003	SHA-1	RSA-2048	1 (SRK)	First mass deployment; superseded by 1.2
TPM 1.2	2003-2014	SHA-1	RSA-2048	1 (SRK)	Vista/7/8 BitLocker baseline; algorithm-rigid
TPM 2.0	2014+	SHA-1 + SHA-256 (+ SHA-3, future PQC)	RSA, ECC	4 (Platform / Endorsement / Storage / Null)	Current; ISO/IEC 11889:2015

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 [@wikipedia-tpm], the Trusted Computing Group [@tcg-tpm2-library-spec] 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 [@iso-iec-11889-1-2015], which removed the "industry consortium" objection from procurement teams in regulated environments. By July 28, 2016 [@ms-learn-oem-tpm], 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 [@ms-learn-how-windows-uses-tpm] 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.

A property of a cryptographic protocol or device whereby the choice of hash, signature, or encryption algorithm is decoupled from the protocol's data structures. Algorithm-agile systems carry algorithm identifiers alongside their cryptographic blobs, so a new algorithm can be added by registering an ID rather than by re-laying out the wire format. TPM 2.0 is algorithm-agile; TPM 1.x was not.

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 [@arthur-challener-goldman-2015] -- 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 [@ms-learn-bitlocker], 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.

TPM 2.0's flexible authorization mechanism. Each protected object carries a hash (policyDigest) of the predicates required to use it. A caller builds an equivalent digest by walking a sequence of TPM2_Policy* commands inside a policy session; the TPM only authorizes the operation if the two digests match. This is the mechanism that lets BitLocker bind the VMK to specific PCR values, lets Hello bind a key to a PIN gesture with anti-hammering, and lets attestation servers compose policies they did not design into the chip.

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 [@ms-learn-secure-boot-process] 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 [@ms-learn-bitlocker] seals the VMK to a PCR policy.
Measured Boot and Device Health Attestation [@ms-learn-azure-measured-boot] quote PCRs to a remote verifier.
Credential Guard [@ms-learn-credential-guard] seals the VBS-isolated NTLM/Kerberos secrets with a policy that includes the VBS measurement.
Windows Hello for Business [@ms-learn-hello-for-business] 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 [@ms-learn-tpm-key-attestation] for ADCS-issued certificates all sit on the same primitives.

Note: BitLocker, Measured Boot, Credential Guard, Windows Hello, virtual smart cards, DPAPI-NG, and TPM key attestation are not seven independent uses of a chip. They are seven policy expressions over the same four operations -- measure, extend, seal, quote -- on the same PCR set. The TPM is not a checkbox shared by features. It is one primitive that defines what hardware-rooted security can do in Windows.

Key idea: 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 [@andzakovic-2019-tpm-sniffing] that, in retrospect, started the modern era of TPM offense. He demonstrated two LPC-bus sniffing attacks on two different machines. On an HP business laptop running TPM 1.2, he used a DSLogic Plus logic analyzer connected via the laptop's debug header (7 wires: LCLK, LFRAME, LAD[0:3], and ground) to lift the BitLocker Volume Master Key off the LPC bus. On a Surface Pro 3 running TPM 2.0, he spent $40 NZD on a Lattice iCE40 ICEStick FPGA (8 connections: GND, LCLK, LFRAME#, LRESET#, LAD[0:3]) and replicated the attack. 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 [@andzakovic-lpc-sniffer-code] 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 [@withsecure-2020-spi-sniffing] and a public BitLocker-key extraction tool. A year later, Thomas Dewaele and Julien Oberson at SCRT reproduced the LPC attack [@scrt-2021-tpm-sniffing] on a Lenovo ThinkPad L440 with a chip (labeled P24JPVSP, identified by SCRT as probably equivalent to the ST33TPM12LPC) and published a tutorial. By October 2024, SCRT had industrialized the attack [@scrt-2024-bitlocker-pin] 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 [@wikipedia-intel-me]) 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 [@tpmfail-microsite]. 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 [@tpmfail-microsite], 2019

NVD assigned CVE-2019-11090 [@cve-2019-11090] to Intel PTT and CVE-2019-16863 [@cve-2019-16863] 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 at the moment of disclosure -- the STMicro chip held both Common Criteria EAL4+ and FIPS 140-2 Level 2, while the Intel chip held FIPS 140-2 [@tpmfail-microsite]. Certification did not catch the bug. The presentation is preserved in the USENIX Security 2020 proceedings [@moghimi-2020-usenix-tpmfail].

Note: Removing the bus did not remove the attack surface. It relocated it from the PCB to the trusted execution environment that hosted the firmware TPM. The fTPM closes one channel and opens another -- and the certification regime that was supposed to catch both missed the timing leak in chips that had passed their respective certification programmes (STMicro: Common Criteria EAL4+ and FIPS 140-2 Level 2; Intel: FIPS 140-2). The "fTPM has no bus to sniff" reassurance was a category error.

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) [@jacob-2023-faultpm], with reproducible code at github.com/PSPReverse/ftpm_attack [@pspreverse-ftpm-attack]. 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) [@jacob-2023-faultpm]

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 [@jacob-2023-faultpm]): 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

Attack class	TPM form	Cost	Time	Source
LPC bus sniffing (BitLocker VMK)	Discrete TPM 1.2 / 2.0	$0 (logic analyzer) -- ~$40 NZD (iCE40 FPGA, Surface Pro 3)	Minutes once wired	Andzakovic 2019; SCRT 2021/2024
SPI bus sniffing	Discrete TPM 2.0	~$50 (logic analyzer)	Minutes once wired	WithSecure 2020-2024
Timing side channel on ECDSA	Intel PTT, STMicro ST33	Software-only	4-20 min local; 5 h remote VPN	TPM-Fail 2019/2020
Voltage glitch on PSP	AMD fTPM	~$200 (glitching rig)	2-3 h physical	faulTPM 2023

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.

A *discrete* TPM is a separate chip on the motherboard, talking to the host over LPC, SPI, or I2C. A *firmware* TPM is a TPM 2.0 implementation running inside an existing trusted execution environment on the host -- Intel CSME (Platform Trust Technology), AMD PSP (fTPM), or a dedicated Microsoft IP block (Pluton). Both pass the same TCG specification; they differ in physical location, attack surface, and update channel. A zero-knowledge protocol that lets a TPM prove "I am a real TPM certified by vendor X" without revealing which chip is talking. Replaces the TPM 1.2 Privacy CA model, which required a third-party CA to mediate every attestation. ECDAA is the elliptic-curve variant standardized in TPM 2.0.

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 [@tpmfail-microsite] 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 [@wikipedia-amd-psp] (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 [@jacob-2023-faultpm] 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 (on 2024 AMD and Intel platforms) [@ms-learn-pluton] 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 [@ms-pluton-blog-2020], 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 [@ms-pluton-blog-2020]

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." [@ms-learn-pluton-as-tpm] 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 [@ms-learn-azure-trusted-launch] 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

Dimension	dTPM	Intel PTT	AMD fTPM	Pluton	vTPM
Physical location	Separate chip	CSME (PCH die)	PSP (CPU die)	Dedicated IP block on CPU die	Hypervisor memory
Bus to host	LPC / SPI / I2C	None (on-die)	None (on-die)	None (on-die)	None (virtual)
TEE shared with	none (own die)	CSME	PSP (large)	none (Pluton-only)	host kernel
Side-channel exposure	Implementation-dependent	TPM-Fail patched	faulTPM unaddressed structurally	Limited public research	host-dependent
Update channel	UEFI capsule	UEFI capsule (CSME)	UEFI capsule (PSP)	Windows Update	hypervisor patch
Certifications	EAL4+, FIPS 140-2/3	EAL4+	varies	varies	n/a
OEM cost	per-chip BOM	bundled	bundled	bundled	n/a
Best-known attack	LPC/SPI sniffing in minutes	TPM-Fail timing	faulTPM full state	None public at faulTPM depth	host compromise
Algorithm agility	spec-required	spec-required	spec-required	spec-required + Rust firmware updates	spec-required
Best fit	Compliance-driven, high-assurance fleets	Existing Intel platforms	Existing AMD platforms	Default for Windows 11 client	Cloud workloads

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 [@ms-secured-core-blog-2019] 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 [@ms-learn-system-guard] 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 [@ms-learn-bitlocker-countermeasures] 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 [@ms-learn-bitlocker-countermeasures] 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.

CVE-2023-21563 [@cve-2023-21563] -- the BitLocker Security Feature Bypass that the offensive-security community calls "Bitpixie" -- is a useful reminder that breaking BitLocker does not require breaking the TPM. The NVD entry reads simply "BitLocker Security Feature Bypass Vulnerability," and the bypass operates against the boot path that consumes the unsealed VMK, not against the chip that sealed it. (NVD does not use the "Bitpixie" name; it is community-known-as.)

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.

Key idea: 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) [@nist-fips-203-mlkem], FIPS 204 (ML-DSA) [@nist-fips-204-mldsa], and FIPS 205 (SLH-DSA) [@nist-fips-205-slhdsa] -- 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 [@nist-pqc-project] 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 [@federal-register-2024-fips-pqc] 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 [@ms-tpm-20-ref-releases] 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 [@fraunhofer-pqc-tpm] 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) [@nist-fips-205-slhdsa] routinely exceed the typical 1-4 KiB response-buffer cap (TPM_PT_MAX_RESPONSE_SIZE in the PC Client Platform TPM Profile [@tcg-pc-client-ptp-spec]); 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 [@ietf-lamps-pq-composite-sigs] 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 [@ietf-tls-hybrid-design] 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) [@ms-quantum-safe-2025] 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 [@ms-learn-tpm-key-attestation] 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 [@crocs-muni-roca] 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 [@cve-2017-15361] 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 [@wikipedia-roca] 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 [@arstechnica-2017-roca-estonia], all using the affected Infineon chip -- had to be re-enrolled. Microsoft published advisory ADV170012 [@msrc-adv170012] 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 [@ms-learn-cae] 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 [@ms-learn-cng-dpapi] 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 [@ms-learn-protection-descriptors] 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 [@register-2022-pluton] 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 [@pcworld-2022-pluton] 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) [@phoronix-2023-pluton-linux63] -- published the closest thing to a public engineering analysis of Pluton's controllability. His April 2022 reverse-engineering write-up [@garrett-2022-pluton-rev] 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 [@ms-learn-bitlocker] 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 [@ms-learn-azure-trusted-launch] 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 [@ms-learn-pluton] is the OEM default in many SKUs; verify the Pluton firmware is current via Windows Update.

9.3 Five common pitfalls

Note: Clearing the TPM invalidates BitLocker recovery on every TPM-bound protector. Always verify recovery key escrow first -- in Microsoft Entra ID for Azure-AD-joined devices, in Active Directory for AD-joined devices, or in a printed/saved location for personal devices. If the recovery key is unescrowed and the TPM is cleared, the volume is unrecoverable.

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.

Note: The Group Policy setting "Require additional authentication at startup" with a minimum PIN length of 8 buys you the most security against published attacks for the least operational cost. It defeats Andzakovic-style bus sniffing (the VMK is no longer the only secret on the bus) and forces an attacker on AMD fTPM to either compromise the TPM state out-of-band or guess the PIN against anti-hammering. The exception is a fully-extracted AMD fTPM where faulTPM has already obtained the unsealed material -- in that case the PIN is bypassed.

From an elevated PowerShell prompt:

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

The RebootCount 1 argument auto-resumes after the next reboot, which is what you want when the firmware update reboots the device. After the update completes, run Get-BitLockerVolume -MountPoint C: and confirm ProtectionStatus is On again. If you forget, the next boot will land on the BitLocker recovery prompt because PCR[0] no longer matches the sealed policy.

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.

No. TPM keys are non-exportable and held inside the chip; the Microsoft documentation [@ms-learn-how-windows-uses-tpm] is explicit that "if a key stored in a TPM has properties that disallow exporting the key, that key truly can't leave the TPM." The Endorsement Key is a privacy concern (it uniquely identifies the chip) but it is not a Microsoft backdoor. Pluton centralizes firmware *signing*, not key access -- Microsoft signs the firmware that runs on Pluton, but the keys Pluton creates and seals stay inside Pluton. Depends on threat model. Against software attackers, fTPM is sufficient -- the no-bus property defeats the cheap LPC/SPI sniffing class. Against well-funded physical attackers, fTPM is weaker than dTPM: TPM-Fail [@tpmfail-microsite] showed timing-side-channel ECDSA key recovery on Intel PTT, and faulTPM [@jacob-2023-faultpm] showed 2-3 hour state extraction on AMD PSP. Pluton sits between the two with a smaller TEE surface but less public scrutiny. Yes -- Microsoft mandates it. The OEM mandate has been in force since July 28, 2016 [@ms-learn-oem-tpm]; the consumer mandate became visible on June 24, 2021 with the Windows 11 announcement. The defensive primitives the TPM underwrites -- BitLocker, Credential Guard, Windows Hello, Device Health Attestation [@ms-learn-azure-measured-boot] -- are real, measurable, and not realistically replaceable by software-only equivalents. Practically no for dTPM and Pluton; the EK private key never leaves the chip, and replicating it would require silicon-level extraction that no public attack has achieved. faulTPM [@jacob-2023-faultpm] proved that AMD fTPM internal state can be *extracted* in 2-3 hours of physical access; that is closer to "extracted" than "cloned" but the practical effect is the same for keys the chip held. Because ransomware operates after the OS has loaded -- by definition outside the TPM's threat model. The TPM secures keys at rest and attests boot integrity. It does not run anti-malware, sign user files, or detect runtime compromise. Microsoft's BitLocker countermeasures page [@ms-learn-bitlocker-countermeasures] is explicit that BitLocker is a data-protection feature, not an anti-malware feature; the same logic applies to the TPM that underwrites it. Pluton implements TPM 2.0 plus Microsoft-specific extensions. From Windows's perspective it *is* a TPM with a different update story (Windows Update instead of UEFI capsule) and a different trust anchor (Microsoft as firmware signer). Whether the OEM exposes Pluton "as the TPM" or alongside a discrete TPM is an OEM choice [@ms-learn-pluton-as-tpm].

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.