# Pluton: A TPM On Silicon Microsoft Can Patch
> How Microsoft moved the TPM onto the SoC die, ran it on Rust firmware, and patched it through Windows Update -- and what that cost in trust centralisation.
*Published: 2026-05-09*
*Canonical: https://paragmali.com/blog/pluton-a-tpm-on-silicon-microsoft-can-patch*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**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 nine 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, four wires 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 27, 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 [@google-cloud-caliptra-1.0]. 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.
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 [@windows-blogs-1.4b]). 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 21, 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 an "SEP CPU Image Page" register 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 2018-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 [@google-cloud-caliptra-1.0] 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 [@google-cloud-caliptra-1.0]. 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.
### 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 [@tcg-tpm-1.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 [@windows-blogs-1.4b]. 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] [@google-cloud-caliptra-1.0], 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.
### 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 August 2024, and 1.3.3 in December 2025 [@dmtf-dsp0274] [@dmtf-spdm-1.3]. 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... leveraging 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:
```powershell
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 `` 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] [@google-cloud-caliptra-1.0] -- 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] [@google-cloud-caliptra-1.0]; 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.