Secure Element vs. Secure Storage vs. TPM: Where Device Keys Belong

"Our keys are in a secure element." We hear this sentence in nearly every first conversation, usually delivered as the closing argument of the security concept. The sentence is often true and usually incomplete: a secure element is one answer to one question, where does key material live? Products have several secrets with several threat models, and the silicon that protects a device identity is not the silicon that protects bulk data at rest.

This note maps the options: what a secure element does, what secure storage does, where a TPM fits, and which question you should actually be answering when you pick one.

What a secure element actually does

A secure element is a separate chip whose job is to hold key material and perform cryptographic operations with it, without ever exposing the private key on its host interface. The application sends data in over I²C or SPI; a signature or MAC comes back. The key is generated inside, lives inside, and dies inside. Typical parts: Microchip ATECC608, ST STSAFE, NXP EdgeLock.

What that buys you: extraction resistance. Reading the key requires defeating the chip's protections, fault injection, invasive probing, side channels, rather than dumping flash. What it does not buy you, for free: correct key usage. An SE with no signing policy serves anyone who can talk to its bus. If the main MCU's debug port is open and firmware can send arbitrary sign requests, the key never left the chip, and the attacker never needed it to. We treat this exact failure pattern in the field note "The Key Is in a Secure Element". What We Check Next.

What secure storage protects

Secure storage is a different answer to a different question. It protects data at rest: configuration, databases, logs, bulk content, anything that must not be readable when the case is open. The mechanisms vary: RPMB partitions on eMMC/UFS (authenticated, replay-protected write access), file-based encryption layers, encrypted custom flash regions.

The critical detail is always the same: where is the key that encrypts the storage? If it is derived from a value in the MCU's readable flash, the protection is against casual copying, not against an attacker. If it is wrapped by a device-unique key in an SE or TPM, you have a real chain. In reviews, "encrypted storage" earns its name only after we have traced the key path end to end.

TPM: the standardized secure element

A TPM is a secure element with a public specification, and the specification is the value. PCRs that hash the boot chain, attestation keys and quotes, sealing data to system state, a standardized command set across vendors. On Linux-class products a TPM 2.0 is often the pragmatic choice: well-supported stacks, measurable boot, and remote attestation without custom protocol design.

The recurring TPM failure is presence without integration: the chip is on the BOM, the firmware never extends PCRs, nothing seals against them, no attestation is ever verified by the backend. That is a secure element in postal service only. The bill of materials is not an architecture.

Generated on-chip vs. imported

Across all three options, one design decision dominates: is the device-unique key generated inside the hardware, or injected during manufacturing? Generated on-chip: the private key never exists elsewhere, provisioning is simpler, and the supply chain question shrinks to trusting the chip. Injected: you can recover escrowed copies, batch-provision identities, and support key replacement, but now a database, a factory process, and everyone with access to both are part of your threat model. Most identity architectures we respect choose on-chip generation plus certificate attestation; most incidents we see trace back to injection processes that were convenient in pilot runs and never hardened for production.

Cost, pins and board reality

The non-technical constraints decide more designs than datasheets. A secure element adds a chip, BOM cost, board area and a second firmware lifecycle (SE applets need updates too). RPMB may already be included in your eMMC, the cheapest option that is actually wired up. A TPM on an embedded Linux board is a commodity; on a small RTOS product it can be architecturally heavier than the product around it. The wrong answer here is not the weaker chip, it is the strong chip whose integration was cut in the next cost-down revision, leaving the part present and mute.

The decision, compressed

Strip the vendor material and the choice reduces to two questions:

• What must survive physical access? Device identity and signing keys → secure element or TPM, keys generated on-chip. Bulk data at rest → secure storage, wrapped by a device-unique key from that element.
• Who must prove what to whom? If the backend needs evidence about device state (attestation), the TPM's PCR machinery earns its price. If only key custody matters, a discrete SE is the leaner design.

And one closing check that has nothing to do with silicon: whatever you chose, is it actually enabled, fused, provisioned and exercised in the production units, or only in the development boards that were demoed? The gap between those two answers is where assessments find their findings.