AmbiSEC IoT Security Co-Processor — 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.
Part of a CRA-aligned security architecture.
According to the European Commission, the EU Cyber Resilience Act (CRA) introduces mandatory cybersecurity requirements for products with digital elements — across design, development, production, and vulnerability handling over the support period. The AmbiSEC secure module is built to sit inside that architecture as the hardware trust layer. It supports CRA-aligned secure-by-design and vulnerability-handling expectations; it does not, by itself, make a product compliant or replace conformity assessment.
Secure by design & by default
A hardware root of trust, non-extractable key storage, and per-device identity burned at factory give a manufacturer a defensible answer to “where do the keys live” — the question secure-by-design starts from. No default passwords, no shared fleet secret.
Vulnerability handling & updates
Secure OTA verification, anti-rollback counters, and credential rotation support controlled, authenticated updates across the support period — the mechanism a CRA vulnerability-handling process relies on to ship fixes without opening new attack paths.
Lifecycle & evidence
Device identity and an attestation chain back to a factory key-ceremony record help manufacturers prepare evidence for secure-lifecycle obligations and keep devices accountable for their full service life. AmbiSEC can form part of a manufacturer’s CRA technical and security architecture.
Blog: CRA for connected hardware & IoT
What the CRA means for manufacturers of connected devices, embedded systems, and smart-city products.
Blog: secure by design under the CRA
Why hardware-backed trust matters — and where hardware-backed trust with AmbiSEC fits a CRA-ready architecture.
Blog: CRA vulnerability handling
Support periods, reporting timelines, and lifecycle maintenance manufacturers need to prepare.
This summarizes publicly available CRA information for product-security awareness. Manufacturers should refer to the official EU sources and their own compliance process for product-specific obligations. AmbiSEC supports CRA-aligned security architecture but does not replace conformity assessment or legal review. See the full AmbiSecure products & CRA readiness mapping.
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.
Building automation controllers
BACnet/MODBUS controllers on a hospital, hotel, or campus network — where the OT plane touches the IT plane. Pairs with the Ambimat building-automation platform for retrofits on existing VRV / VRF systems.
Where the co-processor lands in connected-vehicle infrastructure.
The dual-domain co-processor's signing surface, key isolation, and applet platform map directly onto the V2X OBU/RSU requirement profile. Standards alignment, not yet automotive-grade certification.
| Automotive operating range | Extended automotive temperature range (−40°C to +105°C) available — relevant for OBU/RSU deployments in Indian road environments. |
|---|---|
| V2X key storage | IEEE 1609.2 compatible key isolation. ECDSA-P256 and P-384 signing operations hardware-isolated from the host MCU. |
| V2X certificate lifecycle | Supports Enrolment Credential (EC) storage and Pseudonymous Certificate (PC) batch-management patterns consistent with ETSI TS 102 941. |
| Attestation for EA enrolment | Hardware-signed attestation responses enable Enrolment Authority verification that key material resides in a certified secure element before EC issuance. |
| Silicon-level certification | The underlying secure-element silicon carries Common Criteria EAL6+ certification at the chip level. Automotive-grade certification (ISO 26262, ASPICE) of the integrated AmbiSEC Module product is a target, not yet claimed. |
Industry: Connected Mobility
Why V2X infrastructure demands hardware-backed identity. Standards, threat model, India context.
Solution: V2X security
EA/AA PKI architecture, pseudonymous certificates, HSM-backed provisioning, certificate lifecycle.
Technology: V2X PKI
IEEE 1609.2 certificate format, ETSI TS 103 097 message headers, Butterfly Key Expansion, revocation.
Solution: device identity at scale
The architectural unification page across V2X, eSIM, IoT, and embedded fleets. Where the Co-Processor sits inside a broader credential lifecycle.
Reference: IEEE 1609.2
Structured V2X certificate reference — the byte-level shape of the credentials the Co-Processor holds.
Reference: ETSI TS 102 941
V2X PKI architecture — the authorities the Co-Processor enrols with and refreshes against.
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 EAL6+ 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.