Cyber Resilience Act 2026: IoT and Embedded Compliance Guide

The EU Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847, which imposes horizontal cybersecurity requirements on every Product with Digital Elements (PDE) sold in the European Union. Per the European Commission, the CRA entered into force on December 10, 2024, 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, as noted by ETSI and the harmonised standards working group, 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 company 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
• Where to report: the ENISA Single Reporting Platform
• How to build security in from the design phase
• The SBOM: cornerstone of CRA compliance
• CRA compliance for embedded systems and embedded Linux
• 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 (CRA) is European Regulation EU 2024/2847, published in EUR-Lex, establishing horizontal cybersecurity requirements for every Product with Digital Elements (PDE) placed on the EU market. According to ENISA and per NIST IoT guidance archived on commission.europa.eu, the text was adopted in November 2024 to close gaps in the current regulatory framework and to harmonise obligations across the whole product lifecycle. For an article-by-article walkthrough see the Cyber Resilience Act 2024/2847 guide covering scope, classes and timeline.

The text entered into force on 10 December 2024 and becomes fully binding on 11 December 2027, with a decisive intermediate step on 11 September 2026 for the notification obligations. Penalties reach 15 million euros or 2.5% of worldwide turnover, and the security-support period must cover at least five years. 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. Our CE/RED certification checklist sets out what that technical file has to contain, from the EU declaration of conformity to the post-market obligations the CRA adds on top.

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. Three dates structure the preparation: 10 December 2024 marks the entry into force and opens the preparatory period; 11 September 2026 activates the notification of actively exploited vulnerabilities within 24 hours and of severe incidents within 72 hours; 11 December 2027 makes the full set of requirements applicable, extended CE marking included. The operationally binding date is therefore September 2026, fifteen months earlier than the deadline many manufacturers wrongly plan around.

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. Exemptions are narrow and essentially cover products already governed by an equivalent sector regulation, such as medical devices under the MDR. The question to ask is therefore not "am I concerned?" but "which category does my product fall into?", because the required assessment level depends on it. A manufacturer outside the EU is concerned as soon as its product is placed on the European market: the location of the head office protects nothing.

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

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 24-hour reporting rule is the CRA operational obligation to notify actively exploited vulnerabilities within one day via the single ENISA portal, effective September 11, 2026. As noted by ENISA in its Coordinated Vulnerability Disclosure (CVD) guidelines, it 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. The notification goes through the single European portal operated by ENISA, with an initial notice within 24 hours followed by an intermediate report within 72 hours for severe incidents. Without an internal detection, triage and decision process rehearsed before the deadline, the legal window is mechanically untenable: it is an organisational capability to build, not a form to fill in.

Concretely, the manufacturer must:

• Maintain a public vulnerability intake channel (Coordinated Vulnerability Disclosure, CVD) compliant with ISO/IEC 29147 and ISO/IEC 30111.
• Keep a 24/7 triage capability able to qualify the severity of an incoming Common Vulnerability and Exposures (CVE) report using Common Vulnerability Scoring System (CVSS) v4.0.
• Notify ENISA (European Union Agency for Cybersecurity) 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 such as signed Over-the-Air (OTA) patches validated by a Root of Trust (RoT) anchored in a Hardware Security Module (HSM).

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.

Where to report: the ENISA Single Reporting Platform

The Single Reporting Platform (SRP) is the single European entry point through which every notification required by Article 14 of the CRA passes. A manufacturer files one notification, and the platform routes it to the competent national CSIRT and to ENISA, with no parallel filing in each member state concerned.

That centralisation reduces the administrative load, but it does not move the point at which the clock starts. The statutory window opens when the manufacturer becomes aware of active exploitation, not when the analysis is finished. At AESTECHNO, we recommend creating and exercising the platform account before the deadline, the same way a technical file is prepared in advance: discovering an interface during an incident consumes hours the 24-hour window does not contain.

Your installed base is in scope, unlike the rest of the regulation

This is the point that surprises the manufacturers we work with. Article 69(2) provides that products placed on the market before 11 December 2027 fall under the regulation only if they undergo a substantial modification. Article 69(3) then derogates from that rule for Article 14 alone: the reporting obligations apply to all in-scope products placed on the market before that date. Being grandfathered protects technical compliance, it does not protect reporting.

An industrial sensor shipped in 2023, still installed at a customer site and still within CRA scope, therefore creates a reporting obligation from September 11, 2026 if a vulnerability in it is actively exploited. In our practice this is the category that causes the most trouble: the installed base is rarely inventoried with the rigour applied to products in active development, and responsibility for watching it is almost never assigned by name. Our methodology for securing an IoT product from design through deployment treats that perimeter on the same footing as new work.

A schedule caveat worth planning around

The European Commission states that the platform will be operational by September 11, 2026. It was nonetheless not yet live at the end of June 2026, under three months from the deadline. We therefore advise building the internal process independently of the tool: the obligation runs on the stated date whether or not the interface has settled, and a process that assumes a portal nobody has seen is not a process. Our notes on industrial IoT cybersecurity and the requirements already in force under CE / RED certification for connected devices remain the two fastest ways to frame the work.

How to build security in from the design phase

Security by design is the CRA essential requirement that cybersecurity must shape the product architecture from the specification phase, rather than being bolted on at the end. For a typical Product with Digital Elements (PDE), seven technical pillars have to be addressed. As noted by NIST in SP 800-160 and the NIST Secure Software Development Framework, none of them is optional. The pillars cover STRIDE-style threat modelling, secure boot, TLS 1.3 communications, signed OTA updates with anti-rollback protection, the SBOM software inventory, the coordinated vulnerability disclosure (CVD) policy, and the associated technical documentation. Each one leaves a verifiable trace in the compliance file, which lets progress be assessed as the project advances.

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 (SB) and chain of trust

The chain of trust starts at the first byte executed. A Secure Boot (SB) 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. In our lab we measured a 42 ms Secure Boot validation on an STM32H5 with a 512 KB signed firmware image and a Root of Trust (RoT) provisioned in its on-chip Hardware Security Module (HSM).

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: Transport Layer Security (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

Over-the-Air (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 Common Vulnerability and Exposures (CVE) entry is published, 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 a detailed machine-readable inventory of every software component in a product, third-party libraries, open-source dependencies, proprietary modules and their exact versions. According to the European Commission, the CRA makes it an explicit obligation: without an up-to-date SBOM, a manufacturer cannot prove that it knows what runs inside its product, so it cannot guarantee that it can react to a CVE in one of those dependencies.

Generating the inventory once is not enough: it must be regenerated at every build and continuously checked against known-vulnerability databases, otherwise it becomes a dead document giving a false sense of compliance. Two standard formats dominate the market and are recognised by the European Commission:

• CycloneDX 1.5: 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 2.3: 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. In our lab we measured Syft + Grype generating a full CycloneDX 1.5 SBOM from a 180 MB Yocto rootfs in under 90 seconds on a GitLab runner, scanning 612 packages against the NVD in about 12 seconds. According to ENISA and as noted by Bsi in its TR-03183 guidance, 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 firm 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 firms validates the approach: scanning is necessary but insufficient, pilot-driven remediation is the deliverable that matters for the CRA.

CRA compliance for embedded systems and embedded Linux

Embedded systems sit squarely inside the CRA scope: a connected device built on a microcontroller or on embedded Linux is a Product with Digital Elements like any other, carrying the same SBOM, vulnerability-handling and reporting obligations described above. The difference lies in execution. An embedded Linux image assembled with Yocto or Buildroot aggregates hundreds of packages, kernel, bootloader, C library, userspace daemons, so the software inventory, the CVE monitoring and the update mechanism must operate at distribution scale, which is exactly where the wall of 3,000 CVEs from a single Yocto SBOM described earlier comes from. An MCU-class product running FreeRTOS or Zephyr has a smaller inventory but fewer resources for cryptography and updates. In both cases the compliance levers stay identical: an SBOM generated by the build system, continuous kernel and userspace CVE monitoring, signed OTA updates with rollback, and a security-support window of at least five years.

• Embedded Linux products: SPDX or CycloneDX SBOM generated by the build system, Grype or Trivy scan on every CI build, signed update bundles deployed via RAUC or Mender with rollback, and a kernel LTS branch whose maintenance horizon matches the announced support window. Our embedded Linux distributions comparison details the Yocto / Buildroot / Debian trade-offs behind that choice.
• MCU-class products: SBOM assembled from the locked dependency manifest, MCUboot signed images with anti-rollback protection, a secure element for key storage, and mbed TLS or wolfSSL for TLS 1.3. Our Zephyr / FreeRTOS / embedded Linux comparison shows how the OS choice shapes this list.
• Both classes: a published CVD policy, the 24h/72h notification process, and the threat-model discipline detailed in our industrial IoT cybersecurity guide.

For embedded Linux specifically, the build system is the natural SBOM source: per the Yocto Project documentation, the create-spdx class emits SPDX documents at build time, Buildroot exposes package and licence manifests through make legal-info, and Syft generates CycloneDX from the finished rootfs, the same tool we benchmarked above on a 180 MB Yocto image. Kernel vulnerabilities deserve a dedicated triage rule: since the Linux kernel project became its own CVE Numbering Authority in 2024, kernel CVEs are assigned at a much higher rate, so filtering by the subsystems and drivers your image actually compiles is the only way to keep the remediation pipeline described above workable over a five-year support window.

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. These milestones align compliance with the existing development phases instead of adding a parallel process: each one produces a deliverable that feeds directly into the CRA technical file, from the initial threat model to the notification process dry-run rehearsed before the September 2026 deadline. Compliance is thus observed as the project advances rather than discovered at the end. No milestone is skippable, even on a tight schedule.

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. On a recent project we benchmarked our pipeline against the third-party assessment criteria used by notified bodies such as Bureau Veritas and SGS, and found that a CRA gap analysis typically takes four to six weeks of engineering time for an existing product versus built-in from day one for a new design. 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. They come from support engagements run from our Montpellier lab and are reported without identifying the clients, in line with our confidentiality commitments, because their value is generic: every team preparing for the CRA will meet at least one of these situations. The common thread is that remediation cost grows as the deadline approaches, which argues for an early assessment. Each case below states the symptom, the root cause and the fix we applied.

• 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. According to ENISA and the Network and Information Security (NIS2) directive guidance, alignment with the following normative references is recognised as partial conformity evidence. Here are the references we regularly use at AESTECHNO and recommend evaluating based on project context. The ecosystem splits into three families: the standards that set the requirements, the software-inventory formats recognised by the European Commission (CycloneDX and SPDX), and the analysis tools that automate vulnerability detection in the build chain. Every tooling choice should stay reversible: the regulation will evolve before 2027 and the toolchain must be able to follow, without an irreversible dependency on a single vendor.

Standards and harmonised norms:

• EN 18031-1/-2/-3, harmonised standards being finalised for RED Art. 3.3 (radio cybersecurity) per ETSI, 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 from the IEC.
• IEC 62443-4-2, component-level technical requirements for industrial systems.
• NIST IR 8259/8425, NIST SP 800-213, per NIST, US guides on IoT cybersecurity aligned with CRA philosophy.
• ISO/IEC 27001 / 27034, information security management and application security published by ISO.
• ISO/IEC 29147 / 30111, coordinated vulnerability disclosure and handling, also endorsed by the German federal Bsi in its TR-03183 technical guideline.
• 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. The list condenses the obligations developed in this article: regulatory scoping of the product, security from the design phase, a living software inventory, an operational notification process, and a security-support plan covering at least five years. Every point left unvalidated as the deadline approaches is a direct regulatory risk, with penalties of up to 15 million euros or 2.5% of worldwide turnover. Print it and review it at every project milestone.

• 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
• Industrial IoT cybersecurity, threat model and low-cost defenses for connected industrial products
• Secure IoT product design and deployment, end-to-end security from spec to field
• CE / RED certification for IoT, the EU radio-equipment directive and the cybersecurity articles 3.3(d-f)
• Embedded DevOps CI/CD with automated tests, the pipeline foundation for continuous SBOM and signed firmware
• Embedded power management for 3-year battery life, security and energy budgets are joint constraints
• NB-IoT / LTE-M / satellite connectivity, choosing a connectivity stack with secure update bandwidth in mind
• Contact AESTECHNO, CRA compliance audit, IoT security by design, embedded CI/CD pipeline