Microsoft Pluton Explained: Security Processor, TPM 2.0 and Updates

Microsoft Pluton is a security processor that Microsoft designs and AMD, Intel and Qualcomm build into their chips, so the root of trust sits inside the CPU package rather than on a separate motherboard chip. It can act as the PC's TPM 2.0, and its Microsoft written firmware updates through Windows Update and UEFI capsules.

That is the short answer. The longer answer matters if you run a fleet, dual boot Linux, buy laptops by the hundred, or are about to flip a firmware setting called something like "TPM source". Microsoft changed Pluton's role in 2026: on new AMD and Qualcomm silicon from 2026 onward, Pluton no longer serves as the TPM, and TPM 2.0 comes from the chip maker's firmware TPM or a discrete TPM instead. The Pluton processor itself stays. This post walks through what Pluton is, where it came from, how it compares with a discrete TPM and a firmware TPM, how its firmware gets updated, what Linux users should know, and how to check exactly which TPM your machine is using before you change anything.

Key takeaways

• Pluton is a secure subsystem inside the system on chip plus Microsoft authored firmware that runs on it. Microsoft says it is built on technology used in Xbox and Azure Sphere.
• Microsoft lists Pluton on AMD Ryzen 6000, 7000, 8000, 9000 and Ryzen AI Series, Intel Core Ultra 200V Series, Ultra Series 3 and Series 3, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series, all running Windows 11.
• When configured as the TPM, Pluton implements TPM 2.0, so BitLocker, Windows Hello and System Guard use it like any other TPM.
• Its main physical security argument is location: there is no external CPU to TPM bus for an interposer to sniff, which is the attack class the Linux kernel documentation describes against discrete TPMs.
• Pluton firmware lives in SPI flash and loads at early boot; Windows can then load a newer, valid Pluton firmware delivered through Windows Update. UEFI capsule updates also update the flash copy.
• Since 2024, Pluton firmware on AMD and Intel platforms uses a Rust based foundation. Microsoft says it chose the open source Tock operating system as that foundation.
• Beginning with 2026 silicon, Pluton is no longer the TPM on AMD and Qualcomm platforms; existing devices built on 2025 or earlier silicon with Pluton as TPM remain serviced.
• Switching the TPM source in firmware setup gives the operating system a different TPM. Keys sealed to the old one will not unseal on the new one, so back up BitLocker and LUKS recovery keys first.

What Pluton is

Microsoft's own description is compact. Pluton "provides hardware-based root of trust, secure identity, secure attestation, and cryptographic services", and it combines a secure subsystem integrated into the system on chip with Microsoft authored software that runs on it. Microsoft designs it and silicon partners build it. Microsoft describes three layers:

That split is the whole story in miniature. The silicon is made by the chip maker. The firmware is Microsoft's. The interface to the operating system is a TPM 2.0 interface when Pluton is configured as the TPM, plus Pluton specific interfaces that Microsoft says it can extend over time.

Where Pluton came from

Microsoft announced Pluton for Windows PCs on 17 November 2020 on its security blog, together with AMD, Intel and Qualcomm Technologies. The announcement described it as "chip-to-cloud security technology, pioneered in Xbox and Azure Sphere". Microsoft Learn repeats the lineage today: Pluton "is built on proven technology used in Xbox and Azure Sphere".

The two parents explain the two design goals. A games console is a device that an owner has in their hands with full physical access, and the platform owner wants the security processor to keep working even then. Azure Sphere was a Microsoft platform for internet connected microcontrollers, where the security processor's firmware was maintained and updated by Microsoft through a cloud service. The 2020 announcement drew that second connection directly: Pluton for Windows "will be integrated with the Windows Update process in the same way that the Azure Sphere Security Service connects to IoT devices."

Microsoft does not publish the internal block diagram or the exact silicon revision of the Xbox era security processor on the Pluton pages, so treat the lineage as a statement of shared design approach and technology, not as "the same chip".

Which processors include Pluton

Microsoft's current list, from the Pluton overview page last updated 27 May 2026, is:

Two cautions. First, a processor family appearing on this list tells you the security processor is present in the silicon. It does not tell you whether the PC maker enabled it, whether it is configured as the TPM, or which TPM your firmware setup currently exposes. Second, the list moves. Check it again when you buy hardware, and treat any older blog post or forum thread (including this one, after a few months) as a snapshot.

Microsoft also lists the Windows editions and licences that support Pluton: Windows Pro, Enterprise, Pro Education/SE and Education, with licence entitlements under Windows Pro, Pro Education/SE, Enterprise E3 and E5, and Education A3 and A5.

A dated timeline

How Pluton differs from a discrete TPM and a firmware TPM

Microsoft's TPM recommendations page names three ways to build a TPM, and it says plainly that "Windows uses any compatible TPM in the same way":

1. A discrete TPM: a separate chip in its own semiconductor package, usually soldered to the motherboard.
2. An integrated TPM: dedicated hardware in one or more packages alongside other components, but logically separate from them.
3. A firmware TPM (fTPM): the TPM implemented in firmware running in a trusted execution mode of a general purpose computation unit.

The same page also notes that discrete TPMs let the PC maker "evaluate and certify the TPM separate from the rest of the system", while integrated approaches suit small and low power devices. Microsoft says it does not take a position on which implementation should be used.

Pluton, configured as the TPM, belongs to the integrated family: dedicated security hardware inside the SoC, separate from the application cores. A chip maker's firmware TPM runs in that chip maker's own security engine or trusted execution environment; our explainer on Intel CSME and AMD PSP covers those engines in depth. The practical differences are about three things: where the TPM sits, who writes and ships its firmware, and what an attacker with a screwdriver can reach.

The bus problem

A discrete TPM talks to the CPU over what the Linux kernel documentation calls "some type of low bandwidth bus". On PC motherboards those signals run as copper traces between the TPM package and the chipset or CPU. Anyone with physical access, a few minutes and the right probe can watch them.

The Linux kernel's TPM security documentation is unusually direct about this. It describes "passive and active interposer" attacks, where a small device attached to the bus either reads traffic or alters it. It notes that such attacks have been "successfully demonstrated against the Windows Bitlocker TPM system" and against TPM based Linux disk encryption. The problem is not a broken TPM. It is that a TPM releasing a disk encryption key over an unprotected bus to an unauthenticated listener has done exactly what it was told.

Microsoft's 2020 Pluton announcement framed the motivation the same way. Attackers had begun to target "the communication channel between the CPU and TPM, which is typically a bus interface", and the Pluton design "removes the potential for that communication channel to be attacked by building security directly into the CPU." The current Windows security book says the same thing more cautiously: embedding Pluton in the CPU "makes it harder to exploit the communication path."

Harder is the honest word. Moving the root of trust into the package removes the cheap, external, visible bus. It does not make the device immune to all physical attack. Fault injection, decapping and side channels belong to a different and much more expensive category, and Microsoft does not claim Pluton is immune to them.

Two fixes for the same problem

There are two broad responses to bus interposers, and they are not mutually exclusive.

The first is architectural: remove the external bus, as Pluton and firmware TPMs do. The second is cryptographic: keep the discrete TPM, but protect the traffic. TPM 2.0 supports authorization sessions with HMAC integrity checks and parameter encryption. The Linux kernel documentation describes how the kernel now uses them. It derives a primary elliptic curve key from the TPM's null seed, salts its HMAC sessions with that key, uses HMAC protection on PCR extend and read so substituted measurements produce a detectable failure, and uses request and response encryption for commands that carry secrets, such as key sealing and random number generation. It exports the name of that null primary key through sysfs so user space can later certify it against the endorsement key. In the kernel documentation's words, if that key certifies correctly "you know all your TPM transactions since start of day were secure".

That second approach is why "discrete TPM bad, Pluton good" is too simple. A discrete TPM driven by software that encrypts its sessions is in a very different position from one driven by software that sends secrets in the clear.

Comparison table: four kinds of root of trust

Caliptra appears here as the open source comparison point because it is the clearest example of a root of trust whose hardware design is public. Our Caliptra explainer covers it; it is aimed at data center silicon, not laptops.

What Pluton can do as a TPM 2.0, and beyond

When Pluton is configured as the TPM, Microsoft says it "supports the TPM 2.0 industry standard". The TPM 2.0 library specification, published by the Trusted Computing Group, defines the command set, the key hierarchies and the platform configuration registers (PCRs). Any compliant TPM, wherever it sits, offers the same core functions:

• Protected key storage. Keys are created inside the TPM and their private parts are never released in the clear. Software asks the TPM to sign, decrypt or unseal.
• Sealing. Data can be bound to a policy such as specific PCR values, so it is only released when the platform booted in a known state. BitLocker's TPM protector works this way.
• Measurement. PCRs are extended with hashes of each boot component. Our post on TPM 2.0 PCRs and the event log explains what each PCR records.
• Attestation. The TPM signs a quote over its PCR values with a key that chains to an endorsement key certificate, so a remote service can check the boot state.
• Random numbers, monotonic counters, NV storage and dictionary attack lockout.

Windows features that build on the TPM include BitLocker, Windows Hello, System Guard, Credential Guard, Device Health Attestation, the Platform Crypto Provider key storage provider, virtual smart cards and certificate storage, according to Microsoft's TPM recommendations page. That page also notes Microsoft Entra join key attestation needs a TPM with HMAC support and an endorsement key certificate, and that Windows Hello as a FIDO platform authenticator uses TPM 2.0 for key storage. Pluton as TPM provides those through the same interfaces.

What Microsoft says Pluton adds beyond the TPM

Microsoft says Pluton is designed to "deliver other security functionality beyond what is possible with the TPM 2.0 specification", and that more firmware and OS features can arrive over time through Windows Update. Three concrete points come from Microsoft's own pages:

1. SHACK. The 2020 announcement describes Secure Hardware Cryptography Key technology, which "helps ensure keys are never exposed outside of the protected hardware, even to the Pluton firmware itself". That is a stronger property than "keys stay in the TPM": it says the firmware running on the security processor cannot read the raw key either.
2. Isolation from speculative execution. Microsoft says storing keys inside the isolated Pluton processor helps ensure that "emerging attack techniques such as speculative execution can't access key material". This is an argument about not sharing caches and execution units with the application cores.
3. Reliable attestation for conditional access. Microsoft's overview uses device based conditional access in Intune as its worked example: services gate access on TPM reported health, so the TPM's logs must be both tamper resistant and reliably available. Microsoft argues that tight integration between Pluton and Windows improves that reliability.

Microsoft also says Pluton can be used either as the TPM 2.0 or "as a standalone security processor". That matters more after the 2026 change.

The 2026 change: Pluton stops being the TPM on new AMD and Qualcomm silicon

Microsoft's "Pluton as TPM" page, updated 16 September 2026, carries an important note. Beginning with 2026 silicon, Pluton no longer serves as the TPM on AMD and Qualcomm platforms. On those platforms, and on Intel, TPM 2.0 functionality comes from the vendor's firmware TPM or a discrete TPM. Devices built on 2025 or earlier AMD and Qualcomm silicon that shipped with Pluton as the TPM "remain fully serviced and supported". The change affects only Pluton's TPM role; Microsoft says the Pluton processor "will continue to be present and supported on existing and future Windows devices to provide a hardware isolated security environment for Windows."

What this means in practice:

• On a 2026 or later AMD or Qualcomm laptop, tpm.msc and Get-Tpm should report the chip maker's firmware TPM or a discrete TPM, not Pluton, even though Pluton is in the silicon.
• Fleet inventories that use "TPM manufacturer = Microsoft" as a proxy for "has Pluton" will undercount from 2026 onward. Record CPU family and TPM manufacturer as separate fields.
• Bus exposure depends on which TPM is chosen. A firmware TPM keeps the no external bus property; a discrete TPM reintroduces the bus, so session protection in the OS matters again.
• Mixed fleets will have three TPM populations: discrete, chip maker firmware TPM, and Pluton TPM on 2025 and earlier silicon. Attestation policies and recovery runbooks need to cover all three.

Microsoft's page does not give a reason for the change, and we will not guess at one.

How Pluton firmware is updated

Firmware is the part of a root of trust that most often needs fixing, and NIST SP 800-193 is built around that fact. Its three principles for platform firmware are protection against unauthorized changes, detection of unauthorized changes, and recovery to a known good state. Microsoft's design for Pluton updates speaks to all three.

Microsoft describes two update paths:

1. UEFI capsule updates. Pluton firmware is stored in the SPI flash on the motherboard and loaded during early system boot. Microsoft says Pluton supports "the typical mechanism of UEFI capsule updates that update the Pluton firmware that is resident on the system's SPI flash". In practice that means the PC maker's system firmware update can carry a new Pluton firmware image.
2. Operating system loaded firmware. During Windows startup, Windows loads "the latest version of the Pluton firmware". If a newer, valid firmware has been delivered through Windows Update, Windows uses it; if not, Windows uses the firmware that was loaded at hardware initialization.

The firmware load flow, step by step

Microsoft says the dynamic path exists to deliver "continuous improvements both for bug fixes and new features." The 2020 announcement framed the bigger problem as fragmented firmware supply: customers "receive updates to their security firmware from a variety of different sources", which made patching uneven. The Windows security book adds that Pluton is integrated with Windows Update, "benefiting from over a decade of operational experience in reliably delivering updates across over a billion endpoint systems."

What this means for administrators

• One more update channel to track. Pluton firmware can change without a BIOS update. Treat Windows Update driver and firmware categories as security relevant on Pluton devices, and do not block them across the fleet without a plan for security processor fixes.
• The SPI flash copy still matters. Early boot measurements and pre OS operations use the SPI flash copy. Keep OEM UEFI firmware current so the flash baseline is not years old.
• Record versions. Get-Tpm returns ManufacturerVersion and ManufacturerVersionFull20. Logging these across the fleet over time is the simplest way to see firmware changes land.
• Rings and pilots. Firmware that backs BitLocker and Windows Hello deserves a pilot ring like any other low level update.

What this means for Linux users

Microsoft's dynamic loading path is described as part of Windows startup. Microsoft's pages do not describe a Linux equivalent, so on a machine that only runs Linux, assume the Pluton firmware you get is the SPI flash copy, updated through the PC maker's UEFI capsule updates. On Linux, install those capsules with whatever firmware update route your PC maker supports for Linux, which may be a distribution firmware update tool or the maker's own boot time updater; Microsoft's pages do not cover this.

On the TPM side, a TPM 2.0 is a TPM 2.0. If Pluton is configured as the TPM, the kernel sees a TPM 2.0 device exposed through ACPI, and user space tools such as tpm2-tools and systemd's TPM integration work against /dev/tpmrm0 as they would with any other TPM. Driver support arrived in Linux 6.3, released on 23 April 2023, whose changelog lists "tpm_crb: Add support for CRB devices based on Pluton". On distribution kernels older than that, a Pluton TPM may not appear at all. If /sys/class/tpm/ is empty on a Pluton machine, check your kernel version and the firmware setup TPM source before concluding there is no TPM.

Dual boot machines are the subtle case. Windows may load a newer Pluton firmware for its own session than the copy Linux sees after a reboot into Linux. That is by design, but it means Linux side firmware reports and Windows side reports can legitimately disagree.

Can Pluton be disabled, and what happens to TPM keys if you switch

Whether Pluton can be turned off, and what the setting is called, is decided by the PC maker's firmware. Microsoft's Pluton pages describe what Pluton is and how it is configured as the TPM, but they do not document a universal switch. Microsoft's TPM troubleshooting page confirms the general case: "Some systems may have multiple TPMs and the active TPM may be toggled in UEFI." On Pluton capable systems that usually means a choice between Pluton and the chip maker's firmware TPM. Check your PC maker's documentation for the exact menu name and its default.

Switching TPM source has one consequence that does not depend on the PC maker: the operating system now talks to a different TPM. Each TPM has its own seeds, its own endorsement key and its own storage hierarchy. Anything sealed to the old TPM cannot be unsealed by the new one. Concretely:

Microsoft's BitLocker recovery documentation lists, among common recovery triggers, "Turning off, disabling, deactivating, or clearing the TPM", "Hiding the TPM from the operating system" and "Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade". That is the feature working as intended: a different TPM means the old trust anchor is gone.

Microsoft's guidance on systems with two TPMs

Microsoft's TPM initialization page has a short section on exactly this situation. It says some systems may have multiple TPMs with the active one toggled in UEFI, and that "Windows doesn't support this configuration." If you switch, Windows might not properly detect or interact with the new TPM. Microsoft's instruction for a planned switch is to toggle to the new TPM, clear it, and reinstall Windows, and it notes that toggling TPMs causes BitLocker to enter recovery mode. Its recommendation is that on systems with two TPMs, one is selected and the selection is not changed.

Read that literally. A TPM source switch on Windows is a rebuild event, not a settings tweak. Pick the TPM when the device is first provisioned, record the choice, and leave it. Switching back does not reliably undo the damage either: if Windows has re provisioned the TPM, or if the original TPM was cleared, the original keys are gone too.

What Pluton firmware is written in now

Microsoft says Pluton platforms in 2024 AMD and Intel systems "will start to use a Rust-based firmware foundation given the importance of memory safety." The Windows security book goes further: Microsoft "chose the open-source Tock system as the Rust-based foundation to develop the Pluton security processor firmware and actively contribute back to the Tock community."

Tock is an embedded operating system written in Rust for low power, low memory microcontrollers. Its project site describes it as designed for "running multiple concurrent, mutually distrustful applications" and names "Security critical devices, like TPMs and USB authentication fobs" as a use case, noting that such devices are really multiprogramming environments running code written by different people. Tock's design isolates the kernel, its drivers (called capsules) and user processes so that a buggy or crashing component cannot leak another's secrets.

Why that matters for a root of trust:

• Memory safety bugs are a large share of firmware security bugs. A TPM parses attacker influenced input: commands from the OS, and from the bus on discrete parts. Writing the parser and command handlers in a memory safe language removes whole classes of bugs, such as buffer overflows and use after free in safe code.
• Isolation between components. Pluton provides TPM functions and other Microsoft features. Running them as isolated components on a microkernel style OS limits the reach of a bug in any one.
• Open foundation, closed product. Tock is open source; Pluton firmware built on it is Microsoft's and is not published. You can read and review the operating system, not the TPM implementation on top of it.

If you are planning memory safe firmware in your own products, our memory safe languages for firmware post covers the adoption path.

Step by step: check which TPM you have before changing firmware settings

Do this before any firmware update, TPM source change, BIOS reset or motherboard swap. The goal is a written record of TPM manufacturer, firmware version, specification version and recovery keys, saved somewhere other than the machine.

Windows: tpm.msc

1. Press Windows key plus R, type tpm.msc, press Enter.
2. Read the status line and confirm the TPM is ready for use.
3. In the manufacturer information section, note the manufacturer name, manufacturer version and specification version. The PowerShell commands below return the same values in a form you can save.

Windows: PowerShell

Open PowerShell as administrator.

# Summary of TPM state, manufacturer ID and firmware version
Get-Tpm

# The same data through CIM, including the spec version string
Get-CimInstance -Namespace root/cimv2/security/microsofttpm -ClassName Win32_Tpm |
  Select-Object ManufacturerId, ManufacturerVersion, ManufacturerVersionInfo, SpecVersion

# CPU model, so you can match it to Microsoft's Pluton processor list
Get-CimInstance Win32_Processor | Select-Object Name

ManufacturerId is a 32 bit number holding four ASCII characters. Microsoft's own Get-Tpm example shows ManufacturerId : 1229870147 and ManufacturerIdTxt : INTC. Here is the conversion, so you can decode any value yourself:

1229870147 decimal = 0x494E5443 hex
0x49 = 'I'   0x4E = 'N'   0x54 = 'T'   0x43 = 'C'   ->  "INTC"

A firmware TPM usually reports the chip maker's code and a discrete TPM reports the TPM chip vendor's code. Microsoft's Pluton pages do not print the code a Pluton TPM reports, so do not guess: the Trusted Computing Group publishes the registry of TPM vendor IDs, and you should check the decoded string against it and against the CPU model.

Windows: BitLocker recovery keys before anything else

# Show protectors and the numeric recovery password for C:
manage-bde -protectors -get C:

# If there is no numeric recovery password protector, add one
manage-bde -protectors -add C: -RecoveryPassword

# For a planned firmware update (not a TPM source switch), suspend BitLocker for one reboot
Suspend-BitLocker -MountPoint "C:" -RebootCount 1

Store the 48 digit recovery password outside the machine: your directory service or device management, a password manager, or printed and locked away. Suspending BitLocker is for a firmware update that keeps the same TPM. It does not save you from a TPM source switch, because the new TPM never held the key; for a switch, you need the recovery password to unlock once and then re add a TPM protector on the new TPM.

Linux: is there a TPM, and which one

# Is a TPM device registered?
ls -l /sys/class/tpm/
cat /sys/class/tpm/tpm0/tpm_version_major      # expect 2

# What the kernel logged while probing it
sudo dmesg | grep -i tpm

# Manufacturer, vendor strings and firmware version (tpm2-tools)
sudo tpm2_getcap properties-fixed | grep -A3 -E \
  'TPM2_PT_MANUFACTURER|TPM2_PT_VENDOR_STRING|TPM2_PT_FIRMWARE_VERSION|TPM2_PT_FAMILY_INDICATOR'

# Which TPM systemd can see for disk unlocking
systemd-cryptenroll --tpm2-device=list

tpm2_getcap properties-fixed prints the fixed properties, including TPM2_PT_MANUFACTURER with the same four character code Windows shows. Save the output to a file named after the host and date.

Linux: LUKS recovery before a TPM change

Adding a recovery key does not erase data, but you are pointing a tool at a block device, so confirm the device path first.

# 1. Confirm which partition is the LUKS container. Check size, type and mount point.
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
sudo cryptsetup isLuks /dev/nvme0n1p3 && echo "LUKS confirmed on nvme0n1p3"

# 2. See which key slots and tokens exist (look for a systemd-tpm2 token)
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -E 'Keyslots|Tokens|systemd-tpm2' -A2

# 3. Add a recovery key and store it off the machine
sudo systemd-cryptenroll --recovery-key /dev/nvme0n1p3

Replace /dev/nvme0n1p3 with the device you confirmed in step 1. Never wipe or re enroll slots until you have tested that the recovery key opens the volume.

After the change: re enroll on the new TPM

On Windows, follow Microsoft's guidance for systems with two TPMs: after toggling to the new TPM, clear it from within the operating system and reinstall Windows, restoring user data from backup. Microsoft says to use operating system functionality such as tpm.msc to clear a TPM, not UEFI. If you are recovering a machine where the switch already happened, the recovery password gets you into the volume so you can copy data off before the rebuild. On Linux, after confirming the device path again, remove the stale TPM2 token and enroll the new TPM:

sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p3

--wipe-slot=tpm2 removes only TPM2 slots, but it is still a destructive operation on key slots. Run it only after the recovery key from the previous step has been tested.

A record worth keeping

Common mistakes

Switching TPM source without recovery keys. This is the most expensive mistake on the list. The new TPM never held your BitLocker or LUKS key. Without the recovery password or a passphrase slot, the data on that disk is unrecoverable by design.

Assuming Pluton means DRM. Microsoft's documentation describes Pluton's roles as hardware root of trust, secure identity, attestation, cryptographic services and TPM 2.0. Discussions about remote attestation and owner control of hardware are legitimate policy debates, and every TPM, discrete or integrated, can attest. But "Pluton exists to enforce DRM" is not something Microsoft's Pluton pages say, and decisions should be based on what the documented features are.

Assuming a discrete TPM is always more secure. A discrete TPM can be certified separately, and that has real value. But it talks over an external bus, and the Linux kernel documentation describes successful interposer attacks against disk encryption on such systems. A discrete TPM with HMAC protected, encrypted sessions is in a better position than one without. Pick based on your threat model, not the form factor.

Assuming an integrated TPM is immune to physical attack. Removing the bus closes a cheap attack. It does not close fault injection, side channel analysis or invasive attacks on the die, which need more skill and equipment. Keep a PIN or other pre boot factor for high risk devices.

Using "TPM manufacturer = Microsoft" as a Pluton inventory proxy. From 2026 silicon on AMD and Qualcomm, Pluton is present but is not the TPM. Inventory CPU family and TPM manufacturer separately.

Blocking all Windows firmware updates. Pluton firmware fixes can arrive through Windows Update. A blanket block on firmware and driver categories also blocks security processor fixes.

Ignoring the SPI flash copy because Windows loads a newer one. Pre OS operations and Linux sessions use the flash copy. Keep OEM UEFI firmware current.

Clearing the TPM to "fix" a problem. Microsoft warns that clearing the TPM loses all keys created with it and the data they protect, such as a virtual smart card or a sign in PIN. It also says to clear the TPM from the operating system, for example with tpm.msc, and not directly from UEFI. Back up recovery keys before clearing, and clear only when you know what depends on it.

Running old kernels on new hardware. If Linux shows no TPM on a Pluton machine, the kernel may predate the Linux 6.3 driver support. Update before changing firmware settings.

Where Safeguard fits, honestly

Safeguard does not inspect TPMs, scan firmware or manage devices, and it does not analyze hardware. Pluton, firmware TPMs and discrete TPMs are outside what Safeguard examines. The connection is one level up: the software that uses the TPM. Disk encryption tooling, attestation agents, TPM libraries such as the open source tpm2 software stack, and the applications your team builds on top of them are all ordinary software with open source dependencies. When you rebuild a fleet image after a firmware or TPM change, those packages get pulled and pinned again, and that is where software supply chain hygiene applies.

Rebuilding laptops and servers after a TPM change means reinstalling agents and tooling, and much of that tooling ships open source components that need the same vulnerability tracking as any application. The steps below apply to those open source dependencies and container images, not to Pluton's firmware, which only Microsoft and the PC maker can fix.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The Safeguard CLI is an interactive terminal assistant. In this real session it is asked to fix a lodash CVE, reads the finding and the advisory, asks before any command that changes something, edits package.json, runs the install and tests with approval, and pushes nothing. The same flow applies to the attestation agents and TPM related tooling your team maintains: point it at the repository and fix a vulnerable dependency without leaving the terminal.

Click through it at your own pace, or open it full screen.

The local runner lets you scan on your own machine. You set it up, approve it with a device code, then scan from the terminal. For teams rebuilding a golden image after a firmware change, that is a way to check the image's software inventory locally before it goes back out.

Click through it at your own pace, or open it full screen.

You can also connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. If you keep a TPM and firmware runbook in a chat workflow, this shows how to bring Safeguard's software findings into the same conversation, with you choosing exactly what Claude may call.

Click through it at your own pace, or open it full screen.

To try it, download Safeguard or read the CLI documentation.

FAQ

Is Microsoft Pluton the same as a TPM?

Not exactly. Pluton is a security processor inside the system on chip. It can be configured to act as the TPM 2.0, and on many systems built on 2025 or earlier silicon it is. It can also run as a standalone security processor while a firmware TPM or discrete TPM provides TPM 2.0, which is the arrangement Microsoft describes for new AMD and Qualcomm silicon from 2026.

Which CPUs have Microsoft Pluton?

Microsoft lists AMD Ryzen 6000, 7000, 8000, 9000 and Ryzen AI Series; Intel Core Ultra 200V Series, Ultra Series 3 and Series 3; and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series. Check the Microsoft Learn page for the current list before buying.

How do I know if my PC is using Pluton as its TPM?

Open tpm.msc or run Get-Tpm in PowerShell and look at the manufacturer. Decode the ManufacturerId into its four characters and compare it with the TCG vendor ID registry. On Linux, tpm2_getcap properties-fixed shows the same field. Also check firmware setup for a TPM source option.

How is Pluton firmware updated?

Two ways. The copy in SPI flash is updated by UEFI capsule updates from the PC maker. In addition, Windows can load a newer valid Pluton firmware delivered through Windows Update during startup; if none is available, it uses the flash copy.

Does Pluton work on Linux?

When Pluton is configured as the TPM, Linux sees a TPM 2.0 device if the kernel includes the driver support, which arrived in Linux 6.3 in April 2023. Microsoft's dynamic firmware loading is described as a Windows feature, so Linux only systems rely on UEFI capsule updates for the flash copy.

Can I turn off Microsoft Pluton?

It depends on the PC maker's firmware. Microsoft notes that some systems have multiple TPMs with the active one toggled in UEFI, and PC makers name that setting differently. Back up BitLocker or LUKS recovery keys first, because switching TPM source makes keys sealed to the old TPM unusable.

Will switching from Pluton to fTPM trigger BitLocker recovery?

Yes. Microsoft says toggling TPMs causes BitLocker to enter recovery mode, because the new TPM never held the key. You will need the 48 digit recovery password. Microsoft also says Windows does not support switching between two TPMs and recommends clearing the new TPM and reinstalling Windows if you switch.

Is Pluton more secure than a discrete TPM?

It removes the external CPU to TPM bus, which closes cheap interposer attacks. A discrete TPM can be certified on its own, and the risk from its bus can be reduced with HMAC protected, encrypted sessions. Which is better depends on your threat model and how your OS uses the TPM.

What language is Pluton firmware written in?

Microsoft says Pluton platforms in 2024 AMD and Intel systems started using a Rust based firmware foundation, and that it chose the open source Tock operating system as that foundation.

Is Pluton used for DRM?

Microsoft's Pluton documentation describes root of trust, secure identity, attestation, cryptographic services and TPM 2.0 functions. It does not describe DRM as a purpose. Like any TPM, Pluton can support remote attestation, which some people view as a policy concern.

Quick check

Sources

• Microsoft Learn: Microsoft Pluton security processor
• Microsoft Learn: Microsoft Pluton as Trusted Platform Module
• Microsoft Security Blog: Meet the Microsoft Pluton processor (17 November 2020)
• Microsoft Learn: Windows security book, hardware root of trust
• Microsoft Learn: Windows security book, silicon assisted security
• Microsoft Learn: TPM recommendations
• Microsoft Learn: Trusted Platform Module technology overview
• Microsoft Learn: Get-Tpm
• Microsoft Learn: BitLocker recovery overview
• Linux kernel documentation: TPM security
• Linux kernel documentation: Trusted Platform Module
• tpm2-tools on GitHub
• tpm2-tools: tpm2_getcap manual
• Tock embedded operating system
• NIST SP 800-193, Platform Firmware Resiliency Guidelines
• Microsoft Learn: Troubleshoot the TPM (initialization, systems with multiple TPMs, clearing)
• Microsoft Learn: Win32_Tpm class
• Kernel Newbies: Linux 6.3 changelog
• systemd-cryptenroll manual

Last reviewed: 25 October 2026. Pluton platform support and TPM roles change with new silicon; check the linked Microsoft pages for the current status.