Cyber Resilience Act 2026: IoT and Embedded Compliance Guide

The EU Cyber Resilience Act (CRA) is the European regulation that imposes cybersecurity requirements on every product with digital elements sold in the EU. It entered into force on December 10, 2024, and becomes fully binding on December 11, 2027 — but the 24-hour vulnerability reporting obligation kicks in earlier, on September 11, 2026.

For manufacturers of industrial equipment, IoT devices, medical peripherals and consumer electronics, this regulation changes the rules of the game. Where the RED directive already covered radio security, the CRA extends obligations to every connectable hardware and software product, with a mandatory minimum support horizon of five years, a Software Bill of Materials (SBOM) to provide, a vulnerability disclosure policy to publish, and financial penalties reaching EUR 15 million or 2.5% of worldwide annual turnover.

At AESTECHNO, an electronic design house based in Montpellier, France, we started integrating CRA requirements into our projects from the design phase. This field guide details the obligations, the real timeline to hit, and the technical choices that secure compliance — not as an end-of-project formality, but as an engineering discipline aligned with our signature: product design IS production design, compliant from the first iteration.

Contents

This article covers, in order, the fundamentals of the CRA, its rollout schedule, its legal scope, the technical security requirements, the SBOM, our AESTECHNO methodology, concrete cases, and an actionable checklist. Use the links below to jump to a section.

• What is the Cyber Resilience Act (CRA)?
• What CRA compliance timeline should you follow?
• Who does the CRA apply to?
• Why the 24-hour reporting rule is not a formality
• How to build security in from the design phase
• The SBOM: cornerstone of CRA compliance
• Our AESTECHNO methodology for CRA readiness
• Real cases from the lab
• Tools, standards and compliance toolchain
• Summary: the CRA checklist
• FAQ: Cyber Resilience Act

What is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act is a European regulation — Regulation (EU) 2024/2847 — establishing horizontal cybersecurity requirements for all products with digital elements (PDEs) placed on the EU market. Adopted in November 2024, it aims to close the gaps in the current regulatory framework and to harmonise obligations across the whole product lifecycle.

In practice, the CRA covers four dimensions:

• Secure-by-design development: the product must be designed, developed and manufactured to ensure an appropriate level of cybersecurity, with essential requirements embedded from the design phase.
• Vulnerability handling: the manufacturer must identify, address and notify vulnerabilities throughout the product’s support period, set by default at a five-year minimum.
• Transparency: an SBOM must be available, a vulnerability disclosure policy must be published, and technical documentation must be maintained.
• Formal conformity: CE marking extended to the cybersecurity dimension, EU declaration of conformity, third-party assessment for products classified as Important.

Penalties for non-compliance reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. For manufacturers of industrial and IoT equipment already covered by RED, EMC or LVD, the CRA adds to rather than replaces those requirements — so it must be layered into the existing CE technical file.

What CRA compliance timeline should you follow?

Unlike many European directives that allow a gradual transition period, the CRA follows a tight schedule. Manufacturers have roughly three years between entry into force and full application, but the first binding deadline lands well before that end date: it is the reporting obligation, which becomes active in September 2026.

Date	Milestone	Manufacturer obligation
December 10, 2024	Regulation enters into force	Preparatory period — adapt internal processes
June 11, 2026	Designation of notified bodies	Prepare assessment file for Important Class I/II products
September 11, 2026	Reporting obligations active	Notify exploited vulnerabilities within 24h and major incidents within 72h via the single ENISA portal
December 11, 2027	Full application	All CRA obligations enforceable — extended CE marking, SBOM, 5+ year vulnerability handling

September 11, 2026 is the date you absolutely need to remember. Many manufacturers assume they have until December 2027 to get compliant. That is wrong: the obligation to notify actively exploited vulnerabilities within 24 hours and major incidents within 72 hours kicks in fifteen months earlier. Without an internal detection, triage and notification process already in place by that date, the organisation is mechanically non-compliant from the first public vulnerability.

Who does the CRA apply to?

The regulation targets every product with digital elements placed on the EU market, whether hardware, software, or associated digital services. The scope is deliberately broad to prevent workarounds, and most IoT products, connected industrial equipment, medical devices not covered by the MDR, consumer electronics and professional software are in scope.

The CRA distinguishes four categories based on criticality, which determines the applicable conformity assessment procedure:

Category	Examples	Assessment
Default (~90% of products)	Consumer IoT sensors, connected toys, USB peripherals, non-sensitive mobile applications	Manufacturer self-assessment
Important Class I	Browsers, password managers, antivirus, home automation with security functions, generic industrial controllers	Harmonised standards or third-party assessment
Important Class II	Enterprise firewalls, microcontrollers for critical infrastructure, hypervisors, IDS/IPS systems	Mandatory third-party assessment (notified body)
Critical	Hardware Security Modules, smart cards, smart meters	European Cybersecurity Certification Scheme (EUCC)

A few exemptions exist: products already covered by the MDR (medical), civil aviation (Regulation 2018/1139), motor vehicles (Regulation 2019/2144) and military equipment. For manufacturers straddling multiple regulations, the arbitration is delicate — a medical IoT device may fall outside CRA scope but back in for its companion mobile app.

Why the 24-hour reporting rule is not a formality

The obligation to notify actively exploited vulnerabilities within 24 hours, effective September 11, 2026, is arguably the most operationally demanding provision in the CRA. It requires three capabilities from the manufacturer that cannot be improvised: detecting active exploitation, quickly qualifying the scope, and triggering the notification within the legal window.

Concretely, the manufacturer must:

• Maintain a public vulnerability intake channel (CVD — Coordinated Vulnerability Disclosure policy) compliant with ISO/IEC 29147 and ISO/IEC 30111.
• Keep a 24/7 triage capability able to qualify the severity of an incoming report.
• Notify ENISA and the national CSIRT via the single European portal, with an initial notice within 24 hours and an interim report within 72 hours.
• Notify affected users without undue delay, with mitigation measures.

Contrary to the belief that a dedicated security team is reserved for large enterprises, our experience at AESTECHNO shows that an SME can hold the 24-hour commitment as long as the right artefacts are prepared in advance: a dedicated inbox monitored outside business hours, a triage playbook with documented severity criteria, and an escalation channel to the technical decision-maker. What takes time is not the notification itself — it is decision-making in the middle of the night with partial information. Preparing the process means pre-deciding in calm conditions what will have to be decided under pressure.

How to build security in from the design phase

The CRA makes security by design an essential requirement: security can no longer be a layer added at the end of a project, it must shape the product’s architecture from the specification phase. For a typical product with digital elements, seven technical pillars have to be addressed. None of them is optional.

1. Structured threat modeling

Threat analysis — using established methods like STRIDE, PASTA or OCTAVE — must be documented from the scoping phase. It identifies the assets to protect, the likely attackers, the attack vectors, and the associated countermeasures. Without this step, the security architecture rests on implicit assumptions — exactly what the CRA refuses.

2. Secure boot and chain of trust

The chain of trust starts at the first byte executed. A secure boot cryptographically verifies the bootloader signature, which verifies the firmware image signature, which verifies the application component signatures. Modern SoCs (NXP i.MX, ST STM32H/U5, Nordic nRF54, Renesas RA) integrate these mechanisms natively, but configuring them correctly is engineering work — not a checkbox.

3. Cryptographic storage of secrets

Signing keys, certificates and credentials must never be stored in clear in flash. Dedicated secure elements (Microchip ATECC608B, NXP SE050, Infineon OPTIGA Trust M, ST STSAFE-A110) or ARM TrustZone hardware enclaves provide this storage. The cost of a secure element is a few cents — negligible compared to the risk of key extraction.

4. Encrypted communications

All network communications must use modern encrypted protocols: TLS 1.3 minimum for HTTP/MQTT, DTLS for CoAP, or end-to-end application-layer encryption for architectures without a trusted intermediary. The mbed TLS, wolfSSL and BearSSL libraries cover embedded constraints.

5. Signed update mechanism

OTA updates must be digitally signed, verified before installation, and rollback-capable in case of failure. Without this capability, a product cannot be patched when a vulnerability is found — which makes the CRA mechanically unworkable. MCUboot (FreeRTOS) and Mender (Linux) have become de facto standards.

6. Published disclosure policy

A public web page, reachable via a stable URL like https://yourcompany.com/security or via a security.txt file at the domain root (RFC 9116), must describe the reporting channel, the scope covered, the handling timelines and the coordinated disclosure policy. Without this mechanism, security researchers cannot notify you — and the CRA holds you responsible for that absence.

7. Documented end-of-support

The support period — minimum 5 years under the regulation, longer for products with longer expected lifespans — must be announced at purchase and honoured. End-of-support itself triggers obligations: user notification, final documentation of residual vulnerabilities, migration recommendations.

The SBOM: cornerstone of CRA compliance

The Software Bill of Materials (SBOM) is the detailed inventory of every software component in a product — third-party libraries, open-source dependencies, proprietary modules, exact versions. The CRA makes it an explicit obligation: without an up-to-date SBOM, you cannot prove that you know what runs inside your product, so you cannot guarantee that you can react to a vulnerability in one of those dependencies.

Two standard formats dominate the market and are recognised by the European Commission:

• CycloneDX: format developed by OWASP, JSON or XML, optimised for security. Rich in metadata (licences, hashes, suppliers, transitive dependencies). Our preferred format for industrial projects because of its readability by CVE monitoring tools.
• SPDX: Linux Foundation format, ISO/IEC 5962:2021 standard, more focused on licences and legal compliance. Often required by large buyers and the US administration.

Generating an SBOM once is not enough. The CRA requires the SBOM to be kept up to date throughout the lifecycle. This requires integration into the CI/CD pipeline: on every firmware build, the SBOM is regenerated, diffed against the previous one, cross-referenced with CVE/NVD databases, and archived. Tools such as Syft (Anchore), cdxgen, SPDX SBOM Generator or integrated solutions like Black Duck and FOSSA automate this work.

On our client projects, we have observed that the difficulty is not generating the initial SBOM — it is keeping it alive over 5 to 10 years. An obscure transitive dependency can become critical three years after market launch. Without CI/CD automation coupled with daily CVE monitoring, the security debt accumulates silently until it explodes at the worst moment.

From scan to remediation: the real challenge

Finding CVEs is the easy part. On a complex embedded project, a Grype or Trivy scan can surface more than 3,000 vulnerabilities from a single Yocto SBOM — a raw wall of data that no team can process without prioritisation. The engineering challenge therefore shifts from scanning to remediation piloting: triaging by operational context (attack vector, required privileges, exploitation complexity), tracking correction states (To Do, In Progress, Fixed, Whitelisted), documenting non-remediation justifications, and producing decision-grade reports for technical and quality boards.

On this exact point, we share the view of Thierry Durand at Embedded Expertise, a design house specialised in embedded Linux, Yocto, and product-level cybersecurity, who emphasises that the real value lies in the ability to drive effective correction, not in collecting the initial finding. CRA is a regulatory framework; actual product security plays out in the architecture and in the remediation discipline maintained across the entire support period. This convergence of views between independent French embedded-cybersecurity design houses validates the approach: scanning is necessary but insufficient — pilot-driven remediation is the deliverable that matters for the CRA.

Our AESTECHNO methodology for CRA readiness

Our approach to the CRA follows our signature: product design IS production design, with compliance embedded from the first iteration rather than bolted on at the end. Specifically for the CRA, we structure our projects around a five-milestone checklist we apply to every new product destined for the European market.

1. CRA scoping in the specification — From the specification phase, we identify the likely product category (Default, Important Class I/II, Critical), the applicable essential requirements and the assessment constraints. This step directly impacts hardware architecture choices (presence of a secure element, signed-boot capability, memory resources for TLS 1.3).
2. Documented threat model — Before PCB routing, we produce a STRIDE document listing assets, attackers, vectors and countermeasures. This document becomes an annex of the CE technical file.
3. Security-by-design architecture — Selection of the secure element (ATECC608B, SE050, OPTIGA), secure boot configuration (MCUboot, U-Boot signed images, proprietary ROM bootloaders), crypto framework choice (mbed TLS, wolfSSL), OTA update strategy (Mender, SUOTA, custom signed FOTA).
4. CI/CD pipeline with continuous SBOM — Our embedded CI/CD pipeline integrates automatic SBOM generation (CycloneDX), CVE vulnerability scanning, firmware signing, and auto-deployment gated on test results. Every artefact is traceable and reproducible.
5. 24h/72h operational readiness — Setting up the public CVD policy, the security.txt, the intake channel, the triage playbook and the escalation chain. Without these artefacts, the September 2026 obligation is not tenable.

This discipline is not specific to our clients; we apply it to our own internal tools. In our lab, we use the same CI/CD pipelines, the same secure elements, and the same disclosure processes as those we set up for clients. The field feedback that comes out of it directly feeds the quality of what we deliver.

Real cases from the lab

Here are three concrete examples of problems we encountered while supporting clients on their CRA preparation. These cases show that the regulation’s obligations often expose technical debt that remained invisible as long as no regulation was forcing it to the surface.

• Case 1: IoT product with no secure boot, six months before market launch. A client came to us with a product based on a standard STM32, unsigned firmware, OTA over plain HTTP. Contrary to the assumption that CRA compliance could be added by firmware update, requalification required an MCU variant change (switch to an STM32 with signed ROM bootloader), a partial PCB redesign to integrate an ATECC608B, and a complete overhaul of the OTA protocol. Cost of a late fix: six months of delay and a PCB respin. We systematically recommend asking “what is the secure boot?” at MCU selection time, not after.
• Case 2: SBOM impossible to reconstruct retroactively. On a product that had been in production for three years, the client had to provide a CycloneDX SBOM to respond to a tender that included anticipated CRA clauses. Contrary to the idea that a binary scan is enough, reconstructing an accurate SBOM requires the original build environment — exact GCC toolchain, third-party library versions, compilation options. Without an archived reproducible CI/CD pipeline, the reconstruction takes weeks and remains partial. Rather than suffer this debt, we recommend integrating SBOM from the first iteration.
• Case 3: missing disclosure policy, unreported public vulnerability. A security researcher had identified a critical flaw in a client’s product, found no reporting channel, and published on Twitter after 90 days with no response. The client was never notified — they discovered the vulnerability through customer service three days later. Without a public CVD policy compliant with RFC 9116, the manufacturer is not only non-compliant with the CRA: they expose themselves to uncoordinated public disclosure, which maximises the exploitation risk. We systematically install security.txt and the /security page at product site go-live.

Tools, standards and compliance toolchain

CRA compliance relies on an ecosystem of tools and standards that evolves quickly. Here are the references we regularly use at AESTECHNO and recommend evaluating based on project context.

Standards and harmonised norms:

• EN 18031-1/-2/-3 — harmonised standards being finalised for RED Art. 3.3 (radio cybersecurity), often cited as a conformity basis for the CRA pending specific CRA-harmonised standards.
• ETSI EN 303 645 — consumer IoT cybersecurity standard, a solid base for most Default-class products.
• IEC 62443-4-1 — secure development lifecycle process requirements.
• IEC 62443-4-2 — component-level technical requirements for industrial systems.
• NIST IR 8259, NIST SP 800-213 — US guides on IoT cybersecurity, aligned with CRA philosophy.
• ISO/IEC 27001 / 27034 — information security management and application security.
• ISO/IEC 29147 / 30111 — coordinated vulnerability disclosure and handling.
• RFC 9116 — security.txt format for publishing reporting channels.

SBOM generation and monitoring tools:

• Syft (Anchore) — CycloneDX/SPDX SBOM generation from build artefacts, native CI integration.
• cdxgen — multi-language CycloneDX generator, useful for polyglot projects.
• Grype (Anchore) — CVE scanner paired with Syft, ideal in CI/CD.
• Trivy — multi-target vulnerability scanner, supports containers and firmware binaries.
• FOSSA, Black Duck, Snyk — commercial solutions with governance dashboards, recommended for organisations with high product volumes.

Static analysis and code quality tools:

• Coverity (Synopsys), Polyspace (MathWorks), CodeSonar (GrammaTech) — advanced static analysis, qualifiable for safety/security standards.
• cppcheck, clang-tidy, scan-build — open-source alternatives integrable in CI with no licensing cost.
• OWASP IoT Top 10 — reference list of the ten most frequent IoT vulnerabilities, a basis for a security checklist.

Security hardware components:

• Secure elements: Microchip ATECC608B, NXP SE050, Infineon OPTIGA Trust M, ST STSAFE-A110.
• Hardware enclaves: ARM TrustZone (Cortex-M33/M55, Cortex-A), Intel TDX, AMD SEV-SNP.
• HSMs: Yubico HSM 2, Thales Luna, Utimaco SecurityServer for production firmware signing.

Rather than rebuild a custom stack, we recommend aligning the tool choice with the standards already in place in the organisation — a client already using GitLab CI has every interest in integrating Syft and Trivy into the pipeline rather than switching to an entirely new commercial suite.

Summary: the CRA checklist

The Cyber Resilience Act is not an administrative formality to settle at the end of a project — it is an engineering discipline that shapes product architecture and organisational processes. For a manufacturer starting the preparation, here are the ten actionable points to validate before September 2026.

• Categorise the product (Default / Important Class I/II / Critical) to identify the applicable assessment procedure.
• Document the threat model using STRIDE or equivalent, with assets, attackers and countermeasures.
• Architect secure boot and the chain of trust at MCU/SoC selection time, not afterwards.
• Integrate a secure element (ATECC608B, SE050, OPTIGA) or a hardware enclave for secret storage.
• Implement TLS 1.3 / DTLS or end-to-end application-layer encryption for all network communications.
• Set up a signed OTA mechanism with rollback (MCUboot, Mender, custom signed FOTA).
• Generate a CycloneDX or SPDX SBOM automatically on every build via the CI/CD pipeline.
• Publish the CVD policy (/security page + security.txt RFC 9116).
• Prepare the 24h/72h notification process with a triage playbook and an escalation chain.
• Announce the support duration (5 years minimum) at purchase and plan the patching roadmap.

For manufacturers discovering the regulation now, the timeline is still tractable but tight — plan three to six months to put the basic artefacts in place (CVD policy, SBOM, 24h process) and nine to eighteen months to re-architect an existing product. The window is closing. Starting now means giving yourself the time to do it properly; waiting until September 2026 means having to react under pressure.

FAQ: Cyber Resilience Act

What is the Cyber Resilience Act in one sentence?
The CRA is a European regulation (EU 2024/2847) that imposes cybersecurity requirements on every product with digital elements sold in the EU, with extended CE marking, mandatory SBOM, vulnerability handling over a minimum of 5 years, and 24-hour incident reporting from September 2026.

What are the key deadlines to remember?
Three dates structure the timeline: December 10, 2024 (entry into force, preparatory period), September 11, 2026 (reporting obligations active — exploited vulnerabilities within 24h, major incidents within 72h), December 11, 2027 (full application, extended CE marking mandatory). The operationally binding date is September 2026.

How do I know if my product is in scope?
Almost every product with connectable software or hardware components is in scope: IoT equipment, connected sensors, industrial equipment, companion mobile apps, professional software. The main exceptions are products already covered by other sector-specific regulations (MDR for medical, civil aviation, automotive, military). When in doubt, consult Annexes III and IV of the regulation and a notified body assessment.

What are the financial penalties for non-compliance?
Penalties reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. For breaches of reporting and cooperation obligations, penalties can reach EUR 5 million or 1% of turnover. National market surveillance authorities (in France, ANSSI and DGCCRF) enforce these sanctions.

Does the CRA apply to products already on the market?
Products placed on the market before December 11, 2027 are not subject to the CRA, unless they undergo a substantial modification after that date. But beware: a significant firmware update, a hardware change, a new variant can constitute a substantial modification that requalifies the product as newly placed on the market — and therefore fully subject to the CRA. Commercial continuity of an existing catalogue requires a clear change-management strategy.

How can AESTECHNO help with CRA readiness?
We integrate CRA requirements from the technical scoping of new projects: threat model, security-by-design architecture, selection of security components (secure element, MCU with secure boot), CI/CD pipeline with continuous SBOM, coordinated vulnerability disclosure rollout. For existing products, we offer a gap-analysis audit identifying the gaps vs the CRA and a costed, prioritised remediation plan. Our approach follows our signature: product design is compliant from the first iteration, not adapted at the end of the cycle.

Related

• Cyber Resilience Act — French version — the original article, more context for French-speaking readers
• Contact AESTECHNO — CRA compliance audit, IoT security by design, embedded CI/CD pipeline