Embedded secure element integration — the chip in the product.
Need a secure element in your product? AmbiSecure, the security business unit of Ambimat Electronics, integrates secure elements into connected and IoT products as an engineering service: the security architecture, host-side software and APDU integration, applet integration, SCP03 and provisioning architecture, and the key and provisioning boundaries between your factory, your firmware and your back end. The physical transport between host and secure element is confirmed per project.
What is an embedded secure element?
An embedded secure element is a tamper-resistant chip that sits on your product's BOM and does one job: hold key material and run cryptographic operations on it without the keys ever crossing onto the host. The application MCU asks the secure element IC to sign, verify, or derive; it never sees the private key. That boundary is what makes the device identity survive firmware extraction.
Its side-channel and tamper countermeasures resist differential power analysis, fault injection and microprobing. It runs a small set of operations, not application code.
Use cases where an embedded secure element is the right choice:
- FIDO2 / WebAuthn authenticators (smart card, USB key, embedded SE in phone).
- Connected vehicles (V2X HSMs, automotive cybersecurity).
- Industrial IoT root-of-trust.
- eSIM / iUICC for cellular authentication.
- Document signing terminals (eIDAS signature flows).
What an embedded secure element integration covers
Chip selection
Match SE family to security tier (CC EAL6+ vs EAL4+), interface (industry options include ISO 7816, ISO 14443, SPI and I2C; the transport is confirmed per project), throughput, certifications.
Host driver
Driver on the host MCU / SoC for talking to the SE. APDU framing, secure channel (SCP03), session management. The architecture is set out in integrating a secure element with a host MCU.
SE-side applet
JavaCard applet running on the SE. Custom or off-the-shelf (FIDO, PIV, OpenPGP). Designed for the product's threat model.
Field operations
Issuance, key rotation, applet update under SCP03. Telemetry for tamper detection.
Secure element families we integrate
NXP SmartMX
JavaCard 3.x, GlobalPlatform 2.3.1, CC EAL6+ on flagship variants. Used in OnePass Card.
Infineon SLE / SLJ
JavaCard, CC EAL6+. Strong eID / payments deployment history.
Vendor-agnostic integration
For customers wanting to dual-source. We handle abstraction at the host-driver layer.
Implementation experience. Ambimat has deployed GlobalPlatform secure-channel provisioning using SCP02/3DES and SCP03/AES with customer systems, including NXP P71D600 and Infineon secure elements. See the SCP03 guide, case study and reference code.
Secure element vs TPM vs HSM
All three are “hardware that stores keys”, and they are not interchangeable. The question is not which is strongest — it is which one belongs in the architecture you are building.
- Secure element — lives inside the device, on its BOM. Built for per-device identity at low throughput. This is the one you embed in a product.
- TPM — lives on a PC or server motherboard. Built for platform attestation and measured boot, binding keys to a machine's software state.
- HSM — lives in a rack. Built for bulk server-side crypto, CA roots and key-management systems, at thousands of operations per second.
A connected product that needs its own identity wants a secure element; a fleet-management backend signing on behalf of that product wants an HSM. They frequently appear in the same system. A software key store is the right answer only where the threat model genuinely tolerates key extraction.
Secure Element vs TPM vs HSM — where each fits works through the boundaries, certifications and deployment contexts in full.
The product around the chip
A secure element is a component, not a product. Somebody still has to design the board it sits on, write the firmware that talks to it, get the radio through its approvals and make the whole thing repeatable in manufacturing. Ambimat does that work, and these are the starting points customers most often bring us.
AmbiTap NFC reader module
India-made contactless reader hardware for chargers, kiosks and embedded products. The NFC frontend moves data across the air interface and holds no credentials — the keys belong in a secure element or SAM, which is a separate layer of the same design.
AmbiIoT product engineering
Requirements-to-production engineering for connected hardware: architecture, electronics, RF, firmware, security integration, validation and preparation for manufacture. Engage it for a whole programme or for the single stage a team is short of.
Embedding a secure element in your product?
AmbiSEC FIDO and PIV modules have shipped to customers (see the AmbiSEC page). Tell us your host platform, the secure element you have chosen or are shortlisting, your provisioning flow and your threat model. We will scope the architecture, host-side and APDU integration, applet and SCP03 provisioning work, and confirm the physical transport for your design.