EU Cyber Resilience Act: What It Means for Connected Hardware and IoT Manufacturers
The EU Cyber Resilience Act (CRA) turns “ship it and patch later” into a regulated discipline for anything with a plug, a radio, or a network stack. For manufacturers of connected devices, embedded systems, IoT modules, and smart-city hardware, it makes cybersecurity a product requirement across the whole lifecycle — not a feature you add before launch. This is a practical, product-security read on what the CRA asks for and why the hardware foundations need to be designed early.
What the CRA actually is
According to the European Commission, the EU Cyber Resilience Act sets mandatory cybersecurity requirements for products with digital elements placed on the EU market. The EU describes it as a horizontal rule: where earlier measures touched specific sectors, the CRA applies broadly — if a product has digital elements and connects, it is in scope unless explicitly carved out. Public CRA guidance places the obligations on manufacturers across the entire product life — planning, design, development, production, delivery, maintenance, and vulnerability handling.
The framing that matters for engineering teams is simple: cybersecurity stops being a launch checklist item and becomes a property the product has to carry for its whole supported life, backed by documentation an auditor can read.
“Products with digital elements” — what is in scope
The CRA defines its scope around products with digital elements: hardware and software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That phrasing is deliberately broad, and for hardware makers it captures most of what you ship:
- Connected devices — anything that authenticates, reports telemetry, or receives updates over a network.
- Embedded systems and IoT modules — sensors, controllers, gateways, metering endpoints, building-automation nodes.
- Smart-city infrastructure — lighting, traffic, transit, water and grid equipment sited in public space.
- Security and identity hardware — authenticators, secure modules, and the credentials that ride on them.
The precise classification — default category, important, or critical — and the conformity-assessment route depend on the product and how it is used. That classification is a job for the official text and EU guidance, not a blog. What is safe to assume early is that connected hardware is in scope and should be designed accordingly.
Security by design and by default
Public CRA guidance describes products as expected to be secure by design and by default. In practice that means cybersecurity is considered from the planning and design phase, that products ship in a secure default configuration, and that the attack surface is minimised rather than left open for convenience. For connected hardware specifically, a few foundational questions decide whether the rest of the requirements are reachable:
- Where do the cryptographic keys live? Keys in general-purpose flash are extractable; keys in a tamper-resistant boundary are not.
- How is device identity established? A per-device key established at manufacture is defensible; a shared secret or default password is not.
- How are updates authenticated? An update path that the device itself can verify against a key it cannot rewrite is the difference between a fix and a new attack vector.
These are architecture decisions. They are cheap at design time and expensive — sometimes impossible — to retrofit once a fleet is deployed. A hardware-backed trust layer such as the AmbiSEC secure module exists to answer exactly these questions at the silicon level, so the secure-by-design expectation has somewhere concrete to stand. We go deeper into that in secure by design under the CRA.
Lifecycle maintenance, support periods, and vulnerability handling
The CRA's most operationally significant idea is that a product's security obligations do not end at sale. Manufacturers are expected to:
- Handle vulnerabilities throughout the expected product lifecycle / support period — identify, address, and remediate them, and distribute security updates.
- Define and communicate the support period — how long the product will receive security maintenance, stated clearly to the user.
- Operate a coordinated vulnerability-handling process — including reporting obligations for actively exploited vulnerabilities and severe incidents.
For hardware, this is where the design-time choices pay off. Shipping a security fix to a fielded device requires an update channel the device can trust; rotating a compromised credential requires a key hierarchy that allows rotation without bricking the device. A secure element that supports authenticated updates, anti-rollback, and credential rotation gives the vulnerability-handling process a mechanism to act through. The detail of those obligations — timelines, support-period communication, evidence — is the subject of CRA vulnerability handling and product lifecycle security.
The dates that matter: 2026 and 2027
Two dates anchor the planning calendar:
- 11 September 2026 — the reporting obligations for actively exploited vulnerabilities and severe security incidents start to apply.
- 11 December 2027 — the main body of manufacturer obligations applies.
The gap between them is not slack. The reporting machinery has to exist before September 2026, and the secure-development, documentation, and conformity work behind the main obligations takes the lead time up to December 2027 to do properly. Hardware programmes in particular — where silicon selection, provisioning lines, and certification all have long lead times — need to be making architecture decisions now to be ready then.
Documentation, conformity, and CE marking
The CRA expects manufacturers to produce technical documentation, carry out a conformity assessment appropriate to the product class, draw up an EU Declaration of Conformity, and apply CE marking where applicable. The practical consequence for engineering is that security claims need evidence behind them: how identity is established, how keys are protected, how updates are verified, how vulnerabilities are handled. Architectures that can produce that evidence — an attestation chain, a documented key ceremony, a verifiable update mechanism — make the documentation burden tractable instead of retrospective.
Why hardware security needs to be designed early
The recurring theme is lead time. Software controls can be revised in a release; hardware trust anchors cannot. If a fleet ships with keys in extractable flash, no shared firmware update fixes the architecture — the keys are already exposed to anyone who can read the chip. If devices ship with a shared secret, no policy change un-shares it. The decisions that make the rest of CRA readiness achievable — where keys live, how identity is rooted, how updates are trusted — are made at design time or not at all.
This is why a hardware-backed trust layer is worth selecting before the architecture sets. AmbiSEC for smart city and IoT security provides a hardware root of trust, non-extractable key storage, per-device identity, and authenticated secure OTA — the primitives a CRA-aligned secure-by-design architecture is built on. AmbiSEC supports CRA readiness; it does not by itself make a product compliant, and it does not replace conformity assessment.
Where to start
If you build connected products for the EU market, the productive first move is an architecture review against the secure-by-design and vulnerability-handling expectations — before the silicon and provisioning decisions are locked. Explore how AmbiSecure helps manufacturers build hardware-backed security into connected products, starting with the AmbiSEC module for embedded security, and read the rest of this series to go deeper on architecture, lifecycle, and product mapping.
Frequently asked questions
What is the EU Cyber Resilience Act?
The CRA is an EU regulation that sets mandatory cybersecurity requirements for products with digital elements — hardware and software that connect directly or indirectly to a device or network. It obliges manufacturers to address cybersecurity across planning, design, development, production, delivery, maintenance, and vulnerability handling, and to provide technical documentation, conformity assessment, an EU Declaration of Conformity, and CE marking where applicable.
Does the CRA apply to connected hardware?
Yes. The CRA covers products with digital elements, which expressly includes hardware with a direct or indirect data connection to a device or network — connected devices, embedded systems, IoT modules, and smart-city equipment fall within scope. The exact obligations and conformity-assessment route depend on the product category and the manufacturer’s role.
When do CRA obligations apply?
The reporting obligations for actively exploited vulnerabilities and severe security incidents apply from 11 September 2026. The main set of manufacturer obligations applies from 11 December 2027. Manufacturers generally use the time in between to build secure-development, vulnerability-handling, and documentation processes.
Why does secure-by-design matter for IoT manufacturers?
Because the CRA expects security to be built in from planning and design, not added before shipping. For connected hardware, foundational choices — where keys live, how device identity is established, how updates are authenticated — are hard to change after deployment. Designing a hardware-backed trust layer early makes secure-by-design and vulnerability-handling expectations far easier to meet.