What is the difference between a TPM 1.2 and a TPM 2.0?

TPM 1.2, published in 2005 and standardised as ISO/IEC 11889 first edition, locks the algorithms (RSA-2048, SHA-1, fixed key hierarchy) and exposes a fixed command set. TPM 2.0, whose Library Specification reached version 1.62 in 2020, becomes algorithm-agile: SHA-256 and stronger are baseline, ECC with NIST P-256 and BN-256 is supported, multiple hierarchies (platform, storage, endorsement, null) coexist and authorisation is generalised through policies. The hardware is not compatible across the two: a TPM 1.2 motherboard cannot be flashed to TPM 2.0, the silicon differs. New designs target TPM 2.0; TPM 1.2 is end-of-life and no longer accepted by Windows 11 or by most current attestation services.

What is the role of the Platform Configuration Registers (PCRs)?

PCRs are extend-only registers, 24 of them in the standard profile (PCR 0 to 23), used to record an immutable hash chain of the boot and runtime measurements. Each measurement applies the rule PCR[n] = SHA-256(PCR[n] concatenated with measurement). Boot firmware extends PCR 0 to 7 with its own measurements (UEFI, option ROMs, boot loader, secure boot state); the operating system extends PCR 8 onwards. Two primary uses follow: sealing, which binds data to a chosen PCR state and refuses to unseal if the state differs, and quoting, which signs the PCR contents under an attestation key for remote attestation. PCR layout differs between Windows and Linux: data sealed on one rarely unseals on the other.

Discrete TPM, firmware TPM or virtual TPM, which to choose?

A discrete TPM (Infineon SLB 9670, ST33, Nuvoton NPCT) is a dedicated chip on SPI, I2C or LPC. It offers physical isolation, strong Common Criteria evaluation and is the reference for hardware attestation. A firmware TPM (Intel PTT in the Management Engine, AMD fTPM in the Platform Security Processor) runs inside a Trusted Execution Environment on the main SoC: lower bill of materials, but shares its attack surface with the platform firmware. A virtual TPM (vTPM, swtpm) is for virtual machines and development; the trust anchor moves up to the hypervisor or, for software TPM, is simulated. Typical choices: dTPM for PC, server, defence, payment, automotive; fTPM for consumer laptops; vTPM for cloud workloads; swtpm for CI pipelines.

What was the ROCA vulnerability and is it still relevant?

ROCA (Return Of Coppersmith Attack), published in 2017 under CVE-2017-15361, affected RSA key generation in the Infineon RSALib cryptographic library used in several TPM 1.2 and TPM 2.0 chips. The bias in primes generation made 2048-bit RSA keys factorisable on the order of CPU days. Infineon distributed firmware updates and Microsoft, Lenovo, HP and others regenerated affected keys. In 2026, devices still in service with a vulnerable TPM firmware version remain non-conform to FIPS 140-3 and to most current security baselines; checking the TPM firmware version (tpm2_getcap properties-fixed on Linux, Get-Tpm on Windows) against the manufacturer security bulletin remains an essential audit step.

How does TPM 2.0 fit into the EU Cyber Resilience Act?

The Cyber Resilience Act (CRA), published in November 2024 and becoming applicable December 2027, requires for products with digital elements a secure boot, data confidentiality and integrity, attack surface limitation and a vulnerability handling process. TPM 2.0, or a secure element with equivalent properties, is one of the practical paths for these requirements: measured boot rooted in PCRs, sealing of secrets to platform state, vulnerability management through firmware updates signed and verified by the TPM, attestation of the device state. The CRA does not name TPM explicitly but, for products in the important and critical classes (Annex III and IV), the design without secure hardware anchor becomes hard to defend in conformity assessment.

What are the most frequent pitfalls integrating a discrete TPM?

First, BGA placement and ESD protection: discrete TPM are sensitive to soldering defects, the dry pack must be respected and ESD protection sized for the chosen interface (SPI is more tolerant than LPC). Second, the bus speed: an LPC TPM used for the Static Root of Trust for Measurement lengthens boot by hundreds of milliseconds, SPI at 30 MHz is preferable on a modern platform. Third, the EK certificate chain: forgetting to load the manufacturer intermediate certificate blocks Azure DPS provisioning. Fourth, the firmware TPM is often disabled by default in BIOS (fTPM Disabled), which silently breaks the sealing of BitLocker or LUKS on the first deployment. Fifth, reusing data sealed under a Windows PCR layout on a Linux system is impossible: the boot chain measures different objects in different orders.

TPM 2.0 and TCG hardware security

Q: Which Common Criteria evaluations cover TPM 2.0 chips?

Discrete TPM 2.0 chips from Infineon, ST and Nuvoton are Common Criteria evaluated against the protection profile BSI-CC-PP-0030 Trusted Platform Module Library Family 2.0, published by the German BSI and recognised internationally via CCRA and SOG-IS. Typical assurance level: EAL 4 augmented with AVA_VAN.4 or AVA_VAN.5 (Moderate or High vulnerability analysis), ALC_DVS.2 and ALC_FLR.1. The evaluation covers the hardware, the embedded firmware and the cryptographic library. Firmware TPM evaluations exist but are less common; AMD fTPM and Intel PTT historically have not pursued a Common Criteria certificate equivalent to a dedicated chip, which weighs on the trust analysis for regulated sectors.

Author Hugues Orgitello Last updated 27 May 2026 ~14 min read

Guide, TPM 2.0 and TCG

The Trusted Platform Module (TPM) is the hardware security anchor standardised by the Trusted Computing Group (TCG), an industry consortium founded in 2003 that brings together Intel, AMD, Microsoft, IBM, HP and most semiconductor and platform manufacturers. The TPM 2.0 specification, published in 2014 and standardised as ISO/IEC 11889-1 to -4 in 2015, replaces TPM 1.2 (2005) which is now considered legacy. This page presents the TCG ecosystem and the standards, the TPM 2.0 architecture and its concrete functions (Endorsement Key, PCR, sealing, attestation), the form factors (discrete, firmware, virtual), the certifications (TCG Compliance, Common Criteria against BSI-CC-PP-0030, FIPS 140-3), operating system integration (BitLocker, LUKS, IMA), connected products and IoT use, the known compromises (ROCA, TPM-Fail, Sandman) and the pitfalls observed in integrating discrete TPM (Infineon SLB 9670, ST33, Nuvoton NPCT) or firmware TPM (AMD fTPM, Intel PTT) in PC, server, IoT and embedded products.

Trusted Computing Group, the institutional framework

The Trusted Computing Group is the standardisation body that maintains the TPM specification and a wider family of trusted computing standards. Understanding its scope conditions the technical and contractual choices.

Body	Scope	Type of deliverable
TCG (Trusted Computing Group)	TPM, attestation, measured boot, storage security, network security	Library Specifications, Platform TPM Profiles, certification programmes
ISO/IEC JTC 1/SC 27	Adoption of TPM 2.0 as ISO/IEC 11889	International standard, freely cited
BSI (Germany)	Common Criteria Protection Profile for TPM 2.0	BSI-CC-PP-0030 reference Protection Profile
NIST (USA)	FIPS 140-3 module validation, cryptographic guidance	Cryptographic Module Validation Program (CMVP) certificates
TPM manufacturers	Silicon and firmware (Infineon, ST, Nuvoton, AMD, Intel, Microsoft)	TPM 2.0 conform products, EK certificates, security bulletins

The TCG operates through working groups: TPM Work Group for the core library, PC Client for personal computer and server profiles, Mobile for the mobile world, Embedded Systems for industrial IoT, Storage for self-encrypting drives, Network Equipment Building System (NEBS) and DICE (Device Identifier Composition Engine) for ultra-constrained devices. The deliverables are public, downloadable from the TCG website. Compliance certification (TCG Compliance Programme) is a paid service, with publication on a public list.

TPM 1.2 to TPM 2.0, the algorithm-agile shift

TPM 1.2 (2005) was tied to a fixed algorithmic profile: RSA-2048 for asymmetric, SHA-1 for hashing, no native ECC support, command set anchored on the structure of these algorithms. SHA-1 collisions (Stevens et al., 2017, then SHAttered) and the gradual deprecation of RSA-2048 below the 2030 horizon made the architecture untenable.

TPM 2.0, drafted from 2011 and published as Library Specification 1.07 in 2014, then standardised as ISO/IEC 11889 in 2015, reaching version 1.62 in 2020 with subsequent errata, becomes algorithm-agile. The specification separates the algorithmic profile from the architecture: a TPM 2.0 supports a manufacturer-chosen subset (SHA-256 mandatory, SHA-384 optional, RSA-2048 baseline, ECC NIST P-256 widespread, ECC BN-256 for Direct Anonymous Attestation). Hierarchies are reorganised (platform, storage, endorsement, null) and authorisation is generalised through policies (TPM2_PolicyOR, TPM2_PolicyPCR, TPM2_PolicySigned and so on).

The hardware is not compatible across the two: a TPM 1.2 motherboard cannot be flashed to TPM 2.0. New designs target TPM 2.0; TPM 1.2 is end-of-life and rejected by Windows 11, recent BitLocker baselines and most current attestation services.

TPM 2.0 architecture

A TPM 2.0 exposes a small set of structuring objects.

Endorsement Key (EK)

The EK is an asymmetric key pair (RSA-2048 or ECC NIST P-256) injected at the silicon factory by the manufacturer, private part non-extractable. The associated EK certificate is signed by a manufacturer intermediate certification authority (Infineon, ST, Nuvoton, AMD, Intel), itself rooted on a public certification authority listed by the TCG. The EK proves that the TPM is a genuine certified TPM from a known manufacturer, without revealing the platform identity. It is the trust anchor for downstream attestation.

Storage Root Key (SRK)

The SRK is created when the platform owner takes control of the TPM (TPM2_CreatePrimary in the storage hierarchy). It is the root of the application key hierarchy: keys generated and sealed by the platform descend from it. The SRK never leaves the TPM and disappears when ownership is reset.

Attestation Identity Key (AIK)

The AIK, sometimes called Attestation Key (AK), is a signing key generated by the TPM, derived from the EK but pseudonymous: it does not directly reveal the EK identity. It is certified either by a Privacy CA (external service that validates the EK chain and issues an AIK certificate), or by Direct Anonymous Attestation (DAA), a zero-knowledge protocol that proves the AIK comes from a genuine TPM without identifying the TPM. The AIK signs PCR quotes during remote attestation.

Platform Configuration Registers (PCRs)

PCRs are extend-only registers, 24 of them in the PC Client standard profile (PCR 0 to 23). Each measurement obeys the rule PCR[n] = SHA-256(PCR[n] concatenated with measurement). The architecture forbids overwriting a PCR: only an extension is allowed. Boot firmware extends PCR 0 to 7 with its measurements (UEFI, option ROMs, boot loader, secure boot state, boot policy); the operating system extends PCR 8 onwards.

PCR	Typical content (TCG PC Client profile)
PCR 0	UEFI firmware (BIOS) measurement, S-CRTM
PCR 1	Platform configuration (BIOS options, oprom config)
PCR 2, 3	Option ROMs, drivers
PCR 4	Boot loader (MBR or UEFI loader)
PCR 5	GPT partition table
PCR 7	Secure Boot state and signing keys
PCR 8 to 15	Operating system, application measurements
PCR 17 to 22	Dynamic Root of Trust (DRTM, Intel TXT, AMD SKINIT)
PCR 23	Application use, regularly reset by the OS

The PCR layout differs between Windows and Linux: data sealed on one OS rarely unseals on the other.

Sealing and quoting

Sealing binds data to a chosen PCR state. The TPM will only unseal if PCRs match the expected value. Quoting produces a signed report of PCR values under an attestation key, used in remote attestation. Together they form the core of measured boot and trusted boot.

Form factors, discrete, firmware, virtual

Form factor	Examples	Advantages	Limitations
Discrete TPM (dTPM)	Infineon SLB 9670, ST33TPHF20, Nuvoton NPCT75x	Physical isolation, strong Common Criteria evaluation (EAL 4+), independent attack surface	Bill of materials, PCB area, SPI/I2C/LPC interfacing
Firmware TPM (fTPM)	Intel PTT in the Management Engine, AMD fTPM in the Platform Security Processor	No additional chip, no bill of materials cost	Shares attack surface with platform firmware, Common Criteria evaluation more limited
Virtual TPM (vTPM)	QEMU/KVM with swtpm, VMware vTPM, Hyper-V vTPM	Suitable for virtual machines, software-isolated per VM	Trust anchor moves up to the hypervisor
Software TPM (swtpm)	swtpm, IBM TPM 2.0 reference simulator	Development, CI pipelines, integration testing	No real security, dev-only use

Typical choice: dTPM for PC, server, defence, payment, industrial and automotive; fTPM for consumer laptops; vTPM for cloud workloads; swtpm for CI pipelines.

Interfaces and software stack

A discrete TPM exposes one of several physical interfaces.

Interface	Typical speed	Use
LPC (Low Pin Count)	33 MHz, legacy	Older PC, increasingly avoided due to bus latency
SPI	up to 33 MHz typically	Reference modern interface, PC, server, embedded
I2C	400 kHz to 1 MHz	Embedded systems, IoT, slower interactions
FIFO (memory-mapped)	platform-dependent	Variant on certain platforms

On Linux, the kernel exposes two character devices: /dev/tpm0 for raw access (used by the integrity subsystem) and /dev/tpmrm0 with the kernel-side resource manager (used by user-space applications). The reference stack is tpm2-tss (Trusted Software Stack, ESAPI, SAPI, TCTI layers) plus tpm2-tools (command line). The tpm2-pkcs11 library exposes the TPM as a PKCS#11 token for OpenSSL or browser integration.

On Windows, access goes through the TPM Base Services (TBS) API, encapsulated by the Windows Cryptography API: Next Generation (CNG) and exposed to applications through specific providers. BitLocker, Windows Hello and Credential Guard use the TPM directly through these APIs.

Certifications, TCG Compliance, Common Criteria, FIPS 140-3

A TPM 2.0 product is subject to several certifications.

TCG Compliance Programme

The TCG runs a compliance programme based on the TPM 2.0 Test Suite. The manufacturer submits its product, runs the test suite (functional coverage of the TPM library), and receives a TCG Certified TPM declaration listed on the TCG public list. This certification is conformity (the TPM does what the specification says), not security as such.

Common Criteria and BSI-CC-PP-0030

The security reference is the Common Criteria evaluation against the protection profile BSI-CC-PP-0030 Trusted Platform Module Library Family 2.0, published by the German BSI. This protection profile defines the security functional requirements (SFR) expected of a TPM 2.0 and the assurance requirements. Typical assurance level: EAL 4 augmented with AVA_VAN.4 or AVA_VAN.5 (Moderate or High vulnerability analysis), ALC_DVS.2 and ALC_FLR.1.

Infineon (SLB 9670, SLB 9672), ST (ST33TPHF20, ST33KTPM2X) and Nuvoton (NPCT75x) all hold current Common Criteria certificates against this profile, listed on the BSI and the international Common Criteria portal. Firmware TPM evaluations exist but are rarer: AMD fTPM and Intel PTT historically have not pursued a Common Criteria certificate equivalent to a discrete chip. For the wider framework, see Common Criteria, ISO/IEC 15408.

FIPS 140-3 (USA)

For the United States federal market, the cryptographic module embedded in the TPM is often validated under FIPS 140-3 (or its predecessor FIPS 140-2, in sunset since September 2026). The validation is run under the NIST Cryptographic Module Validation Program (CMVP), at level 1 or 2 typically for a TPM. The result is a published validation certificate on the CMVP list. For the full framework, see FIPS 140-3.

Operating system integration

Windows BitLocker

BitLocker uses the TPM to seal the Volume Master Key (VMK) on PCR 0, 2, 4, 7 and 11 (default profile), which couples disk decryption to the secure boot state. A change of BIOS, of secure boot keys, of boot loader breaks the seal and triggers BitLocker recovery (recovery key prompt). On Windows 11, TPM 2.0 is mandatory, which made fTPM activation a critical point on motherboards delivered with fTPM disabled by default.

Linux dm-crypt and LUKS

The reference stack uses dm-crypt for full disk encryption, LUKS2 for the key envelope, and the unlock mechanism couples to the TPM through one of two paths: clevis (a pluggable framework that supports TPM 2.0, Tang and Shamir secret sharing) or systemd-cryptenroll (native, since systemd 248). In both cases, the LUKS passphrase is sealed against a PCR profile chosen at enrolment (commonly PCR 7 for secure boot state, PCR 0 for UEFI firmware, PCR 1 for platform config). Unsealing at boot is silent if PCRs match, falls back on passphrase entry otherwise.

Integrity Measurement Architecture (IMA)

The Linux kernel implements IMA (Integrity Measurement Architecture) to measure executables, configuration files and chosen objects at runtime. IMA extends a dedicated PCR (PCR 10 by convention) and produces a measurement log readable in /sys/kernel/security/ima/ascii_runtime_measurements. Pairing IMA with the TPM allows remote attestation of the runtime state, beyond the initial boot.

OpenSSL and tpm2-pkcs11

The library tpm2-pkcs11 exposes the TPM as a PKCS#11 token to OpenSSL or any PKCS#11-aware application. This permits HSM-like signing and decrypting operations with the TPM acting as a low-cost cryptographic store, suitable for X.509 client certificate authentication, code signing on embedded build environments or sealing of CA private keys.

Connected products and IoT

Microsoft Azure Device Provisioning Service (DPS)

Azure DPS supports TPM-based attestation. The device declares its endorsement key public (EKpub) to DPS; DPS validates that the EKpub is signed by a known TPM manufacturer intermediate certification authority, then issues an attestation challenge that the TPM signs under a derived attestation key. On success, DPS provisions the device to its IoT Hub. The provisioning chain falls apart if the manufacturer intermediate certificate is missing from the device-side dossier: a frequent error in first deployments.

AWS IoT and X.509 in the TPM

AWS IoT does not natively support TPM EK attestation; the integration goes through a long-term X.509 client certificate, whose private key is generated and stored in the TPM. Mutual TLS authentication to the AWS broker then uses the TPM as a private-key store, with no extraction of the private key.

Matter (CSA) and the Device Attestation Certificate

The Matter standard from the Connectivity Standards Alliance requires a Device Attestation Certificate (DAC) anchored in a hardware secure storage element, often a secure element rather than a discrete TPM (TPM is rare in consumer Matter devices because of bill of materials). The trust chain logic, however, is the same: vendor intermediate certificate, manufacturer root certificate, attestation in fabric commissioning. For details, see Matter certification.

TPM, secure element and HSM, what differs

Aspect	TPM 2.0	Secure Element (SE)	HSM
Form factor	Discrete chip or firmware, integrated to a platform	Discrete chip, smaller, generic crypto offload	Network appliance or PCI card, datacenter
Typical use	Boot trust, sealing, attestation, key sealed to platform state	Generic crypto offload, IoT identity, payment, transport tickets	High-throughput crypto operations (TLS, code signing, PKI)
Standardisation	TCG, ISO/IEC 11889	GlobalPlatform, JavaCard, EMVCo for payment	FIPS 140-3, Common Criteria for the bigger ones
Typical examples	Infineon SLB 9670, ST33, Nuvoton NPCT, fTPM	NXP A71CH, SE050, Microchip ATECC608B, Infineon OPTIGA Trust	Thales Luna, Utimaco, AWS CloudHSM
Bill of materials order	Low for fTPM, moderate for dTPM	Low	High

Embedded products often choose an SE rather than a TPM (lower bill of materials, simpler interface), but the rise of Matter, of regulated industrial IoT and of the Cyber Resilience Act pushes attestation onto TPM-like devices, with chip evaluated under Common Criteria.

Known compromises and security history

Year	Compromise	Affected scope	Mitigation
2017	ROCA (CVE-2017-15361)	Infineon RSALib library, RSA key generation in TPM 1.2 and 2.0	Firmware update, regeneration of affected RSA keys
2019	TPM-Fail (CVE-2019-11090, CVE-2019-16863)	Timing side channel on ECDSA in Intel fTPM and ST33TPHF20	Firmware update, mitigations in the cryptographic stack
2024	Sandman	Cold boot variant on dTPM exposed on SPI bus	Bus encryption (TPM 2.0 supports session encryption since spec 1.38), physical access control

The general operational lesson is the same: any TPM in service must be inventoried with its firmware version, and the firmware version checked against published security bulletins. PCR-based measured boot remains the user-visible mitigation: a compromised TPM that produced a maliciously sealed value betrays itself by an attestation that no longer matches the expected reference state.

TPM 2.0 and EU Cyber Resilience Act

The Cyber Resilience Act, published in November 2024 (Regulation (EU) 2024/2847) and becoming applicable December 2027, sets essential cybersecurity requirements for products with digital elements. The TPM is not named explicitly but several CRA requirements have a TPM-natural reading: secure boot, data integrity and confidentiality, attack surface limitation, vulnerability handling process, security update path.

For products classed important (Annex III) or critical (Annex IV), where conformity assessment is reinforced (third-party where applicable), designing without a secure hardware anchor becomes hard to justify. TPM 2.0, or a secure element with equivalent properties, is one of the practical paths to meet these requirements. For the wider framework, see Cyber Resilience Act.

Step-by-step procedure for an embedded product

The typical sequence for an engineering team integrating a TPM 2.0 in a new electronic product.

Choose the form factor (dTPM, fTPM, none plus SE) by mapping the bill of materials constraints, the certification requirement (Common Criteria for regulated sectors), the attack model and the target operating systems.
Select the chip (Infineon SLB 9672, ST33KTPM2X, Nuvoton NPCT75x for dTPM; AMD or Intel platform support for fTPM), check the current Common Criteria certificate, the FIPS 140-3 validation if relevant, and the active security bulletins.
Define the bus (SPI 25 to 33 MHz recommended for modern dTPM, I2C for ultra-constrained embedded, LPC only on legacy compatibility).
Lay out the PCB with appropriate ESD protection, supply decoupling, BGA placement with respect of the dry pack, and dedicated ground for the chip.
Integrate the software stack (tpm2-tss and tpm2-tools on Linux, TBS API on Windows, vendor SDK for RTOS).
Provision the EK certificate chain, load the manufacturer intermediate certificate on the device, validate the chain on first boot.
Define the PCR profile for sealing (commonly PCR 0, 2, 4, 7 on Windows; PCR 7 plus optional on Linux), test the unsealing behaviour across firmware update scenarios.
Implement attestation to the back end (Azure DPS, AWS IoT through X.509, internal IoT platform), validating the EK chain on the server side.
Plan firmware updates to the TPM (vendor supplies firmware bundles), with version inventory and security bulletin tracking.
Document the trust chain in the security dossier (root CA, intermediate, EK, AIK, sealed data) for the CRA, Common Criteria or sector evaluation.

Frequent pitfalls

Pitfall	Consequence
Discrete TPM in BGA poorly soldered or under-ESD-protected	Unstable TPM in the field, sporadic field returns hard to diagnose
LPC bus used for SRTM on a modern platform	Boot extended by hundreds of milliseconds, perceptible user impact
fTPM disabled by default in BIOS	BitLocker or LUKS sealing silently broken on first deployment
EK certificate chain not loaded on the device	Azure DPS provisioning fails, message Unauthorized EK
Re-use of Windows-sealed data on a Linux system	Unsealing systematically fails, PCR layout differs
TPM with ROCA-vulnerable firmware version still in service	RSA keys factorisable, security audit non-compliant
FIPS 140-2 declared instead of FIPS 140-3 after September 2026	Validation expired, federal procurement blocked
Confusion between TCG Compliance and Common Criteria	Belief that conformity covers security, gap in the security dossier
Sealing on PCR 0 with frequent BIOS updates	Routine recovery key prompts, support burden
No firmware version inventory across the fleet	Impossible to react to a new security bulletin in a deadline compatible with the CRA

Going further

Common Criteria, ISO/IEC 15408: the framework under which TPM 2.0 chips are evaluated against BSI-CC-PP-0030.
FIPS 140-3, cryptographic modules: the US validation framework for the TPM embedded cryptographic module.
Cyber Resilience Act: the EU regulation pushing secure boot and integrity, where TPM 2.0 is a structuring path.
Matter certification: the parallel logic, with a DAC anchored in a secure element close in role to a TPM.
Glossary: definitions of TPM, TCG, PCR, EK, AIK, sealing, attestation, dTPM, fTPM, vTPM.