The path toward an interoperable TPM Profile for IoT

Presently, supporting strong, interoperable security for Internet of Things (IoT) devices is an important priority for TCG. IoT encompasses an exceptionally broad range of devices, from small embedded controllers to complex industrial, automotive and infrastructure systems. A focused TPM profile must therefore address common security requirements while remaining practical across diverse architectures and resource constraints.

On occasion, some IoT and embedded-platform vendors have told TCG that existing Trusted Platform Module (TPM) can appear too difficult to navigate, particularly for engineers who are not TPM or security specialists. For these businesses, a more focused IoT profile could reduce implementation and maintenance overhead while making established TPM security capabilities more accessible to constrained-device developers. The TCG IoT Work Group is addressing this challenge by exploring a TPM profile tailored to the requirements of constrained and specialized IoT platforms.

What is the IoT Work Group doing within TCG?

The IoT Work Group is currently working towards a four-year timeline, which began in the summer of 2025. Despite only being in the early stages of this roadmap, our members are already gaining momentum: for example, they have found that simplifying the Device Provisioning Network (DPN) is beneficial as engineers don’t need deep, specialist knowledge to work with it, and it results in fewer complex features for vendors to maintain. Reducing that complexity shrinks the attack surface and lowers the memory footprint inside the trusted computing environment. These constraints are becoming more important as many post-quantum cryptography algorithms introduce larger keys, signatures, and intermediate working buffers than commonly deployed classical algorithms.

This has become a key motivation for developing a new TPM profile, while preserving interoperability across the broader trusted computing ecosystem. What will begin as a small, flexible subset will flourish into a profile that is more practical for IoT platforms - without creating a separate or incompatible trust architecture.

There is still a lot of work to be done here, and the Work Group is actively defining use cases and maintaining early draft specifications internally. The objective is to make TPM-based security easier to adopt for embedded-systems engineers who may not be TPM or hardware-security specialists. By defining which capabilities must be mandatory, optional, or deployment-specific, the Work Group creates a leaner profile that is easier for vendors and embedded-systems teams to implement consistently.

What would be the scope of the new IoT TCG profile?

Part of this work has included a review of previous specifications in order to identify the specific areas that need to be addressed for IoT devices. One area under evaluation is whether every privacy and anonymous-attestation mechanism required by general-purpose client profiles is also necessary for every IoT deployment. The Work Group is considering which capabilities should be mandatory, optional, or selected according to the deployment’s privacy requirements.

The Work Group is also discussing the technical challenges present in the industry, including how Platform Configuration Registers (PCRs) should be mapped for IoT devices. Because IoT hardware behaves differently from PCs and servers, the existing PCR model does not translate cleanly. This illustrates a broader point: the diverse characteristics of IoT require the Work Group to evaluate which existing TPM profile assumptions remain appropriate and which require IoT-specific guidance.

Other considerations are also under discussion. One option is whether RSA should remain mandatory within an IoT-focused profile. Making RSA optional could reduce code, storage, key-management and validation requirements for implementations designed around ECC and future PQC capabilities. Together, these design choices could support simpler device provisioning, ownership establishment and onboarding into device-management or cloud services.

How would this IoT TPM profile help with PCRs?

Existing profile guidance commonly describes PCR usage through PC-oriented boot components and terminology, which may not align with the architecture and lifecycle of an IoT device. To address this, the Work Group is exploring a more flexible way of describing PCRs, while still allowing for a minimum required set that is defined within the specification.

To support this objective, the Work Group is developing an IoT-oriented PCR model that recognizes the diversity of IoT architectures, including platforms with substantially lower memory, storage and processing capacity than PCs or servers. Potential measurement categories could include boot components, firmware, application code, security-critical configuration, sensor firmware and calibration state, depending on the device architecture and attestation use case.

In essence, the profile must address more than the number of PCRs. Interoperability depends on consistent measurement semantics, event-log information, and reference-value interpretation.

How will the IoT Work Group support resource-constrained systems?

The proposed profile is intended primarily for systems constrained by memory, storage, processing capacity, power consumption or implementation. Many IoT devices run on small or highly specialized microcontrollers with limited RAM, non-volatile storage and processing capacity. Their security mechanisms must remain reliable throughout long operational lifecycles, including in regulated, industrial or safety-relevant environments. Take automotive platforms, which may contain several secure elements, Hardware Security Modules, or other roots of trust - not necessarily TPMs.

A narrower mandatory command and algorithm set could also enable TPM Software Stack implementations with a smaller code and memory footprint. By retaining compatible TPM interfaces and command semantics, vendors may be able to reuse portions of existing TPM Software Stack implementations, provisioning tools and attestation services. The IoT TPM can be used as a standalone, or even in combination with the PC-Client TPM.

Improving adoption will require deliberate choices about which capabilities are essential, which can be optional and how implementation guidance can be made more accessible for resource-constrained environments.

The IoT Work Group is continuing to refine the use cases, interoperability boundaries and technical requirements that will determine the final shape of the profile.