The phrase "hardware root of trust" appears in nearly every IoT security architecture document. What it means operationally is: there is a piece of hardware whose security properties cannot be subverted by software alone, and the rest of the security stack depends on that hardware's guarantees. The choice of what that hardware is — discrete TPM, integrated TPM, secure element, or secure enclave inside the main MCU — has direct consequences for BOM cost, integration complexity, certification options, and achievable security level.
This article is for embedded engineers making the hardware security decision for a new IoT design. We'll cover what each option actually does, what standards apply, and how to choose between them based on device class and threat model — not marketing claims.
Trusted Platform Module (TPM): What It Is and What It Isn't
A TPM is a dedicated security IC specified by the Trusted Computing Group (TCG). The current specification is TPM 2.0, published as ISO/IEC 11889. TPMs provide a standardized API for cryptographic operations: key generation (RSA, ECC, HMAC), symmetric encryption, digital signatures, and a set of Platform Configuration Registers (PCRs) that can attest to boot state via cryptographic measurement.
What makes a TPM distinct from a general-purpose crypto IC is the PCR-based attestation capability. PCRs are hash registers that accumulate measurements of the boot chain — the bootloader, the OS kernel, the firmware image — such that the current PCR state cryptographically reflects what software ran during boot. Remote attestation allows a backend server to ask the TPM to sign a quote over its current PCR values, proving what software the device booted. This is a capability that general-purpose secure elements do not have.
TPMs exist in two physical forms: discrete TPMs — separate ICs soldered to the main PCB (connected to the host via SPI or I2C, e.g., Infineon SLB9670, Nuvoton NPCT75x) — and firmware TPMs (fTPMs) — TPM implementations running in a trusted execution environment inside the main processor (AMD fTPM, ARM TrustZone-based fTPM implementations, Qualcomm QSoC integrated fTPM). Discrete TPMs have stronger physical isolation. fTPMs are cheaper (no additional component) but their security properties depend on the TEE implementation quality.
Secure Element: Narrower, More Constrained, More Audited
A secure element is a tamper-resistant IC designed specifically to store secrets and perform cryptographic operations in isolation from the main host processor. Unlike TPMs, secure elements do not have a standardized API — each vendor implements their own interface. Common examples: Infineon OPTIGA Trust series (SLM76, SLx97 family), NXP SE050, Microchip ATECC608B, STMicroelectronics STSAFE-A.
Secure elements are evaluated and certified under Common Criteria (ISO/IEC 15408) and often FIPS 140-2/140-3. The ATECC608B is FIPS 140-3 Level 2 certified. The OPTIGA Trust M (SLM9670) is CC EAL6+. These certifications mean the security properties of the hardware have been independently evaluated against defined attack scenarios — not just manufacturer-claimed.
What secure elements excel at: key generation and storage with hardware-enforced non-exportability, cryptographic signing (ECDSA P-256 or P-384 typically), and secure key provisioning at manufacturing (pre-provisioned keys, certificate injection during production). What they do not have: PCR-based boot attestation, the broad protocol support of a TPM, or the TPM 2.0 standardized API.
Software-Only (TEE / TrustZone): The Constrained Option
ARM TrustZone provides hardware-isolated secure world execution on Cortex-A and Cortex-M33+ processors. A TrustZone-based key store — the most common form: keys generated and used only in the Secure World, never accessible to the Normal World application — provides meaningful isolation for software attacks. A Normal World exploit cannot directly read a TrustZone-isolated key.
The limitation of TrustZone-based security: physical attacks. A sufficiently motivated attacker with physical access — voltage glitching, fault injection, power analysis — can in some cases extract keys from TrustZone implementations that have not been specifically hardened against physical attacks. Discrete TPMs and certified secure elements have specific silicon-level countermeasures against physical attacks (active shields, sensor mesh, environmental detectors) that TrustZone alone does not.
We're not saying TrustZone-based key storage is weak — for network-level threat models and devices where physical access by an adversary is not a realistic scenario, it is a cost-effective and well-understood option. We're saying it doesn't provide equivalent physical attack resistance to a certified discrete security IC, and design decisions should reflect that honestly.
Decision Framework: Matching Hardware to Threat Model
The choice of hardware root of trust should follow from the threat model, not from what was easiest to integrate. A practical framework:
Device class: constrained MCU, BOM cost-sensitive (consumer IoT, volume >100K units/year)
Consider: Microchip ATECC608B or NXP SE050 at $0.50-1.20 per unit at volume. These provide FIPS-certified key storage and ECDSA signing via I2C with well-supported embedded SDKs (wolfSSL, Mbed TLS, AWS IoT Device SDK all have ATECC608 drivers). The limited protocol support is not a constraint for certificate-based TLS authentication — you don't need TPM PCR attestation to provision a device certificate and authenticate to MQTT/TLS.
Device class: Linux-based gateway, edge server, or industrial PC
Consider: discrete TPM 2.0 (Infineon SLB9670 or equivalent), connected via SPI. The standardized TPM 2.0 API (exposed by the Linux TPM kernel driver and the TSS2 library stack) integrates cleanly with standard PKI tooling. TPM PCR-based attestation can be used to verify boot integrity before releasing long-term identity credentials. For IEC 62443 SL2/SL3 applications, TPM-based attestation with a remote attestation service is increasingly expected.
Device class: automotive ECU, critical infrastructure component
Consider: integrated hardware security module (HSM) as part of the SoC (Infineon AURIX TC3xx, NXP S32G, Renesas RH850 — all include dedicated Hardware Security Module or HSM cores with cryptographic acceleration and key storage). These on-chip HSMs provide isolation without requiring a separate component, which is important for automotive reliability/vibration requirements. They are typically evaluated under ISO/SAE 21434 security assurance levels rather than FIPS/CC.
Device class: development prototype or low-volume industrial device
TrustZone-based software key storage is acceptable for prototyping and for deployments where the threat model excludes physical access attacks and volume does not justify the NRE cost of integrating a separate security IC. Document this choice explicitly in the device security design document — "software key storage, threat model excludes physical access" — so the decision is auditable and can be revisited if the threat model changes.
Scenario: Industrial IoT Gateway Redesign, Singapore, 2024
A growing industrial automation company producing Modbus-to-MQTT gateways for factory floor deployment redesigns its platform from an Arm Cortex-A7 module with software-only TrustZone keys to add a discrete TPM 2.0 chip. The driver: a major Japanese automotive customer requires IEC 62443-4-2 SL2 certification, and their security specification explicitly requires hardware-protected key storage with tamper evidence.
The engineering decision was between adding a discrete TPM (Infineon SLB9670, approximately $2.50 per unit at 5K volumes, SPI interface) and replacing the module with one that includes an integrated fTPM. The discrete TPM won on timeline: the fTPM option required a module vendor change with 16-week lead time; the SLB9670 could be added to the existing PCB layout in the next revision with 4-week NPI impact. The TSS2 software stack on Yocto Linux required three weeks of integration work including attestation service integration. Total BOM impact: $2.50 + ~$1.00 passives + PCB real estate. Timeline from decision to sample: 8 weeks.
The certification result: the SLB9670's CC EAL4+ evaluation was accepted as evidence of hardware key protection under the customer's security specification. The project would not have passed without it.
Pre-Provisioning and Manufacturing Implications
One frequently underestimated factor: secure elements and TPMs differ in their factory provisioning support. Many secure elements (ATECC608B with Microchip's Trust&GO service, OPTIGA Trust with Infineon's personalization service, SE050 with NXP's EdgeLock) can be pre-provisioned at the silicon level with device certificates before the PCB is assembled. The factory receives ICs that already contain a device certificate issued by the OEM's CA, with the private key generated and stored on the IC — never exposed to the provisioning system.
Discrete TPMs typically require post-board-assembly provisioning: the TPM key is generated on the assembled PCB during factory test, and the Certificate Signing Request is submitted to the CA service at that point. This is a more complex factory process but works for designs where the provisioning infrastructure is already set up for factory-floor CA integration.
The manufacturing provisioning model — whether the security IC arrives pre-provisioned or is provisioned on the production line — should be part of the hardware selection decision, not an afterthought during production planning.