Secure by Design Under the CRA: Why Hardware-Backed Trust Matters
“Secure by design” is the phrase in the Cyber Resilience Act that engineers can actually act on. It is not a paperwork requirement — it is a statement about where security lives in a product. For connected hardware, the honest reading is that secure-by-design begins with a single architectural question: can an attacker who holds the device extract its keys? This piece walks the threat model the CRA's secure-by-design expectation is really about, and shows where a hardware root of trust — specifically the AmbiSEC module — fits.
What secure by design means in practice
According to the European Commission, the EU Cyber Resilience Act expects products with digital elements to be secure by design and by default: cybersecurity considered from the planning and design phase, a secure out-of-the-box configuration, and a minimised attack surface. For software, that maps onto familiar practices — threat modelling, least privilege, safe defaults. For connected hardware, it reduces to a small set of foundational decisions that are nearly impossible to revise once a fleet ships:
- Where do the private keys live, and can the application firmware read them?
- How is each device's identity established, and is it unique per device?
- How is a firmware update authenticated before it runs?
- How is a key rotated or a credential revoked over the supported life?
Each of these is answered at design time by the trust architecture, not later by a patch. That is why secure-by-design, for hardware, is mostly a question of what the silicon guarantees.
The threat model secure-by-design is defending against
Field-deployed connected products face a threat model that desktop and server software does not. The device is physically reachable by people who are not the manufacturer, and a laboratory attacker who buys one unit has unlimited time with it. Five failure modes recur:
- Cloned devices. If identity is a copyable secret, two devices can present the same identity. The back end cannot tell the clone from the original.
- Exposed keys. A private key in general-purpose flash is bytes an attacker recovers through a debug port, an external flash chip, or decapsulation.
- Insecure provisioning. Keys injected without protected custody, or a shared master key burned into every unit, turn one leak into a fleet-wide compromise.
- Weak firmware identity. If the update verifier and its key live in rewritable firmware, malicious firmware can authorise itself.
- Poor lifecycle control. No way to rotate a compromised credential, no anti-rollback, no revocation — so a single incident has no clean remediation.
These are not implementation bugs a careful engineer catches on review; they are properties of an architecture that stores trust in software. We unpack the full version of this in why software-only device trust fails.
Software-only security vs hardware-backed trust
The distinction the CRA's secure-by-design expectation pushes toward is the distinction between protecting a secret with more software and removing the secret from software entirely. Software mitigations — encryption at rest, obfuscation, secure-boot chains rooted in firmware — raise the cost of an attack but leave the key reachable in principle. A hardware root of trust changes the category: the private key is generated and used inside a tamper-resistant boundary and never leaves it. The host asks the secure element to sign or decrypt; it never holds the key. An attacker who extracts the firmware finds key handles, not keys.
The practical consequence is economic. With software-only identity, compromising one device yields the technique for the whole fleet, so attacker cost is flat in fleet size. With hardware-bound identity, each device requires its own physical attack against certified silicon, so attacker cost scales with the fleet. That shift — from “break one, break all” to “break one, break one” — is the core of what hardware-backed trust buys a CRA-ready architecture.
AmbiSEC as the embedded trust layer
This is the role hardware-backed trust with AmbiSEC is built for. AmbiSEC is a dual-domain secure module: the MCU domain runs the application; an isolated cryptographic security domain holds the device identity, signs and verifies, enforces anti-replay, and authenticates every OTA image before it boots. The two domains share a bus, not a memory map. Mapped onto the threat model above, it answers each failure mode at the silicon level:
- Against cloning — a per-device key generated and held inside the secure element, non-extractable and bound to the physical part.
- Against exposed keys — key storage the application firmware cannot read; an MCU compromise does not become a key compromise.
- Against insecure provisioning — identity established at manufacture under protected custody, attested back to an issuance key-ceremony record.
- Against weak firmware identity — secure OTA verification inside the security domain, against a key the MCU cannot rewrite, with anti-rollback counters.
- Against poor lifecycle control — credential rotation against a root that never moves, so devices stay maintainable across the support period.
The AmbiSEC module for embedded security deploys as a solderable MFF2 secure element or a removable nano-card, and runs a JavaCard applet stack — identity, OTA verifier, attestation, rotation. It is the hardware tier a secure-by-design architecture can stand on.
Smart city and IoT use cases
The argument is sharpest where devices live in public space and stay deployed for years.
- Smart-city infrastructure — lighting, traffic, metering, and water nodes sited where physical access cannot be controlled. AmbiSEC for smart city and IoT security keeps each node's identity bound to its silicon, so a tampered cabinet does not yield a usable credential.
- Industrial IoT — sensors and controllers that authenticate to a telemetry back end and may actuate physical processes. A hardware-bound credential prevents a single extracted device from authorising forged commands fleet-wide.
- Connected products and gateways — consumer and prosumer devices that need real device identity rather than a default password or a per-fleet shared key.
For the wider architecture these sit inside, see device identity at scale and the smart cities industry view.
What AmbiSEC does and does not do
To be precise: AmbiSEC supports CRA-aligned secure-by-design and vulnerability-handling expectations and can form part of a manufacturer's CRA technical and security architecture. It does not, on its own, make a product compliant, and it does not replace conformity assessment. Compliance is a function of full-system design, manufacturer process, and the applicable conformity route — the hardware provides primitives the rest of the system is built on, not a certificate. Treat AmbiSEC as the embedded trust layer, and the documented secure-development and vulnerability-handling process as the thing that uses it.
Frequently asked questions
What does secure by design mean under the CRA?
It means cybersecurity is considered from the planning and design phase, the product ships in a secure default configuration, and the attack surface is minimised. For connected hardware it translates into concrete architecture choices — where keys are stored, how device identity is established, and how updates are authenticated — made at design time rather than added before launch.
Why is hardware-backed trust important for connected products?
Software-only key storage does not survive the threat model field-deployed devices face — physical access, firmware extraction, fleet-scale cloning. A hardware root of trust keeps private keys inside a tamper-resistant boundary the application firmware cannot read, so compromising one device does not yield the keys for the whole fleet. That property is what makes secure-by-design and vulnerability-handling expectations achievable.
How can AmbiSEC support CRA readiness?
AmbiSEC provides a hardware root of trust, non-extractable key storage, per-device identity established at manufacture, authenticated secure OTA, anti-rollback, and credential rotation. These support CRA-aligned secure-by-design and vulnerability-handling expectations and help manufacturers prepare evidence for secure-lifecycle obligations. It can form part of a manufacturer’s CRA technical and security architecture; it does not by itself make a product compliant.
Is AmbiSEC a CRA compliance certificate?
No. AmbiSEC is a hardware security module, not a certificate or a compliance guarantee. CRA conformity depends on product category, manufacturer role, market placement, conformity-assessment route, and applicable EU guidance. AmbiSEC supports CRA-aligned security architecture but does not replace legal, conformity, or notified-body assessment.