Pluton: A TPM On Silicon Microsoft Can Patch

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 ^[1]. 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" ^[2]. 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 ^[3]. A network packet defeats Intel PTT through a 5-hour timing side channel against the ECDSA implementation in CSME ^[4]. 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 ^[5]. 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.

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 ^[6]. 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 ^[2] 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 ^[7]. 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 ^[7]. The Microsoft Research blog post is the surviving primary source on Sopris ^[7].

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 ^[8]. 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" ^[8]. 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.

November 9, 2017 -- Project Cerberus#

Microsoft announced Project Cerberus at the OCP Summit on November 9, 2017 ^[9]. 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" ^[9]. Microsoft contributed a five-PDF specification set to OCP under Project Olympus ^[10]: Architecture Overview, Challenge Protocol, Firmware Update, Host Processor Firmware Requirements, and Processor Cryptography. The reference implementation lives at Azure/Project-Cerberus on GitHub ^[11] -- platform-agnostic core, FreeRTOS and Linux ports, "designed to be a hardware root of trust (RoT) for server platforms" ^[11]. Microsoft Learn describes Cerberus as "a NIST 800-193 compliant hardware root-of-trust with an identity that cannot be cloned" ^{[12] [13]}. 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 ^[3]. 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" ^[14]. The companion Anatomy of a Secured MCU post is the first technical description: "our Pluton Security Subsystem is the heart of our security story" ^[6]. 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 ^[15], also describing Pluton as "a Microsoft-designed security subsystem that implements a hardware-based root of trust for Azure Sphere" ^[15].

"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 ^[14]

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 ^[3]. 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" ^[2]. 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 ^[4]: 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.

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 ^[5]. "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" ^[5]. The mechanism: a voltage glitch on the SVI2 power-management bus, against the AMD PSP (an ARM TrustZone Cortex-A5 inside modern Ryzen SoCs ^[16]), 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.

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

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.

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 ^[2]. 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 ^{[12] [13]}. Open spec at OCP ^[10]; reference implementation on GitHub ^[11]. 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" ^[2]. 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 ^{[14] [6]}. "Our Pluton Security Subsystem is the heart of our security story" ^[6]. 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.

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 ^[2]. AMD Ryzen 6000 was the first silicon to actually ship, at CES 2022 ^[17]. 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 ^[18]. 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 ^{[19] [20]}. "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" ^[19]. 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:

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 ^[2] 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" ^[2]. With Pluton, that communication channel is silicon, not a board trace. Andzakovic-class attacks have nothing to attack ^[3].

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 ^[5], 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 ^[21]. 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 ^{[22] [23]} 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 ^[23]. 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" ^[18]. Memory-safe firmware is a direct response to the firmware-CVE history -- TPM-Fail ^[4], 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.

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" ^[18]. 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" ^[2]. 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.

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 ^[19]); 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'));

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 ^[18]. 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 ^[17] 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 ^[25]. 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 ^[25]. 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" ^{[25] [26]}. 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 ^[18]. This is the first product class where retail-bought Windows 11 hardware turns Pluton on at the factory.

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" ^{[27] [28]}. The driver author was Matthew Garrett ^[28]. 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 ^[21] 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" ^[21]. 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" ^[21]. 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.

The fleet shape, in one comparison table:

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" ^[29]. 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 ^{[29] [30]}. 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 ^[29].

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 ^[31]. 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 ^[31]. 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 ^[29]

Google Titan M / Titan M2 and OpenTitan#

Google announced Titan M with the Pixel 3 launch in October 2018 ^[32]: "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..." ^[32]. Titan M2 followed with Pixel 6 in October 2021 ^[33]. 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" ^[34]. 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 ^[35] -- 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" ^[35]. 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.

Caliptra#

The OCP coalition's open-source datacenter Root of Trust. Specification, RTL, ROM, FMC, and runtime are public on CHIPS Alliance ^{[19] [20]}. 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" ^[19]. 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" ^{[12] [13]} running in Azure datacenters; the GitHub reference implementation ^[11] 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 ^[2] -- 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#

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 ^[1] 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 ^[1]). 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.

Worked example -- CVE-2025-2884#

On June 10, 2025, NVD published CVE-2025-2884 ^[36]. The CERT/CC coordination ticket is VU#282450 ^[37]. 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" ^[37].

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" ^[37]. 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.

Multiple downstream products are affected. Intel published Security Advisory SA-01209 ^[38]. Siemens published SSA-628843 ^[39]. The libtpms project assigned CVE-2025-49133 ^[40] for its own derivative; the upstream fix landed in libtpms commit 04b2d8e9 ^[41]. The TCG itself coordinated VRT0009 ^[42] 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 ^[21] 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.

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

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 ^[19] [@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 ^[43], 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.

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 ^[44]; 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 ^{[25] [26]} 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 ^[46] [@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" ^[47], 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 ^[48] commits SPDM as part of the Caliptra Subsystem reference stack: "Reference Stack: MCTP PLDM, SPDM" ^[48]. 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 ^[18]. 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 ^{[46] [47]}. 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" ^[49]; 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" ^[50]; 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 ^[51]. 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 ^[52]. 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 ^[53]. Caliptra 2.0's reference stack already wires SPDM, MCTP, and PLDM ^[48]; the Caliptra MCU Rust responder shows the SPDM endpoint shape ^[47].

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 ^[54], 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 ^[55] 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 ^{[46] [47]} 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 ^[48]) emits a measurement set tied to its CDI. Third, OCP S.A.F.E. (Security Appraisal Framework and Enablement) v2.0 ^[53] 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 ^[50]. 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 ^[1] 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.

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#

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 ^[1] documents the broader manufacturer-string discovery path. The new Pluton-specific check is the four-letter MSFT value.

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

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 ^[21]). 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 ^[25] -- 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 ^[18]. 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 ^[18]. 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 ^[3], faulTPM-class voltage glitching ^[5]. 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 ^[36]. 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 ^[45], EU sovereign workloads. Hardened dTPM (Infineon SLB 9670 / 9672, STMicro ST33TPHF) has the certified posture ^[56]; Pluton has no equivalent EAL4+ certification path on the public record as of 2026 ^[56].
• 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 ^[19] -- not a Pluton substitute on Windows clients, but the right answer for datacenter SoC procurement.

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.

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" ^[1]. 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.