Secure Element IC Selection: Identity, Provisioning, and CRA Evidence

Table of Contents

• Define the Threat and Product-Lifecycle Requirement
• Separate Secure Elements From TPMs, TEEs, and MCU Security
• Map Identity, Keys, Secure Boot, and Attestation
• Plan Cryptographic Agility and Update Boundaries
• Make Provisioning Ownership Part of Selection
• Connect Hardware Evidence to CRA Readiness
• Qualify Certification, Lifecycle, and Replacement Risk

A secure element is useful only when its trust boundary matches the product’s threat model and manufacturing process. Protected key storage is one capability; the product also needs a defined identity, cryptographic protocols, host integration, provisioning authority, certificate lifecycle, update strategy, and evidence that survives supplier or firmware changes.

This is why the selection cannot be completed from an algorithm checklist. The same chip may be appropriate for device authentication in one product and unsuitable for secure boot or field credential renewal in another because the object model, host interface, provisioning service, or lifecycle does not fit.

Define the Threat and Product-Lifecycle Requirement

List the assets the hardware must protect: device private keys, code-signing trust anchors, product identity, user credentials, payment keys, usage counters, calibration secrets, or cloud onboarding material. Then identify credible attackers, including remote software exploitation, physical probing, board replacement, firmware rollback, credential extraction from manufacturing systems, and unauthorized cloning.

For each asset, define the required operation. A private key may need to generate signatures without ever leaving the secure element. A secure-boot root may need to verify a firmware manifest before the main processor runs. A monotonic counter may need protected update semantics. “Stores keys securely” is not specific enough to select an architecture.

Set the expected support life and field state transitions. Products may be manufactured by one partner, claimed by a customer, transferred between owners, serviced offline, rotated to new certificates, revoked, or decommissioned. The secure element and its backend must support those transitions without exposing a shared factory secret.

NIST’s April 2026 Foundational Cybersecurity Activities for IoT Product Manufacturers asks manufacturers to consider whether capabilities should be hardware-based or cryptographically bound. It gives a hardware root of trust with protected key storage, secure boot, and authenticity as an example, while also asking whether those capabilities can evolve for future cryptography. That is a risk-based design prompt, not a requirement to add the same chip to every product.

Separate Secure Elements From TPMs, TEEs, and MCU Security

A discrete secure element is a tamper-resistant IC designed to protect assets and perform controlled operations. A Trusted Platform Module (TPM) follows standardized commands, objects, platform measurements, and attestation patterns widely used in computers and infrastructure. A Trusted Execution Environment (TEE) isolates code within a main processor. A security-capable MCU can integrate secure boot, protected storage, accelerators, and isolation features in the same package as the application.

These architectures overlap without being equivalent. A discrete device can isolate long-term keys from application firmware and provide a separately evaluated boundary. It also adds a bus, driver, provisioning flow, latency, power, BOM line, and vendor dependency. An integrated MCU can reduce parts and boot dependencies but may share more of the attack surface and product lifecycle with application silicon.

Choose from the required standards and protocols. A product that needs a PC-compatible TPM stack should not treat a generic authentication IC as a drop-in TPM. A device using TLS client authentication may need only protected key generation, signing, and certificate storage. A payment or identity product may require a secure-element platform, applet, or certification beyond general IoT authentication.

GlobalPlatform’s introduction to secure elements describes secure elements as tamper-resistant platforms capable of securely hosting applications and confidential data. Use that architecture definition alongside the selected vendor’s command reference; it does not make every secure element software-compatible.

Map Identity, Keys, Secure Boot, and Attestation

Create a function matrix for device identity, key generation/import, supported curves and algorithms, certificate storage, random-number generation, hashing, signing, key agreement, encrypted host channel, counters, policy objects, secure boot, measured boot, and attestation. Mark which functions execute inside the secure boundary and which depend on host software.

Secure boot and device authentication are different claims. Secure boot verifies that authorized code starts; device authentication proves possession of an identity credential to another party. Attestation can make a signed statement about software or device state. One root key can sometimes support a hierarchy, but protocol separation, revocation, audit, and compromise containment may require different keys and policies.

Check algorithm details rather than family names. Record key sizes, curves, padding, certificate formats, derivation functions, counters, session limits, random-number behavior, and protocol interoperability. Verify execution time, wake latency, command concurrency, endurance, and behavior during power interruption.

Host integration is part of the security boundary. I2C or SPI electrical compatibility does not secure commands on the board. Determine whether the device supports authenticated or encrypted host sessions, how session keys are established, how replay is prevented, and what an attacker controlling the host can still request. If the threat includes board-level access, plaintext commands and unprotected host firmware may defeat the intended control even if private keys remain non-exportable.

Plan Cryptographic Agility and Update Boundaries

Products with long service lives need a documented path for algorithm deprecation, certificate rollover, compromised trust anchors, and backend migration. Identify which algorithms are fixed in ROM, which policies can be updated, which public trust anchors can be replaced, and whether new credentials can be provisioned after deployment.

An immutable root can provide a stable anchor, but excessive immutability can strand a product when protocols change. Conversely, an update path with weak authorization can undermine the root it was meant to preserve. Define who can authorize changes, how rollback is prevented, what evidence is logged, and how recovery works if a legitimate update fails.

Do not claim post-quantum readiness because a device stores a large blob or has an “updatable” label. Check support for the exact algorithm, key and signature sizes, command transport, memory, performance, and certificate chain. If post-quantum operations remain in the host, state which secrets or trust decisions the secure element still protects.

NIST IR 8259r1 specifically raises the tension between immutable roots and the ability to move to post-quantum cryptography. Include that decision in the product-security plan while there is still freedom to change the hardware and provisioning design.

Make Provisioning Ownership Part of Selection

Provisioning determines who creates and controls the trust material. Common models include vendor-provisioned generic credentials, customer-specific keys injected by the semiconductor vendor, injection at a contract manufacturer, and in-product generation followed by certificate enrollment. Each changes custody, lead time, minimum-volume constraints, audit evidence, and recovery.

Answer these questions before issuing a production purchase order:

• Who owns the root certificate authority and signing systems?
• Where are private keys generated, and can they ever be exported?
• How is each chip identity bound to the product serial number and manufacturing record?
• What proves that a failed or scrapped unit cannot be activated later?
• How are certificates renewed, revoked, transferred, and retired?
• Can blank, development, and production-provisioned order codes be confused?
• What tools, secure rooms, hardware security modules, operator roles, and logs are required at each factory?

The Microchip ATECC608A page illustrates a secure-authentication device with protected key operations and associated provisioning options. It is a family example, not evidence that one ATECC608 configuration satisfies every identity or compliance model. Microchip, NXP, and Infineon use different device families, tools, credential services, and order-code conventions.

Treat a provisioned part number as configuration-controlled material. The silicon marking may not reveal customer keys, certificate policy, locked zones, lifecycle state, or personalization template. Receiving, traceability, rework, RMA, and excess-inventory processes need controls that preserve that distinction without exposing secrets.

Connect Hardware Evidence to CRA Readiness

The EU Cyber Resilience Act (CRA) applies cybersecurity and vulnerability-handling requirements to products with digital elements placed on the EU market. The European Commission’s current CRA overview states that the main obligations apply from December 11, 2027, while reporting obligations apply from September 11, 2026.

The Commission’s July 31, 2026 reporting guidance states that manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security, with an early warning within 24 hours and a full notification within 72 hours. The CRA is technology-neutral: it does not make a secure element mandatory for every product.

A secure element can still improve the evidence and response model when it has a defined role. Maintain the device revision, firmware/command-library version, provisioning template, certificate chain, cryptographic configuration, security advisories, PCNs, vulnerability contacts, affected product mapping, and remediation path. If a vulnerability occurs, the manufacturer needs to know which finished products contain the affected hardware or library and whether credentials can be rotated or firmware updated.

The existing CRA component-supplier checklist owns the reporting workflow and supplier-evidence process. This page owns the secure-element architecture and records that feed that process. Keeping those intentions separate prevents a policy update from turning the device-selection page into a duplicate compliance article.

Qualify Certification, Lifecycle, and Replacement Risk

Record any Common Criteria, FIPS, payment, identity, automotive, or platform certification by exact device, firmware, configuration, protection profile, certificate number, status, and validity. A vendor’s certified family does not automatically confer certification on every package, firmware revision, customer applet, or finished product.

Review security advisories, disclosure process, software-support policy, PCN/EOL process, data retention, endurance, environmental grade, package, and expected supply life. A long product lifecycle may outlast the backend SDK or certificate service even when silicon remains available. Preserve API documentation, tools, libraries, licenses, and test vectors needed to build and service the product.

Second sourcing is architectural. Another secure element may support the same cryptographic algorithm while using a different object model, provisioning authority, certificate chain, driver, timing, and certification. Plan an abstraction boundary only where the product can test it; do not claim drop-in compatibility from I2C address and package alone.

Validate factory enrollment, first boot, host authentication, valid and invalid commands, power interruption, counter/endurance limits, certificate renewal, revocation, firmware update, rollback rejection, RMA, ownership transfer, and decommissioning. Archive expected test vectors without storing production secrets in ordinary quality records. The final approval package should connect the threat model, exact IC configuration, provisioning custody, software version, certificates, lifecycle plan, and regulatory evidence into one traceable decision.