Windows 11 TPM 2.0 Requirement: What's Changing With Pluton in 2026?

Windows 11 TPM 2.0 Requirement: What’s Changing With Pluton in 2026?

Since the launch of Windows 11, Trusted Platform Module (TPM) 2.0 has been a mandatory hardware security requirement. It provides a hardware-backed foundation for protecting encryption keys, securing authentication credentials, and establishing trust in the operating system’s boot process.

However, Microsoft’s approach to TPM implementation is evolving in 2026.

According to updated Microsoft technical documentation, beginning with silicon platforms introduced in 2026, Microsoft Pluton will no longer serve as the system TPM on AMD and Qualcomm platforms. Instead, TPM 2.0 functionality will be provided through the processor vendor’s firmware TPM (fTPM) or a discrete TPM (dTPM).

This change does not mean that Microsoft is removing Pluton from future processors, nor does it represent a relaxation of Windows 11’s security requirements.

Rather, Microsoft is separating two functions that were previously combined on certain platforms:

• TPM 2.0: Provides standardized hardware-backed key storage, cryptographic operations, and platform measurements.
• Microsoft Pluton: Continues to operate as an independent, hardware-isolated security processor that provides additional security capabilities beyond the TPM specification.

For existing AMD and Qualcomm systems manufactured through 2025 that use Pluton as their TPM, Microsoft has explicitly confirmed that support and servicing will continue.

For enterprise IT departments, however, the change introduces an important consideration: firmware security maintenance, TPM vulnerability remediation, and OEM BIOS update policies may become more significant parts of device procurement and lifecycle management.

🔐 1. Windows 11 Still Requires TPM 2.0

#

Before examining the Pluton changes, one point needs to be clarified:

Windows 11 has not removed its TPM 2.0 hardware requirement.

Microsoft continues to require TPM 2.0 for supported Windows 11 installations.

TPM provides a hardware-backed environment for managing sensitive cryptographic information and supporting system security features.

Its responsibilities include:

• Generating and protecting cryptographic keys.
• Securely storing authentication credentials.
• Supporting measured boot and platform attestation.
• Protecting BitLocker encryption keys.
• Supporting Windows Hello authentication.
• Providing a hardware root of trust for security-sensitive operations.

1.1 What Is a Trusted Platform Module?

#

A Trusted Platform Module is a security component designed to provide cryptographic and platform-integrity functionality.

Unlike ordinary system memory, TPM-protected key material is designed to remain protected by the security processor.

TPM 2.0 supports standardized cryptographic operations and security mechanisms, including:

• RSA and ECC cryptographic operations.
• Secure key generation and storage.
• Hashing and integrity measurement.
• Platform Configuration Registers (PCRs).
• Attestation mechanisms.
• Protected authorization and key-management operations.

One particularly important feature is the use of Platform Configuration Registers.

PCRs store measurements associated with different stages of the system boot process.

These measurements can be used to evaluate whether the machine started in an expected configuration.

For example, changes to firmware, bootloaders, or other measured components can affect PCR values.

Security mechanisms such as BitLocker can use these measurements when determining whether protected encryption keys should be released.

1.2 Why Windows 11 Requires TPM 2.0

#

Microsoft introduced TPM 2.0 as a baseline requirement for Windows 11 to strengthen hardware-backed security across the PC ecosystem.

The requirement supports several security technologies:

An important distinction is that Secure Boot itself is implemented through UEFI firmware and its signature-verification mechanisms. TPM complements Secure Boot by storing platform measurements and supporting attestation; it is not the component that independently validates every bootloader signature.

Microsoft’s requirements remain unchanged in 2026: supported Windows 11 devices must provide TPM 2.0 functionality.

For the official technical requirements, see Microsoft’s Windows 11 hardware security and TPM documentation.

🧩 2. The Major 2026 Change: Pluton No Longer Serves as the TPM on AMD and Qualcomm Platforms

#

The most important update comes from Microsoft’s revised documentation for Microsoft Pluton as a Trusted Platform Module.

Beginning with silicon introduced in 2026, Pluton will no longer act as the system TPM on new AMD and Qualcomm platforms.

Instead, these systems will provide TPM 2.0 through one of two implementations:

1. Firmware TPM (fTPM).
2. Discrete TPM (dTPM).

Microsoft’s documentation also describes Intel platforms as using the silicon vendor’s firmware TPM or a discrete TPM to provide the system TPM functionality.

This represents a change in the allocation of security responsibilities, not a change in the Windows 11 security baseline.

2.1 Understanding the Three TPM Implementations

#

There are three important ways to provide TPM functionality in modern PCs.

Firmware TPM (fTPM)

A firmware TPM implements TPM functionality through the platform’s processor or chipset security architecture.

It does not require a separate physical TPM chip mounted on the motherboard.

Examples include:

• AMD firmware TPM implementations.
• Intel Platform Trust Technology (PTT).
• Firmware-based TPM implementations on supported Qualcomm platforms.

The fTPM provides TPM 2.0 functionality through platform firmware and hardware security mechanisms.

Discrete TPM (dTPM)

A discrete TPM is a dedicated physical security chip installed on the motherboard.

It provides cryptographic and key-management functionality independently of the main CPU’s firmware TPM implementation.

Its advantages can include a separate physical security boundary and dedicated hardware implementation.

Microsoft Pluton

Pluton is a security processor integrated into the processor or SoC platform.

It can implement TPM 2.0 functionality when configured as the system TPM.

However, its capabilities extend beyond the standardized TPM interface.

Pluton also provides a Microsoft-maintained security execution environment designed to protect sensitive information and support additional Windows security features.

2.2 How the 2026 Platform Configuration Changes

#

The updated platform arrangement can be summarized as follows:

The important distinction is that the 2026 change specifically removes Pluton’s system-TPM role on new AMD and Qualcomm silicon.

It does not imply that every future PC will use a separate physical TPM chip.

Firmware TPM remains a supported implementation.

2.3 Why Is Microsoft Separating Pluton From TPM Functionality?

#

Microsoft’s updated architecture gives PC manufacturers more flexibility in choosing which security component provides the standardized TPM interface.

Pluton can continue handling its additional security responsibilities independently.

This separation also allows the system TPM implementation to follow the silicon vendor’s platform security architecture.

In practical terms, the distinction becomes:

• The TPM provides standardized cryptographic and platform-trust functionality.
• Pluton provides an additional hardware-isolated security environment.
• Windows can use both components for different security purposes.

This is not necessarily a reduction in protection.

The overall security level depends on the implementation quality of the TPM, firmware, Pluton security environment, and their integration with Windows.

🛡️ 3. Microsoft Pluton Is Not Disappearing

#

One possible misunderstanding is that Microsoft is abandoning Pluton in future Windows PCs.

That is not what the updated documentation says.

Microsoft explicitly confirms that Pluton will continue to be present and supported on existing and future Windows devices.

The change affects only its role as the system TPM.

3.1 What Is Microsoft Pluton?

#

Microsoft Pluton is a security processor developed through Microsoft’s collaboration with major silicon vendors, including AMD, Intel, and Qualcomm.

Its architecture integrates security functionality directly into the processor or SoC subsystem.

This design aims to reduce the attack surface associated with communication between the CPU and a separate security chip.

Traditional discrete TPM implementations communicate with the host processor through an external interface.

Depending on the platform design, this communication path may expose additional opportunities for physical attacks or bus-level observation.

Pluton addresses this concern by integrating its security processor into the SoC environment.

Its primary objectives include:

• Protecting cryptographic keys.
• Securing authentication information.
• Protecting sensitive user credentials.
• Providing an isolated firmware execution environment.
• Supporting additional Windows security capabilities.

3.2 Pluton Continues Operating as an Independent Security Processor

#

On future platforms where another TPM implementation provides the system TPM, Pluton remains available for security functions beyond the standard TPM specification.

The general architecture becomes:

+--------------------------------------+
|              Windows 11              |
|                                      |
|  BitLocker | Windows Hello | VBS     |
|  System Guard | Security Services    |
+------------------+-------------------+
                   |
          +--------+--------+
          |                 |
          v                 v
+-------------------+ +-------------------+
|    System TPM     | |  Microsoft Pluton |
|                   | |                   |
| fTPM or dTPM      | | Isolated Security |
|                   | | Processor         |
| TPM 2.0 Interface | | Additional Security|
| Key Protection    | | Functions         |
| PCR / Attestation | | Protected Firmware |
+-------------------+ +-------------------+
          |                 |
          +--------+--------+
                   |
                   v
          Platform Hardware

This separation allows Windows to use standardized TPM interfaces while Pluton continues to provide additional security functionality.

3.3 Pluton Firmware Updates Through Windows Update

#

One of Pluton’s major architectural advantages is its firmware-maintenance model.

Microsoft designed Pluton to support security firmware updates delivered through Windows Update.

This addresses an important problem in traditional PC security infrastructure.

Security firmware can be difficult to maintain because updates may originate from different manufacturers and require different deployment procedures.

By maintaining Pluton’s firmware and delivering updates through Windows Update, Microsoft can provide a more centralized update mechanism.

Importantly, Pluton retaining this update capability does not mean that the separate system fTPM automatically receives the same update treatment.

This distinction becomes particularly important for enterprise firmware maintenance.

3.4 Existing 2025 and Earlier Devices Remain Supported

#

Microsoft has also clarified the upgrade impact on existing devices.

AMD and Qualcomm systems built on 2025 or earlier silicon that ship with Pluton configured as the TPM remain fully serviced and supported.

The new policy applies only to silicon platforms introduced in 2026 and later.

Therefore:

• Existing Windows 11 devices do not need to replace their TPM.
• Existing Pluton-based installations remain supported.
• Users do not need to disable or reconfigure Pluton.
• Windows 11 continues to use the active TPM 2.0 implementation.
• Future AMD and Qualcomm platforms will use fTPM or dTPM for system TPM functionality.

For further background, see Microsoft’s official Pluton security processor architecture documentation.

🔑 4. BitLocker, Windows Hello, and System Guard Remain Supported

#

For ordinary Windows users, the most important question is whether removing Pluton’s system-TPM role affects existing security features.

The answer is no, provided the replacement TPM implementation correctly supports the required TPM 2.0 functionality.

Windows security features communicate through the TPM interface rather than requiring a particular physical TPM implementation.

This means that BitLocker and Windows Hello can continue operating with a compatible fTPM or dTPM.

4.1 BitLocker Drive Encryption

#

BitLocker uses TPM-backed mechanisms to protect encryption keys.

When the system starts, the TPM can evaluate platform measurements and determine whether the environment matches the expected trusted configuration.

If the relevant integrity conditions are satisfied, the TPM can release the protected key material required for the system to unlock its encrypted drive.

This provides protection against unauthorized access to data when a device is physically removed or stolen.

The implementation can use:

• Microsoft Pluton TPM.
• AMD fTPM.
• Intel PTT.
• Supported discrete TPM devices.

The underlying TPM implementation may change, but the BitLocker security model remains supported.

One practical consideration is that significant firmware or TPM configuration changes can affect the measurements associated with BitLocker’s key protectors.

After a BIOS update or TPM-related platform change, users may occasionally encounter a BitLocker recovery prompt.

Organizations should therefore maintain recovery-key backups and test their firmware-update procedures.

4.2 Windows Hello and Windows Hello for Business

#

Windows Hello provides passwordless authentication through biometric verification and PIN-based credentials.

Its security architecture uses hardware-backed key protection where supported.

TPM can securely store the cryptographic keys used for authentication.

This helps prevent sensitive authentication material from being directly exposed to ordinary application processes.

For enterprise environments, Windows Hello for Business can also integrate with Microsoft Entra ID and other identity infrastructure.

Switching the system TPM from Pluton to fTPM or dTPM does not inherently remove these capabilities.

4.3 System Guard and Platform Integrity

#

Microsoft System Guard provides security mechanisms intended to protect the Windows boot process and establish confidence in the platform’s integrity.

TPM contributes through measured boot and hardware-backed attestation.

During startup, platform components can be measured and recorded in PCRs.

These measurements can subsequently be evaluated by security services to determine whether the system booted in an expected configuration.

This is particularly relevant to enterprise environments that use device-health attestation to control access to sensitive resources.

4.4 Secure Boot Still Works Independently

#

It is worth distinguishing Secure Boot from TPM itself.

Secure Boot is implemented by UEFI firmware.

It validates boot components against trusted signatures and firmware security databases.

TPM complements this mechanism by storing measurements associated with the startup process.

The two technologies work together but are not interchangeable.

A system can support Secure Boot independently of whether its system TPM is implemented through Pluton, fTPM, or dTPM.

🏢 5. Why the Change Matters for Enterprise IT Departments

#

For individual users, the new TPM arrangement may have little visible impact.

Windows continues to recognize a compatible TPM 2.0 implementation, and familiar security features remain available.

For enterprise IT administrators, however, the distinction becomes more important.

The main issue concerns firmware maintenance and the delivery of security updates.

5.1 Windows Update vs. OEM Firmware Updates

#

When Pluton serves as the system TPM, its security firmware can receive updates directly through Windows Update.

This provides a relatively centralized update mechanism.

By contrast, when the system TPM is implemented through vendor fTPM, the firmware update process generally depends on the silicon vendor and the PC manufacturer.

The typical servicing chain looks like this:

\[ \text{Silicon Vendor} \rightarrow \text{PC OEM} \rightarrow \text{UEFI/BIOS Firmware} \rightarrow \text{Enterprise Deployment} \]

The process generally involves several stages:

1. The silicon vendor identifies a vulnerability or develops a security fix.
2. The platform vendor integrates the correction into its firmware package.
3. The PC manufacturer validates and releases an updated BIOS or UEFI image.
4. The enterprise evaluates and deploys the firmware update.
5. IT administrators verify that the update has been successfully applied.

This can create differences in remediation timing between manufacturers and even between different laptop models from the same manufacturer.

There is an important qualification: Windows supports mechanisms for distributing certain OEM firmware updates through Windows Update, including UEFI firmware update packages.

Therefore, an fTPM update is not necessarily installed manually through a BIOS utility.

The key difference is that its firmware lifecycle and release responsibility generally remain tied to the platform and OEM rather than being directly maintained by Microsoft as Pluton’s firmware is.

5.2 TPM Firmware Vulnerabilities and BIOS Maintenance

#

Firmware TPM implementations are not immune to security vulnerabilities.

A flaw in an fTPM implementation may affect key management, cryptographic operations, or platform attestation.

A recent example involves AMD’s 2026 fTPM security advisories.

AMD disclosed vulnerabilities affecting its firmware TPM implementation, tracked as:

• CVE-2026-6726.
• CVE-2026-6727.

The fixes were distributed through updated AGESA firmware to motherboard and system manufacturers.

This illustrates why enterprise organizations should pay attention to firmware maintenance rather than treating TPM as a component that can be configured once and forgotten.

For further technical details, see AMD fTPM Vulnerabilities: Update Your BIOS to Fix CVE-2026-6726.

The example also demonstrates a broader operational problem: even when a silicon vendor has developed a fix, the correction may not reach end users until the corresponding OEM firmware package becomes available.

5.3 BIOS Update Frequency Becomes a Procurement Metric

#

When purchasing commercial PCs based on 2026 and newer silicon, enterprise IT departments should evaluate the manufacturer’s firmware support capabilities.

Important considerations include:

• Frequency of BIOS security updates.
• Time required to release critical firmware patches.
• Availability of firmware update packages.
• Windows Update integration.
• Enterprise deployment tooling.
• Firmware rollback and recovery procedures.
• Support duration for each commercial model.
• Security-advisory transparency.

A manufacturer offering longer and more predictable firmware maintenance may provide operational advantages over one with irregular BIOS support.

5.4 BitLocker Recovery-Key Management

#

TPM-related firmware changes can affect BitLocker’s trusted boot measurements.

During certain firmware updates, a system may detect a change in the measured boot environment and request the BitLocker recovery key.

For enterprise environments, recovery-key management should therefore be treated as part of the firmware update process.

Recommended practices include:

1. Back up BitLocker recovery keys before major firmware maintenance.
2. Ensure recovery keys are escrowed in Microsoft Entra ID or Active Directory where appropriate.
3. Test firmware updates on a representative device group.
4. Follow Microsoft’s and the OEM’s guidance on temporarily suspending BitLocker protection.
5. Verify successful system startup after updating.
6. Confirm that BitLocker protection is resumed.

Do not clear the TPM simply to troubleshoot a firmware update unless the manufacturer or Microsoft specifically instructs you to do so.

Clearing TPM state without preparing recovery mechanisms can make protected data or authentication credentials inaccessible.

5.5 Firmware Lifecycle and UEFI Integration

#

The role of UEFI firmware becomes increasingly important when the platform relies on fTPM.

The system firmware coordinates initialization of the platform security environment and integration with the operating system.

It also determines how certain hardware security functions are configured and exposed.

For developers working on firmware integration, UEFI BIOS Explained: Architecture, Boot Flow, and Secure Boot provides useful technical background on UEFI boot stages, firmware responsibilities, and Secure Boot.

Enterprise administrators should also understand how their OEM implements firmware updates, TPM initialization, and recovery workflows.

🔍 6. How to Check Your TPM Version and Provider in Windows 11

#

Windows 11 provides built-in tools that allow users to inspect the TPM implementation currently exposed to the operating system.

The simplest method is the Microsoft Management Console TPM interface.

6.1 Check TPM Information Using tpm.msc

#

Follow these steps:

1. Press Win + R to open the Run dialog.
2. Enter tpm.msc.
3. Press Enter.
4. Wait for the Trusted Platform Module Management console to open.
5. Check the TPM status and Manufacturer Information.

The most important field is:

Specification Version: 2.0

This indicates that Windows recognizes a TPM implementation supporting the TPM 2.0 specification.

The Manufacturer Information section also provides details such as:

• Manufacturer Name.
• Manufacturer Version.
• Manufacturer Specification Version.

These values help identify the TPM implementation.

However, the manufacturer identifier alone may not conclusively establish whether the active TPM is Pluton, fTPM, or a discrete TPM. For definitive identification, consult the OEM’s technical documentation or the platform’s UEFI configuration.

6.2 Check TPM Status Using PowerShell

#

Administrators can also use PowerShell.

Open PowerShell with administrative privileges and execute:

Get-Tpm

The command returns information including:

• TpmPresent
• TpmReady
• TpmEnabled
• TpmActivated
• ManagedAuthLevel
• AutoProvisioning

For example, a typical TPM status might look like:

TpmPresent        : True
TpmReady          : True
TpmEnabled        : True
TpmActivated      : True
AutoProvisioning  : Enabled

The exact fields displayed depend on the Windows version and platform implementation.

To inspect the TPM specification and manufacturer details, administrators can also use the TPM WMI interface or the TPM management console.

6.3 Check Windows Security

#

Another option is to open:

Settings
|
v
Privacy & Security
|
v
Windows Security
|
v
Device Security
|
v
Security Processor Details

This interface provides information about the system’s security processor and its capabilities.

Depending on the device, users may also find relevant information through the manufacturer’s BIOS setup utility.

6.4 Common TPM Implementations

#

The following table summarizes some typical firmware and hardware labels:

The actual implementation depends on the processor generation, motherboard, firmware, and OEM configuration.

📋 7. What Should Enterprises Evaluate Before Buying 2026+ PCs?

#

The change in Pluton’s TPM role creates an opportunity for IT departments to improve how they evaluate hardware security.

Instead of checking only whether a device supports TPM 2.0, procurement teams should examine how the implementation is maintained over its operational lifetime.

The following checklist provides a practical starting point.

7.1 TPM Architecture and Support

#

Confirm the following details:

• Does the platform use fTPM or dTPM?
• Is Microsoft Pluton also present?
• Which component acts as the active system TPM?
• Is TPM 2.0 enabled by default?
• Does the platform support required PCR and attestation functionality?
• How long will the TPM implementation receive firmware maintenance?

7.2 Firmware Update Infrastructure

#

Evaluate the OEM’s firmware support model:

• Are BIOS updates distributed through Windows Update?
• Does the manufacturer provide centralized enterprise deployment tools?
• Are firmware security advisories published regularly?
• Can updates be deployed silently?
• Are firmware packages digitally signed?
• Are rollback and recovery procedures documented?

7.3 Security Integration

#

Enterprise IT teams should also validate:

• BitLocker integration.
• Recovery-key escrow.
• Windows Hello for Business.
• Secure Boot configuration.
• Device Health Attestation.
• Microsoft Entra ID integration.
• TPM-backed authentication workflows.

7.4 Recommended Procurement Evaluation

#

This approach gives enterprises a more complete picture of platform security than checking TPM compatibility alone.

⚠️ 8. Does the Change Reduce Windows 11 Security?

#

The short answer is that Microsoft’s updated platform policy does not itself indicate a reduction in Windows 11’s security requirements.

TPM 2.0 remains mandatory, and the supported security features continue to work with compatible TPM implementations.

However, the actual security properties can differ between implementations.

8.1 fTPM vs. dTPM vs. Pluton

#

Each implementation has different architectural characteristics.

It is not accurate to conclude that one implementation is universally more secure than the others.

Security depends on:

• Hardware design.
• Firmware quality.
• Physical attack resistance.
• Key-storage implementation.
• Vulnerability management.
• OEM security practices.
• Platform configuration.

A properly implemented fTPM can satisfy Windows 11’s TPM requirements and provide hardware-backed security.

Similarly, a discrete TPM is not automatically immune to physical or firmware-level attacks.

8.2 The Importance of Firmware Security

#

A TPM is only one component of the overall hardware security architecture.

The security of a Windows PC also depends on:

• UEFI firmware.
• Secure Boot.
• System Management Mode (SMM) protections.
• Virtualization-Based Security (VBS).
• Hypervisor-protected Code Integrity (HVCI).
• Firmware update authentication.
• Operating-system security updates.

A vulnerability in platform firmware can undermine the security assumptions made by higher-level mechanisms.

This is why OEM firmware maintenance becomes an important consideration when the active system TPM relies on the vendor’s firmware implementation.

🧭 Conclusion: TPM 2.0 Remains Mandatory, but Firmware Responsibility Is Changing

#

Microsoft’s 2026 TPM policy adjustment does not remove the Windows 11 TPM 2.0 requirement.

Instead, it separates the role of the system TPM from Microsoft Pluton’s broader security functionality on new AMD and Qualcomm platforms.

The key changes are:

• TPM 2.0 remains mandatory: Windows 11 continues to require a compatible TPM 2.0 implementation.
• Pluton’s role changes: Beginning with 2026 AMD and Qualcomm silicon, Pluton no longer serves as the system TPM.
• fTPM and dTPM take over: Platform vendors provide the standardized TPM functionality through firmware or dedicated hardware.
• Pluton remains available: Microsoft continues supporting Pluton as an independent, hardware-isolated security processor.
• Existing systems remain supported: AMD and Qualcomm devices built through 2025 with Pluton configured as the TPM remain fully serviced.
• Enterprise firmware management becomes more important: OEM BIOS update frequency, security patch delivery, and recovery procedures deserve greater attention.

For ordinary Windows users, this architectural change should have little direct impact on everyday computing. BitLocker, Windows Hello, and other TPM-dependent security features remain supported through compatible TPM 2.0 implementations.

For enterprise IT departments, however, the change introduces an important procurement consideration.

The next generation of Windows PC security will depend not only on whether a system includes TPM 2.0, but also on who maintains its firmware, how quickly vulnerabilities are patched, and how reliably those updates can be deployed across an enterprise fleet.

Pluton is not disappearing. Its responsibilities are simply becoming more clearly separated from the standardized TPM functionality that Windows 11 continues to require.