
In upcoming Intel, Qualcomm, and AMD processors, there is going to be a new chip, built-in to the CPU/SoC silicon die, co-developed by Microsoft and AMD called the Pluton. Originally developed for the Xbox One as well as the Azure Sphere, the Pluton is a new security (cynical reader: DRM) chip that will soon be included in all new Windows PCs, and is already shipping in mobile Ryzen 6000 chips.
This new chip was announced by Microsoft in 2020, however details of what it was actually capable of, and what it actually means for the Windows ecosystem were kept frustratingly vague. Now with Pluton rolling out in some AMD chips, it is possible to put together a cohesive story of what Pluton can do from several disparate sources.
Because Microsoft’s details are sparse, this article will attempt to summarize all that we now know regarding Pluton. It may contain inaccuracies or speculation, but any potential inaccuracy or speculation will be called out where possible. If there are inaccuracies that result in more, better information being found, so be it.
What’s inside Pluton?
Pluton encompasses several functions. I’ll be throwing out the acronyms first and some of their meanings and effects later in the article:
- A full TPM 2.0 implementation, developed by Trusted Computing Group (TCG)
- SHACK (Secure Hardware Cryptography Key) implementation
- DICE (Device Identifier Composition Engine) implementation, also designed by TCG
- Robust Internet of Things (RIoT) specification compliance, a specification developed by Microsoft and announced with almost no fanfare all the way back in 2016
However, besides these functions, Pluton implements the full breadth of security improvements that Microsoft used to only have on the Windows 10 Secured-Core PC systems. A Pluton system is a superset of the Secured-Core PC specification which was previously only on select systems. A Secured-Core PC requires the following additional technology measures that were not previously required for a standard PC:
- Dynamic Root of Trust for Measurement (DRTM)
- System Management Mode (SMM) (edit: with Device Guard, regular computers have long had SMM)
- Memory Access Protection (Kernel DMA Protection, protects against
PlundervoltThunderspy) - Hypervisor Code Integrity (HVCI)
Edit: See update at the bottom of post, the overlap of Secure Core and Pluton is currently somewhat unclear.
Also, starting this year, new Secured-Core PCs (and Pluton PCs by extension?) will also be required to drop support for the Microsoft 3rd-party UEFI Secure Boot Certificate Authority by default. This means that the shim bootloader used for booting some Linux OSs will no longer be trusted without flipping a switch in the UEFI firmware, which may partly be why Lenovo and Dell have announced they are keeping Pluton disabled by default. However, this might not do much in the long run, as will be explored below.
It is important to note that Pluton is very much like the Secure Enclave or TrustZone systems on macOS/iOS/Android systems, with a full (secure) CPU core, its own small onboard RAM, ROM, RNG, fuse bank, and so forth. For (obvious) security reasons, Pluton only boots officially-signed Microsoft firmware and carries anti-downgrade protections inherited from the Xbox. On non-Windows systems like Linux, Pluton quietly degrades into only a generic TPM 2.0 implementation.
A lot of acronyms, but what is the big picture?
In a nutshell, Microsoft believes they need to exercise more control over PC Security than previously. This came up with Windows 11, which infamously required 8th Gen or newer CPUs, TPM 2.0, and Secure Boot capability. At the time, there was (and still is) much concern regarding the almost arbitrary nature of the requirements.
However, while Microsoft was terrible at defining why certain CPUs made the cut and others didn’t (like why no Zen 1?), Ars Technica noticed a pattern:
Windows 11 (and also Windows 10!) uses virtualization-based security, or VBS, to isolate parts of system memory from the rest of the system. VBS includes an optional feature called “memory integrity.” That’s the more user-friendly name for something called Hypervisor-protected code integrity, or HVCI. HVCI can be enabled on any Windows 10 PC that doesn’t have driver incompatibility issues, but older computers will incur a significant performance penalty because their processors don’t support mode-based execution control, or MBEC.
And that acronym seems to be at the root of Windows 11’s CPU support list. If it supports MBEC, generally, it’s in. If it doesn’t, it’s out. MBEC support is only included in relatively new processors, starting with the Kaby Lake and Skylake-X architectures on Intel’s side, and the Zen 2 architecture on AMD’s side—this matches pretty closely, albeit not exactly, with the Windows 11 processor support lists.
Windows 11, by (almost) requiring MBEC, TPM 2.0, Secure Boot capability, and so forth is in every way trying to get people used to a Pluton-lite experience, as “Pluton-y” as possible without actually having Pluton yet. Windows 11 is the “stepping stone” to Pluton with security requirements to match. With Windows rumored to return to the 3-year version cycle with Windows 12 in ~2024, and with Microsoft clearly being less afraid of cutting off large swaths of old PCs, it would not shock me if Windows 12 makes Pluton a system requirement. Windows 10 for old systems, Windows 11 for systems not quite there, Windows 12 for the endgame.
Anything more I should know about what Pluton aims to do?
I’ve thrown out the acronyms for those interested in further reading, but what are the design goals behind those acronyms?
Microsoft originally developed Pluton for the Xbox, but also for the Azure Sphere. When they developed the Azure Sphere chip for secure IoT Devices, they designed it to be in compliance with their “Seven Properties of Highly Secure Devices“:

Microsoft also in that document shares how Pluton was integrated with this MediaTek IoT Chip, which looks probably pretty similar to how it is being integrated in Intel/AMD/Qualcomm:

It is not perfectly possible to implement Azure Sphere levels of security in a Windows PC. On Azure Sphere, a device becomes permanently locked to one manufacturer’s account permanently and only runs one app, with absolutely no ability to boot alternative apps or operating systems. Microsoft is no doubt going to need to compromise Pluton for general-purpose computing, but by how much…
All put together, what are the effects on me when Pluton arrives?
- You will no longer be able to install Linux with Pluton enabled unless the Microsoft 3rd-party UEFI Certificate is enabled in your UEFI Firmware. See Microsoft’s 7 Principles #5. (Also see update below at bottom of post – this status is ambiguous as Pluton and Secured Core kind of overlap.)
- Pluton will integrate with Windows Update at least for system firmware, potentially allowing for some forms of drivers to be updated as well as potentially having downgrade prevention. This may partly be why Windows 11 has new driver requirements (DCH compliance). See Microsoft’s 7 Principles #3, #6, and possibly #7.
- With SHACK, Secret Keys will be able to be stored in hardware and be able to encrypt and decrypt material without the key ever being exposed to firmware or software. This allows for a potentially stronger BitLocker… or just plain old DRM. See Microsoft’s 7 Principles #2.
- DICE+RIoT is where the rubber really hits the road. In Microsoft’s documentation of what RIoT can do:

Meanwhile, DICE appears to share a lot of the same goals as RIoT:


DICE and RIoT appear to be different parts of the same solution: Providing a device-specific key and assertion capabilities. What’s more, consider when it is combined with SMM and DRTM:

Why is a DICE+RIoT+SMM+DRTM sandwich so potentially extremely dangerous? Imagine if you are a game developer who wants to prevent cheating. According to IEEE’s interpretation, it could be possible to use Pluton to irrefutably verify (aka “assert”) that:
- The device is running Windows,
- The device is up-to-date or recently updated,
- The device has not had Secure Boot disabled or tampered with
Part #3 is most important. When you combine #3, the ability to have the Pluton security processor assert that the device has booted with Secure Boot in accordance with Microsoft’s 7 Principles #5 using the sandwich, and a potential custom kernel module for anti-cheat, you have successfully proven cryptographically:
- The device has securely booted,
- Your kernel module has loaded,
- Your kernel module, and Windows itself, has absolutely not been tampered with in any way
- Windows is up-to-date with all or most security features enabled,
- By having Hypervisor-powered Code Integrity through HVCI/MBEC, injecting code will be extremely difficult even if the code is flawed or contains exploits
If you were a DRM designer, you would probably be drooling. No more workarounds or hacks – its an on-silicon, Xbox-proven solution, now on Windows. Microsoft, of course, doesn’t want to talk about that use-case and says that it will primarily be used by their Azure Attestation Service and allowing businesses to keep devices up-to-date and secure, but the road to Hell is paved with good intentions. As IEEE has noted citing personal conversations with Microsoft Engineers, any attestation service could use Pluton for their own ends, as DICE+RIoT are both open standards for this kind of thing. In fact, Microsoft’s use of open standards for assertions might make this more dangerous in my opinion.
(Note: Please see later in post for edits regarding TPM capabilities)
Doomsday and “Fearmongering” Speculations Below – Objectively verified knowledge ends here
What is to prevent school WiFi from one day requiring a Pluton assertion that your Windows PC hasn’t been tampered with before you can join the network? As far as I can tell from the above specifications, there is no reason, assuming that the school had the ability to provide a connection client app before connecting.
Microsoft’s other use of DICE+RIoT, in their own words, is to enable “Zero Trust Computing.” By giving every device the ability to have secret keys completely out of reach of the main processor (see 7 Security Principles #2 and #5), it is theoretically possible to create documents, messages, and other content that is completely unreadable except by a specific device using a key that cannot be extracted from that device.
Imagine thus, a different scenario from the game developer. Imagine a (maybe corrupt) government agency or business. In the not-too-distant future, the following could be possible with Pluton (with some custom app development to streamline everything together):
- All devices in the network have Pluton and are enrolled in Azure.
- Every time a document is created and added to the network, it is added with a Pluton certificate verifying who created the document. Anonymous documents are kept off the network.
- Every user in the organization is in Azure through Active Directory, and has specific devices attached to their User. Their User is enrolled in specific groups, such as Accounting or Legal.
- Documents are encrypted through Azure to be only readable on specific client devices using the device-specific public key.
- Thus, employees can read approved documents, but only on authorized systems.
To put this together, imagine this hypothetical scenario. A user in Legal creates a document. When the user uploads it, Azure verifies it against Pluton to both verify the document as being likely clean, and also to firmly establish who created it. When another user wants to download the document, Azure only provides a version that has been encrypted with the user’s Pluton public key if that user belonged in the right department, and thus only readable by that user.
- These authorized systems could contain MDM (Mobile Device Management) measures that, thanks to Pluton with Secure Boot and physical attack protection, cannot be disabled. It also cannot easily have code injected or bypasses installed due to the Hypervisor. Pluton will also, in this situation, likely enforce BitLocker with an unknown unlock key.
- The system is tamper-resistant and constantly updated, meaning that should a strict MDM policy be in place, extracting documents from a system without authorization could be potentially extraordinarily difficult to impossible.
Now, Microsoft might look at the above and laugh this off as fear mongering, as that is much further than what Pluton is being pitched as right now, as a firmware security device to prevent malware. However, how far away is it actually? If you can have Pluton verify a system as Securely booted without tampering, encrypt and decrypt material with an unextractable key, and connect to Azure for firmware updates, how much harder is it to add a secure mode to Microsoft Office that pulls it all together? You can’t hack Microsoft Office’s read-only or other protection modes if your MDM blocks external apps, the hypervisor prevents code injection, you can’t mess with Secure Boot without your keys getting invalidated, and your document is encrypted with a key only your device has that cannot be extracted.
The road to Hell is paved with good intentions. It looks as though Microsoft’s Next-Gen Secure Computing Base / Palladium project never really died.
Updates
A Linux Kernel engineer on Hacker News (@mjg59) claims that “Secured Core” PCs and Pluton are not synonymous. This would mean that certain features mentioned in the “Secured Core” list would not be present on all systems with Pluton.
I am currently unable to verify this claim (or my original view that the two were inseparable), due to the lack of hardware with Pluton out there, and also because it appears that (all?) hardware with Pluton also implements Secured Core right now, but perhaps Pluton w/o Secured Core systems will emerge. I am open to being incorrect on this though – as the lack of information regarding Pluton means I am stumbling in the dark for information.
I also currently do not buy his argument fully as of yet because he also argues most of what Pluton can do could also be implemented with just a TPM 2.0 chip. This may be true – however, this also leaves the actual purpose of Pluton unclear and possibly very redundant, and it doesn’t address what Microsoft means in their blog post by “chip-to-cloud” security that wasn’t possible before. If it wasn’t possible before, and is now, what changed if nothing changed? Is this Microsoft making a huge amount of fuss over just a remotely-updatable TPM 3.0?
The Kernel Engineer responded to that by stating that Pluton is a more-secure TPM, because it is built-in to the silicon, and because Microsoft wanted a more secure, easily updatable security chip than the Intel ME / AMD PSP which have had issues previously and are harder to update. This doesn’t make much sense to me – is it really hard to implement a separate TPM outside of ME/PSP that just does TPM things and gets Windows Updates? It’s really easier and more trustworthy just to add an entire new security processor to an actual chip CPU and adjust that design to various node sizes because Intel and AMD can’t implement any secure interfaces of their own? I don’t buy it. Intel would probably have vastly preferred that, then it could have just been marketed as a new vPro feature.
@mjg59 takes the view that Pluton is not (currently) a threat to user freedom, stating to my doomsday scenario:
(Edit: it’s been pointed out that I kind of gloss over the fact that remote attestation is a potential threat to free software, as it theoretically allows sites to block access based on which OS you’re running. There’s various reasons I don’t think this is realistic – one is that there’s just way too much variability in measurements for it to be practical to write a policy that’s strict enough to offer useful guarantees without also blocking a number of legitimate users, and the other is that you can just pass the request through to a machine that is running the appropriate software and have it attest for you. The fact that nobody has actually bothered to use remote attestation for this purpose even though most consumer systems already ship with TPMs suggests that people generally agree with me on that)
I do not agree with him on that and Hacker News considers that to be naive, and to me it screams “it could – but it won’t!,” but there is no reason he couldn’t be right. Read it as an optimistic scenario. It’s hard to be optimistic though when SafetyNet exists.
On that note however, there are some things that he has stated that are accurate that weren’t in the original story. This is not malice on my part (as, well, why would I update this blog to refer to his views?) but rather a lack of information:
- Original version of this post believed that Pluton is a de-facto Secured Core PC implementation. This is corrected, we don’t know whether this is the case, and do not currently know of proof either way. I personally doubt that Microsoft intends “Secured Core” to remain around forever and won’t mandate parts of it slowly.
- I misread the checkbox on the Microsoft documentation regarding SMM. SMM has been around forever, but Secured Core PCs require SMM with Device Guard whereas standard Windows does not – and Microsoft’s documentation for Secured Core then just has SMM (with Device Guard) unchecked on the requirements which I misread as no SMM. Oops.
- Apparently DICE and extensions are a… simpler way of doing the exact same things as a TPM? I can’t quite follow why anyone would want that. He did not have much explanation for what Pluton needed RIoT for and (it appears) initially did not believe RIoT was in Pluton, but then he said it is probably just for IoT scenarios. I’m a skeptic. Could PCs one day be managed like IoT?
- I think the engineer’s main criticism is that I got some details regarding TPM wrong (in that TPM is more capable than I thought), and that much of what is stated above can already be accomplished with just a TPM but hasn’t been (and, in his view, probably never will be, though I disagree and believe Pluton makes it easier in the future). In which case my “fear and despair” part was may have actually been underselling what Pluton specifically can do and means long-term.
- Because of that, I think my new criticism of Pluton would be the following (which he has not responded to despite responding to others later multiple times):
At this point, even if a TPM can recreate much of Pluton’s functionality, I still believe some fear regarding Pluton is still necessary and healthy, although I do not dispute that for some uses it may be useful – after all, why was my fear mongering section explicitly labeled “Fearmongering and Doomsday speculations”? Microsoft can still screw people over, but Pluton is different from a TPM and should still be (generally) regarded with caution where possible, and more caution than a standard TPM.
This is mainly because, at this point,
A. A TPM’s level of access and capabilities to a system is well-known at this point. Pluton, we do not know with certainty what all of its capabilities are.
B. Microsoft has explicitly stated Pluton will have functionality added to it in the future though software updates, most likely that cannot be downgraded, that are not present yet. It’s not that Pluton might have stuff added later – Microsoft has said stuff will be added later. What these upgrades entail or are capable of is also unknown.
C. Because of the above, Pluton requires a previously-unknown level of trust for Microsoft, because Pluton almost certainly has anti-downgrade procedures. Microsoft could, potentially, send out an update just blocking Linux and if Pluton received the update, it would be irreversible. Maybe this isn’t within Pluton’s abilities, but we just don’t know. Just that Microsoft (or a hacker of Microsoft – I’m more concerned about a rogue employee than Microsoft at the moment) could have permanent effects on the security of a system is worth paying attention over.
D. Because of the reasons above, Pluton should be regarded with extra skepticism as it is a magical black box, with unknown capabilities, that it is not clear whether it can actually be disabled. (Already on my blog, there’s a user talking about how Pluton briefly boots and then disables itself if the UEFI says that it should be disabled, not that it never starts, so theoretically a Pluton update could ignore its own disable switch.) I don’t have verification of that, but until we know more… TPM is known, TPM can screw people, Pluton has the potential to extremely screw people over, and while many of my doomsday speculations can actually be recreated with just a TPM if TPMs are widely adopted, perhaps it could be enhanced with more Pluton-specific ones. Perhaps my doomsday predictions actually weren’t far enough.
Thus, your point that Pluton doesn’t add too much might be completely valid right now. That doesn’t mean Pluton isn’t also a potential Trojan horse that Microsoft updates as they please with new things that we didn’t expect or ask for with no ability to undo them.
Edit: Removed a previous edit, and adding that, to complement the above notes, it does not help instill confidence that Microsoft isn’t telling what Pluton can and cannot do at a hardware level. They’ve said a few things it can do right now, and just said more stuff will be coming in the future, but they won’t talk about where its limits are. So… trust the black box without questions please. To be fair, this isn’t the first time (Intel ME, AMD PSP?), but it is unsettling to have another one.