Secure elements: where the keys actually live.
A secure element is a tamper-resistant chip whose entire purpose is to store keys and run cryptographic operations on those keys. It is the foundation that every hardware-rooted credential is built on — smart cards, FIDO authenticators, IoT device identity, eSIM. This is the technology overview.
What a secure element is
A secure element (SE) is a chip:
- Designed for the single purpose of holding key material and executing cryptographic operations on it.
- Common Criteria EAL6+ certified for the chip class (silicon + OS), often with FIPS 140-3 Level 2 or higher for the cryptographic-module side.
- Resistant to physical-attack classes that consumer chips are not — differential power analysis, fault injection, microprobing.
- Lives on the BOM of something else: a smart card, an IoT controller, a phone’s system-on-chip.
Secure elements are not general-purpose processors. They do a small number of operations very securely; they do not run application code in the way an MCU does.
How it differs from TPM and HSM
| Property | Secure element | TPM | HSM |
|---|---|---|---|
| Where it lives | Inside a device | On a PC/server motherboard | Data centre / rack |
| Designed for | Per-device identity, smart cards | Platform attestation, boot integrity | Bulk crypto, CA root, KMS |
| Throughput | Low (a few ops/s typical) | Low | High (10,000s+ ops/s) |
| Per-unit cost | Low | Low | High |
For a fuller treatment, see Secure Element vs TPM vs HSM — Where Each Fits.
Where AmbiSecure uses secure elements
OnePass Card
Smart card form factor. Secure element holds the FIDO2 keypair and badge credential.
OnePass USB Key
Hardware security key. Secure element holds the FIDO2 keypair.
IoT Security Co-Processor
Discrete secure element for connected-device manufacturers. Goes on the device BOM.
JavaCard Applets
Twelve applets co-resident on a single CC EAL6+ secure element.
Digital Signature Token
USB-attached secure element for PKI signing operations.
Secure element integration
The solution-level overview of putting a secure element on a new product line.
Engineering ground rules
- Keys are generated on-chip. A secure element that ever exposes a private key in cleartext, even at provisioning time, is being used incorrectly.
- Attestation in the issuance flow. The certification of the chip class is only useful if your CA verifies the attestation at certificate-signing time. (See PKI Credential Issuance for Workforce and Government.)
- Use the chip’s crypto coprocessor. The framework primitives are side-channel-hardened. Reimplementing crypto in card-side bytecode loses that protection.
- Personalise under secure messaging. SCP02 / SCP03 at the personalisation line; refuse plain APDUs once personalised.
- Treat the chip as the trust boundary. Everything around the chip is plumbing.
Related on the AmbiSecure site
- Blog: Why Hardware-Backed Identity Matters
- Blog: Secure Element vs TPM vs HSM
- Blog: JavaCard Applet Development for Enterprise Identity
- Blog: Designing Secure Credential Lifecycle Management
- Case study: Secure device identity
- Brochure: Device identity / IoT
- Technology: JavaCard
- Certifications — which secure-element classes we ship under
Putting a secure element on your BOM?
The first call is engineering. Bring your BOM constraints, your SMT cadence, and your PKI. We’ll bring an architecture sketch.