Hardware Security for IoT: TPMs, Secure Elements & ATECC608 Explained

Most IoT product teams over- or under-spec their hardware security. Some bolt on a TPM because the slide deck said so; others ship a fleet of devices with no hardware root of trust at all and discover the gap during the first audit. Here is the framework we use to decide what each product actually needs.

What you are actually choosing between

In rough order of cost and capability:

1. Software-only crypto with secure boot and flash encryption (no separate hardware element)
2. MCU-integrated crypto and secure storage — built-in to many modern MCUs (ESP32, STM32, Nordic)
3. Discrete secure element — Microchip ATECC608, NXP A71CH/SE050, Infineon OPTIGA Trust M
4. TPM 2.0 — Infineon SLB 9670, ST33 series — full Trusted Computing Group spec
5. PUF (Physically Unclonable Function) — silicon-level uniqueness, vendor-specific (Intrinsic-ID, eMemory)

Each step up adds cost, board area, and engineering effort. Each step also adds attack resistance. The question is: which step does your threat model justify?

Software-only: when it is enough

A surprisingly common, defensible answer for low-stakes consumer products.

You can defend software-only when:

• The product has no high-value secret on the device (no payment, no health data, no enterprise credentials)
• Physical compromise of one device does not break others (per-device keys, no shared secrets)
• Reverse-engineering the firmware does not yield commercial advantage
• The MCU supports flash encryption and secure boot, both enabled

ESP32-S3 with Secure Boot V2 and flash encryption, for example, raises the bar for casual reverse-engineering significantly. A determined attacker with a logic analyser and time can still extract secrets — but for many consumer products, that level of effort exceeds the attacker’s incentive.

MCU-integrated crypto: the under-utilised middle ground

Modern MCUs ship more crypto hardware than most products use:

• STM32H5 / U5 — secure boot, TrustZone, OBKv2 (one-time programmable key storage), AES, PKA, true random number generator
• Nordic nRF5340 / nRF54 — Arm CryptoCell, Secure Domain isolation, KMU (Key Management Unit)
• NXP i.MX RT — EdgeLock secure enclave on RT117x, dedicated crypto engine
• ESP32-S3 / S2 — XTS-AES flash encryption, eFuses for secure boot key, HMAC peripheral

Using these properly often gets you to the security posture of a discrete secure element without adding a chip. The trade-off: the keys live in the same silicon as the application code. A successful exploit of the application can — in some attack scenarios — leak the keys.

For most product teams, MCU-integrated crypto is the right starting point. It is genuinely good. Reach for a discrete element only when the threat model demands it.

Discrete secure elements: the right call when

Pick a discrete secure element (ATECC608, SE050, OPTIGA Trust M) when:

• You need certified key storage — Common Criteria EAL4+, FIPS 140-2/3 — for compliance reasons
• The device does payments, healthcare, or identity where regulators expect a hardware root of trust
• High-value firmware that competitors would reverse-engineer must be protected against extraction
• The product will face expert-level physical attackers with significant resources

What you actually get:

• A separate chip with side-channel-hardened crypto routines
• Tamper detection (sometimes)
• Secure key generation and storage that survives even full firmware compromise
• Pre-provisioned device certificates from the vendor’s CA — saves you running your own PKI for cellular/cloud onboarding

The standard pick in 2026:

• Microchip ATECC608B — cheap, widely-deployed, AWS IoT and Azure IoT pre-provisioning available, ECC P-256
• NXP SE050 / EdgeLock — broader algorithm support, larger key storage, applet model
• Infineon OPTIGA Trust M — strong in industrial, integrates well with PSA Certified flow

TPM 2.0: when you need full TCG spec

TPMs are oversized for most IoT products but right when:

• The product runs Linux and integrates with enterprise PKI
• Compliance demands TCG-compliant attestation (DRTM, RTM)
• You need flexible policy-based key release that simpler secure elements do not support

For Linux-based IoT (industrial gateways, kiosks, medical workstations), TPMs are the standard. For microcontroller products, they are usually overkill — a discrete secure element is cheaper and fits the constraints better.

PUFs: niche, growing

Physically Unclonable Functions derive a unique device key from silicon manufacturing variability. The key is never stored — it is regenerated from the physical chip on each boot.

PUF use cases in 2026:

• Anti-counterfeit (genuine vs cloned device authentication)
• Key generation when storage is impossible (legacy SoCs, ultra-constrained devices)
• Supply-chain integrity (device identity established at silicon level, not at firmware programming)

Mostly vendor-specific implementations. Worth knowing about; rarely the deciding factor unless your project specifically calls for it.

How we decide on a real project

Walk through these questions in order:

1. What is the highest-value secret on the device? If it is “the application code we wrote,” software-only is usually enough. If it is “a payment key” or “a healthcare API token,” go higher.
2. What does compliance demand? PCI, HIPAA, EU Cyber Resilience Act, IEC 62443 — read what your auditor will ask for, not what marketing implies.
3. What is the BOM tolerance? A discrete secure element adds $0.50–$1.50 per unit. At low volume that is irrelevant; at million-unit volume it is real money.
4. What does the team know? Adding a chip you have never integrated adds 4–6 weeks of bring-up. If the threat model only marginally justifies the upgrade, the schedule cost may dominate.

What we typically recommend

For most consumer IoT in 2026: software-only with secure boot and flash encryption on a modern MCU. Defensible, simple, ships fast.

For products handling payments, identity, healthcare, or with high IP value: discrete secure element (ATECC608B is the default; SE050 if you need more capability).

For Linux-based IoT, industrial gateways, or compliance-driven enterprise products: TPM 2.0.

The decision matters. It is also reversible early in the project and very expensive to change after first volume production. If you are weighing the call, the conversation is worth having before you commit the schematic.