A second silicon domain for connected devices — keys never reach application firmware.
AmbiSEC Module is a dual-domain IoT security co-processor. The MCU domain runs the application — firmware, radios, sensor acquisition. The cryptographic security domain holds the device identity, signs and verifies, prevents replay, and authenticates every OTA image before it boots. The two domains share a bus, not a memory map.
Multi-hop = multi-risk.
A connected device rarely talks to the back end directly. Every relay node — gateway, concentrator, mesh peer — is a place where firmware can be tampered with, traffic can be replayed, or an attacker can impersonate the device. Software-only trust models do not survive that geometry.
Every relay is an attack surface
A device that speaks to a gateway, that speaks to a concentrator, that speaks to the cloud, is only as trustworthy as the weakest hop. Any one of them can be coerced into forwarding lies.
Replay, impersonation, firmware threats
Captured packets get replayed. Sibling devices get impersonated. Malicious firmware images get pushed under the cover of a legitimate OTA channel. These are not theoretical — they are the standard playbook.
Software-only trust runs out
A key sitting in MCU flash is one buffer overflow away from exfiltration. Once it leaves the silicon, the device's identity travels with the attacker, not the hardware.
Dual-domain. Two pieces of silicon, one bus, one trust boundary.
The MCU domain handles everything that talks to the outside world. The cryptographic security domain holds the keys and does the operations the MCU is not allowed to do itself. The MCU asks; the security domain answers. Private material does not cross the boundary.
What the security domain does — and why it matters.
Secure boot
Every firmware image is verified by the co-processor against an issuance public key burned in at factory, before the MCU executes a single instruction from it. A signature failure is a boot failure.
Anti-replay
Monotonic counters live inside the security domain. A captured frame from yesterday cannot be reused today — the counter has already moved past it, and the MCU cannot rewind it.
Credential isolation
Device identity and operational keys are stored in the co-processor's TEE-class credential store. A compromise of the application firmware does not yield a compromise of the keys.
Encrypted communication
Session keys derived inside the co-processor. Confidentiality and integrity end at the co-processor, not at the MCU's network stack — closing the gap that classic embedded TLS leaves open.
Hardware-rooted device identity
A 128-bit unique device identity burned at factory, signed under AmbiSecure's issuance chain. The device proves it is itself with a signature, not a serial number. No defaults, no shared secrets.
OTA trust validation
A dedicated OTA verification applet checks every incoming image: signature, version, rollback protection. The MCU may host the download buffer; only the applet decides whether the image becomes the next boot.
Credential rotation
Operational keys can be rotated over the air against the same root identity. The device stays in field through its full lifecycle; the keys that derive from the root change as policy requires.
Cryptographic attestation
Each device produces a verifiable attestation that chains back to AmbiSecure's issuance CA. Auditors can walk the chain from a deployed device to a factory key ceremony record at any future point.
Tamper resistance
Active shield, voltage and clock monitors, fault-injection countermeasures — the standard secure-element defences live inside the co-processor, not the MCU.
Aligned with the TEC IoT security baseline, by construction.
TEC 31318 is the Telecommunication Engineering Centre's IoT security framework. AmbiSEC Module's dual-domain design covers the baseline categories at the silicon level — not as a policy add-on, but as the architecture itself.
| No default passwords | Unique 128-bit device identity burned at factory. There is no factory-default credential to brute-force. |
|---|---|
| TEE credential store | Hardware-isolated key vault inside the cryptographic security domain — secure-element-class storage, non-extractable by design. |
| Secure boot | Image signature verified by the co-processor before the MCU executes the new firmware. Boot is gated on the verdict. |
| Multi-hop encryption | Three deployment models — hop-by-hop, end-to-end, hybrid — selected to match the trust geometry of the link layer. |
| Secure OTA | OTA verification applet inside the security domain. Credential rotation under the same root identity. |
Compliance is a function of full-system design, not silicon alone. AmbiSEC Module provides the hardware primitives the framework asks for; the certification path is a joint effort with the OEM integrator.
Three encryption models. Pick the one the link layer deserves.
Not every IoT link has the same threat model. A LoRa packet crossing five untrusted relays is not the same as a Wi-Fi packet on a customer network. The co-processor supports all three patterns so the integrator can match the cryptography to the topology.
Hop-by-hop
Each link encrypted independently. Gateways need to be trusted to decrypt-and-re-encrypt. Lowest overhead. Right for tightly-managed industrial backhauls.
End-to-end
Device-to-cloud cryptography. Gateways forward ciphertext blindly. Highest confidentiality. Right for fleets where the gateway is field-owned and not the trust anchor.
Hybrid
End-to-end for payload, hop-by-hop for control frames. The pragmatic real-world mode — payload confidentiality preserved while operations like throttling and routing remain inspectable.
The MCU side handles every radio you ship. The co-processor never has to.
Radios live in the MCU domain — BLE for proximity, Wi-Fi for premises connectivity, LoRa for long-range industrial telemetry, Sub-GHz for licensed bands. The co-processor talks only to the MCU, over a simple bus. That separation is what makes the cryptographic surface tractable to reason about.
BLE & Wi-Fi
Consumer-grade and premises-grade radios. Session keys derived inside the co-processor; the MCU handles framing.
LoRa & Sub-GHz
Long-range, low-power industrial telemetry. The co-processor's anti-replay counters survive the long backhauls these networks expose.
Edge gateways & concentrators
In hybrid encryption mode the gateway sees control frames and forwards payload ciphertext blindly. Telemetry stays confidential past the field network boundary.
Where AmbiSEC Module fits in real product lines.
OEM integration
Drop the co-processor onto the PCB next to the MCU. Reference C driver for the host MCU; reference applet stack on the secure element. Two weeks to first signed boot in our reference designs.
Industrial deployment
Operational keys rotate across the fleet against a per-device root that never moves. Devices remain in field through their full service life without recall.
Smart infrastructure
Metering, lighting, traffic, water, grid — deployments where physical access to devices cannot be controlled, and identity must survive tampering attempts.
Connected products
Consumer and prosumer devices that need real device identity — not a default password, not a per-fleet shared key, not a serial number.
Energy systems
DER controllers, EV charging, battery management — deployments where signed firmware authentication is the difference between a safe update and a catastrophic one.
Edge gateways
When the gateway itself needs hardware-rooted identity to relay telemetry under its own signed attestation, not under a per-deployment shared secret.
Removable for products that ship identity with the user. Solderable for products that don’t.
Nano-card removable secure element (4FF)
A removable secure-element form factor for products where the device identity travels with the user, or where field-replacement of the credential is a requirement. Mechanically familiar; logically a JavaCard secure element with the AmbiSEC applet stack on board.
MFF2 solderable embedded secure element
Surface-mount, 8 × 6 mm, treated as a normal PCB component. Right for infrastructure-grade and industrial deployments where the device is intended to remain bound to its identity for its full service life. No socket, no removable card.
Both form factors carry the same AmbiSEC applet stack and the same trust model. AmbiSEC is a secure-element deployment, not a telecom SIM — the form factor is borrowed; the role is identity, not subscriber identification.
Where AmbiSEC Module sits in the standards landscape.
| Secure element class | Hardware-isolated cryptographic execution environment. Tamper-resistant package. Active shield, voltage / clock monitors, fault-injection countermeasures. |
|---|---|
| Hardware-backed identity | Per-device unique key generated and stored inside the SE. Non-extractable. Attested by AmbiSecure's issuance CA. |
| GlobalPlatform | JavaCard applet platform with GlobalPlatform Card Specification loading and personalisation patterns. |
| SCP03 | Secure channel protocol for applet loading and key personalisation, authenticated under per-keyset issuer keys. |
| Secure OTA | Image signature verification inside the co-processor; rollback protection via in-domain monotonic version counter. |
| Device attestation | X.509 attestation chain — device → per-batch attestation CA → AmbiSecure issuance CA → HSM key ceremony record. |
| PKI integration | Standard CSR / certificate enrolment flows; mTLS credential storage; per-fleet issuance policies on the back-end. |
| Cryptography | ECC P-256 / P-384, RSA 2048 / 3072, AES-128 / 256, SHA-256 / SHA-384, HMAC, ECDSA. |
| Certification path | Designed against Common Criteria EAL5+ secure-element targets. SE-compliant integration patterns for AVA_VAN.5. Final certification is engaged per OEM programme — this page does not assert any specific certificate as already issued. |
AmbiSEC Module is one node in a larger trust system.
The co-processor is the hardware tier. The applets, the JavaCard platform, the validation server, the PKI, and the secure-mail surface all sit on the same trust spine.
IoT Security Applets
JavaCard applets the co-processor runs — identity, attestation, OTA verifier, mTLS credentials.
JavaCard Applet Platform
The wider applet platform — FIDO, PIV, OpenPGP, NDEF, and the GlobalPlatform tooling.
IoT Solution
End-to-end view — co-processor, key manager service, operator FIDO MFA, attestation pipeline.
JavaCard development
Custom applet engineering for SE-based device identity — the team that wrote the AmbiSEC stack.
FIDO Validation Server
Operator MFA for the cloud-side management plane that talks to the co-processor.
Secure element integration
How to bring a secure element into a connected product end-to-end.
Technology: secure elements
The silicon class the co-processor belongs to.
Technology: attestation
The cryptographic ceremony the co-processor's identity chain implements.
Blog: secure IoT identity
Cornerstone read — the five applets, threat model, host MCU integration.
Questions we hear from engineering teams.
What is an IoT security co-processor?
A dedicated piece of silicon that sits next to the main MCU and owns everything cryptographic — identity key, signing, verification, replay counters, OTA signature check. The MCU does sensing and radios; the co-processor does the work the MCU cannot do safely.
Why separate cryptographic execution from the MCU?
Because an MCU compromise should not equal a key compromise. The application firmware is large, frequently updated, and routinely exposed to untrusted input. Moving the key into an isolated co-processor means a compromised MCU can request signatures but cannot extract them.
What is secure OTA verification?
The cryptographic check on a firmware image happens inside the co-processor, against an issuance public key burned in at factory and not modifiable by the MCU. The MCU may host the download; the co-processor decides whether the image becomes the next boot.
What is hardware-rooted device identity?
A unique key generated and stored inside a tamper-resistant secure element, non-extractable by design and bound to a specific piece of silicon. The device proves it is itself by signing a challenge with that key.
Why use MFF2 secure-element deployments?
MFF2 is the solderable 8 × 6 mm embedded secure-element form factor. For industrial and infrastructure deployments where the device must remain bound to its identity for its full service life, surface-mount integration is the right answer — no socket, no removable card.
Is AmbiSEC Module a SIM?
No. It is a secure-element deployment that borrows the nano-card and MFF2 mechanical form factors. Its role is device identity and cryptographic execution, not subscriber identification on a cellular network.
Designing a connected product that needs real keys?
We will sit with your hardware lead and your firmware lead, walk the architecture, and show how the co-processor integrates without rewriting the MCU side. Reference designs available under NDA.