What is a secure element in IoT?

An IoT secure element is a dedicated, tamper-resistant cryptographic chip that generates, stores, and uses private keys within a hardware boundary that isolates them from the device's main processor. Common examples include Microchip's ATECC608C, Infineon's OPTIGA Trust M, and NXP's EdgeLock SE050. The critical property is that the private key never leaves the chip — all cryptographic operations happen inside the secure element, and even if the device's firmware is fully compromised, the key cannot be extracted remotely. This makes each device identity certificate physically bound to a specific device, which fundamentally simplifies monitoring and incident response at fleet scale.

What is the difference between a TPM and a secure element for IoT devices?

A Trusted Platform Module (TPM) and a discrete secure element both provide hardware-based key storage, but they differ in scope and form factor. TPMs implement a standardised feature set defined by the Trusted Computing Group, including secure boot measurement, platform attestation, and key storage — they are common in PCs, servers, and higher-end IoT gateways. Discrete secure elements like the ATECC608C are smaller, lower-power, and designed specifically for constrained IoT devices where a full TPM would be too large, too expensive, or too power-hungry. For most constrained IoT devices — sensors, actuators, smart home products — a discrete secure element is the right choice. For IoT gateways and edge devices with more compute, a TPM may be appropriate and offers a broader security feature set.

Why is the IoT key storage decision more than a BOM question?

IoT secure elements add $0.50–$2.00 to the bill of materials, which seems like a component cost question. In reality, they change your entire operational security model: how device identities can be cloned, what monitoring signals are trustworthy, how revocation works, and what incident response looks like. Hardware-bound keys make each certificate inseparable from a physical device, allowing monitoring to focus on behaviour. Software keys can be extracted or cloned, forcing you to invest in far more complex analytics to distinguish legitimate devices from copies, which often costs millions more than the saved hardware spend over the product lifecycle.

How do IoT secure elements change threat models compared to software key storage?

IoT secure elements generate and store private keys inside a tamper-resistant chip and never expose them to the main MCU. That means a Device Attestation Certificate or operational certificate bound to a secure element is effectively bound to a specific physical unit. Remote compromise of firmware cannot extract the key to clone identity onto other hardware, and physical attacks require sophisticated hardware lab capabilities. This shifts the threat model from large-scale remote identity cloning to per-unit physical compromise, which is a much easier problem to monitor and respond to at scale.

What extra monitoring is required when using software key storage on IoT devices?

With software key storage, private keys can be copied from one device to another, so a valid certificate no longer guarantees a unique physical device. Monitoring must therefore focus on detecting cloned identities: concurrent use of the same certificate from multiple locations, telemetry patterns inconsistent with deployment records, firmware version mismatches per identity, and abnormal volume or frequency of authentication events. Building and operating this analytics capability — and dealing with the higher false positive rate — adds substantial ongoing engineering and cloud cost that often dwarfs the hardware savings.

When is software key storage an acceptable choice for IoT devices?

Software keys can be rational for ultra-low-cost, short-lifecycle devices where component cost dominates and the impact of compromise is limited, or for devices deployed in tightly controlled physical environments where hardware attacks are unlikely. They are also appropriate for development and prototyping, and for existing fleets that cannot be retrofitted with secure elements. Even in these cases, you should pair software keys with short-lived certificates, strong firmware hardening, and realistic expectations about monitoring cost and risk.

How do Matter and the EU Cyber Resilience Act influence IoT key storage?

Matter requires that Device Attestation Certificate keys be 'securely stored' on devices and PAA providers increasingly expect hardware-backed key protection in practice, even if not yet enforced in certification labs. The EU Cyber Resilience Act emphasises security-by-design and proportional protection for high-risk use cases such as locks, cameras, and medical devices. For these categories, regulators and auditors are likely to view software key storage as inadequate when affordable hardware alternatives exist, making IoT secure elements the default for any device where compromise could have significant safety, privacy, or regulatory consequences.

IoT Secure Element vs Software Key Storage: The Decision That Shapes Your Security and Monitoring Architecture

By Dan Cvrcek, Founder, Axelspire · Updated March 2026

Part of the IoT Certificate Management pillar. This page explains how the IoT key storage choice you make during product design — secure element, TPM, or software keystore — determines your long-term monitoring costs, incident response options, and regulatory posture.

This Isn't a BOM Decision. It's an Architecture Decision.

Secure key storage for IoT devices is the single architectural choice that most determines your operational security costs at scale. When product teams evaluate whether to include an IoT secure element in their connected device, the conversation almost always starts with the wrong question: "What does it add to the bill of materials?"

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

6 more tools: Cost & Risk Explorer Timeline Builder Shadow Heatmap Process Transform Slider Scenario Comparator What-If Demo All tools & guide →

The answer — $0.50 to $2.00 per unit — either sounds trivial or significant depending on your production volumes and margins. At 100,000 units, that's $50K–$200K in additional component costs. At a million units, it's $500K–$2M.

But framing this as a component cost decision is the wrong analysis. The IoT secure element doesn't just change your BOM. It changes your entire operational model for device security — your monitoring architecture, your incident response procedures, your revocation strategy, and your ongoing certificate management costs.

IoT network operators and enterprise teams running their own Matter fabrics inherit this exact decision — the IoT key storage choice made by the manufacturer directly determines how they must design monitoring, incident response, and revocation across their entire fleet.

Three Models for IoT Private Key Storage

Model 1: Discrete Secure Elements (Hardware-Bound Keys)

An IoT secure element is a dedicated tamper-resistant cryptographic chip that generates, stores, and uses private keys within a hardware boundary isolated from the device's main processor. Common examples include Microchip's ATECC608C, Infineon's OPTIGA Trust M, and NXP's EdgeLock SE050. These are the most widely used hardware security components for constrained IoT devices — sensors, smart home products, wearables, and industrial endpoints.

The critical property: the private key never leaves the chip. It's generated inside the secure element using a hardware random number generator, and all cryptographic operations happen within the chip. The main MCU sends data to be signed; the secure element returns the signature.

Device identity is physically bound. A Device Attestation Certificate issued to a device with a hardware-bound key is that device. The IoT device identity certificate can't be copied to another device because the key can't be copied.

Cloning is impossible without physical tampering. An attacker who gains remote access to the device's firmware can read the certificate but cannot extract the private key to clone the device's identity.

Side-channel protection is built in. Modern IoT secure elements include protection against power analysis, timing attacks, electromagnetic emanation, and fault injection — controls that are impractical to implement in general-purpose microcontrollers.

Manufacturing provisioning is simplified. With solutions like Microchip's Trust Platform, the secure element arrives from the factory pre-provisioned with keys and certificates. Your contract manufacturer never handles private keys at all — they just solder the component onto the board.

Model 2: Trusted Platform Modules (TPMs)

A Trusted Platform Module (TPM) is a standardised hardware security component defined by the Trusted Computing Group that provides secure key storage, platform attestation, and measured boot capabilities. TPMs are common in PCs, servers, and higher-end IoT gateways, and implement a broader feature set than discrete secure elements.

For IoT, the TPM vs secure element choice comes down to device class. TPMs offer platform integrity measurement (PCR registers), sealed storage tied to platform state, and standardised APIs (TSS/PKCS#11) — features valuable for IoT gateways, edge compute devices, and industrial controllers that run Linux or RTOS with sufficient resources. But TPMs are typically larger, more power-hungry, and more expensive ($2–$5) than discrete secure elements, making them impractical for constrained sensors and battery-powered endpoints.

When to use a TPM for IoT: gateways, edge devices, industrial PLCs, and any IoT device with sufficient compute and power budget where platform attestation and measured boot are required — particularly in environments governed by IEC 62443 or where customers require TCG-compliant attestation.

When to use a discrete secure element: constrained endpoints — sensors, actuators, smart home devices, wearables — where size, power, cost, and simplicity matter more than full platform attestation.

Model 3: Software Key Storage

Software key storage means the IoT device's private key is generated by the main MCU and stored in flash memory or a dedicated partition. The key may be encrypted at rest, but it exists as data the MCU can read.

No additional hardware cost. The obvious advantage: no secure element on the board, no BOM increase, no new component supply chain.

Key extraction is possible. An attacker with physical access can dump flash and extract the private key. Depending on MCU protections, this might require JTAG/SWD access, a firmware exploit, or glitching — but it's fundamentally achievable in a way that IoT secure element extraction is not.

Remote key extraction is possible if firmware is compromised. A firmware vulnerability that grants arbitrary read access can exfiltrate the private key over the network, creating clones indistinguishable from legitimate devices.

Simpler development workflow. Developers can generate test keys, inspect certificates, and debug TLS handshakes without interacting with a hardware coprocessor — useful for prototyping and early development.

IoT secure element vs software key storage: two security models for IoT devices showing hardware-bound keys versus software keystores — Hardware-bound keys (secure elements and TPMs) vs software key storage: different threat models and operational implications for IoT fleets.

The Monitoring Divergence

Hardware-Bound Keys: Monitoring for Behaviour

When keys can't be extracted — whether stored in an IoT secure element or a TPM — you know that a valid certificate is a specific physical device. Your monitoring architecture can focus on detecting anomalous behaviour from authenticated devices.

Geographic anomaly detection. Device presenting valid credentials from a network location inconsistent with its known deployment location.

Usage pattern monitoring. Authentication frequency, data volume, and API call patterns that deviate from expected operational profiles.

Concurrent session detection. The same device identity appearing in two locations simultaneously is definitionally impossible in legitimate operation, so it is immediately actionable.

The monitoring infrastructure is relatively straightforward: collect authentication telemetry, build baseline behavioural profiles per device type, and alert on deviations. The signal-to-noise ratio is high because you trust the identity layer.

Software Keys: Monitoring for Identity Duplication

When keys can be extracted, a valid certificate no longer proves device identity — it proves someone has the key. Your monitoring must detect cloned identities.

Certificate usage from multiple network locations. The same certificate appearing from different geographies may signal clones — but you still have to decide which instance is legitimate.

Temporal pattern analysis. Authentications outside expected schedules could indicate clones running at different cadences.

Firmware version correlation. Certificates showing up with firmware combinations that shouldn't exist together suggest identities copied onto different hardware.

Volume and throughput analysis. A device identity generating far more traffic than expected might indicate multiple instances using the same credentials.

This monitoring infrastructure is substantially more complex, with higher false positive rates and more expensive investigations. The cost of detecting and investigating cloned IoT device identities often exceeds the hardware savings within the first two years of deployment.

IoT monitoring divergence: behaviour monitoring with secure elements vs identity duplication detection with software keys — With hardware keys you monitor for behaviour; with software keys you must detect cloned identities.

The Cost Comparison That Actually Matters

For a 250,000-device deployment over a 7-year product lifecycle, the numbers are stark:

Hardware secure element path: incremental component and provisioning costs plus simpler monitoring and fewer, shorter investigations, leading to a total around $1.4M over 7 years.

Software key storage path: savings on hardware offset by higher provisioning complexity, more expensive monitoring, more investigation effort, and higher breach/recall risk, leading to an estimated $3.3M–$4.8M — or more if a major incident occurs.

The $375,000 you "save" on hardware often costs $1.9M–$3.4M in additional operational complexity over the product lifecycle, even before incidents are considered.

The Complicating Factors

There are legitimate scenarios where software key storage is rational for IoT devices:

Ultra-low-cost, short-lifecycle devices where BOM dominates and risk is limited.
Devices in physically controlled environments where physical access is already restricted.
Development and prototyping environments.
Existing fleets that cannot be retrofitted; focus there should be on monitoring and future revisions.

Matter and CRA Implications for IoT Key Storage

The Matter standard doesn't explicitly mandate hardware key storage, but it does require DAC keys to be "securely stored," and PAA providers strongly recommend IoT secure elements in practice.

The EU Cyber Resilience Act requires "appropriate" security measures proportionate to risk. For high-impact devices — medical, security, smart locks — software key storage is increasingly hard to justify when IoT secure elements are widely available at $0.50–$2.00 per unit.

The Infrastructure Intelligence Connection

This decision connects directly to our infrastructure intelligence thesis. Certificate telemetry is only as valuable as the identity layer it reflects.

With hardware-bound keys — whether IoT secure elements or TPMs — telemetry gives reliable intelligence about which devices are active, where they're deployed, and whether they're behaving anomalously. With software keys, the same telemetry may describe legitimate devices or clones, degrading the value of your data.

Making the IoT Key Storage Decision

Use an IoT secure element if: device lifetime exceeds two years, BOM can absorb $0.50–$2.00, the device handles sensitive data or physical security, or you want to minimise long-term monitoring and incident costs. This is the right choice for the vast majority of IoT devices.

Use a TPM if: the device is a gateway, edge compute node, or industrial controller with sufficient resources, and your security requirements include measured boot, platform attestation, or compliance with TCG standards.

Consider software keys if: devices are disposable or very short-lived, BOM is extremely constrained, deployments are in physically secure locations, and you explicitly accept higher monitoring costs and risk.

Never use software keys if: the device is a medical device, security system, or smart lock where the liability exposure and regulatory expectations make hardware-backed secure key storage for IoT devices the only defensible choice.

Continue to IoT Device Identity Certificates: Who Owns Them and Why Platform Choice Matters to understand how your cloud platform choices interact with your key storage architecture, or revisit The IoT Certificate Lifecycle Nightmare to see how IoT key storage impacts provisioning, renewal, and revocation in practice. For a complete implementation guide covering SE/TPM part selection, certificate hierarchies, and secure boot integration, see Hardware-Backed Device Identity. For how keys get into the SE at manufacturing time — and which provisioning model keeps them most secure — see Factory Provisioning.