Cyber Resilience Act: Are Embedded-Device Manufacturers Ready for September 2026?

Most discussions of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) revolve around 11 December 2027, when the essential cybersecurity requirements and vulnerability-handling obligations become fully applicable. That date matters but it is not the first one.

The reporting obligations under Article 14 apply from 11 September 2026. From that day manufacturers of products with digital elements sold on the EU market must report actively exploited vulnerabilities and severe incidents to the authorities, on fixed timelines measured in hours. This applies to products already on the market, not only to new releases.

If you build embedded Linux devices, industrial controllers, IoT gateways, or connected appliances, September 2026 is the deadline to plan around.

This article is technical guidance, not legal advice. For binding interpretation, consult the regulation text and qualified counsel.

Why September 2026 matters

The CRA entered into force on 10 December 2024. Its provisions phase in:

11 September 2026: Article 14 reporting obligations
11 December 2027: the remaining obligations, including the essential requirements of Annex I and the vulnerability-handling requirements

Two things make the September date operationally hard. The timelines are short: an early warning is due within 24 hours of becoming aware and weekends do not pause the clock. And you cannot report what you cannot detect: awareness depends on vulnerability monitoring, a reachable security contact and a team that knows what to do with an incoming report. Neither can be improvised.

What must be reported and what must not

Article 14 does not require reporting every vulnerability. Two specific event types trigger the obligation:

An actively exploited vulnerability in your product. Under Article 3(42), this means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. A CVE by itself is not reportable. Evidence of exploitation in the field is the trigger.

A severe incident having an impact on the security of the product. Under Article 14(5), an incident is severe where it negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or where it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user.

Concrete embedded examples:

A known vulnerability in a library is being exploited on devices to extract device keys or gain remote access: an actively exploited vulnerability, reportable.
Compromise of your OTA signing infrastructure enabling malicious update delivery: severe incident, reportable.
A CVE against BusyBox with no exploitation evidence, patch scheduled for the next release: not reportable under Article 14. It falls under the vulnerability-handling obligations that apply from December 2027.

This distinction is important. Article 14 is a reporting duty for specific events. The broader obligations to handle vulnerabilities, maintain an SBOM and publish a coordinated vulnerability disclosure policy sit in Article 13 and Annex I Part II, applying from December 2027. Do not confuse the two, but note that meeting the reporting duty in practice pulls much of that machinery forward.

Who is affected

The CRA applies to products with digital elements made available on the EU market: hardware and software products and their remote data processing solutions, with defined exclusions for products under sectoral regimes such as medical devices, aviation and motor vehicles. For embedded manufacturers that covers PLCs, industrial controllers, edge gateways, building automation, connected appliances and software components sold separately such as a commercial BSP or middleware stack.

Critically for reporting: Article 14 obligations from September 2026 also cover products placed on the market before December 2027. Your current portfolio is in scope, not just your roadmap.

The reporting stages and deadlines

Both event types follow a staged process, submitted via the single reporting platform.

Actively exploited vulnerability:

Early warning within 24 hours of becoming aware
Vulnerability notification within 72 hours, with general information, severity and impact and corrective or mitigating measures where available
Final report no later than 14 days after a corrective or mitigating measure is available

Severe incident:

Early warning within 24 hours, indicating whether the incident is suspected to be caused by unlawful or malicious acts
Incident notification within 72 hours, with general information, an initial assessment and applied or ongoing mitigations
Final report within one month after the incident notification

Manufacturers must also inform impacted users of the product about the event and, where necessary, about corrective measures they can deploy.

The engineering consequence: your internal process must produce a defensible initial assessment within 24 hours and a technical assessment within 72. That is an incident-response drill, not a compliance document.

The ENISA Single Reporting Platform

Under Article 16, ENISA establishes and operates a Single Reporting Platform (SRP). Manufacturers report once through the SRP. The notification is addressed to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment and is simultaneously accessible to ENISA. The receiving CSIRT disseminates the notification to CSIRTs in other Member States where the product is available, subject to narrow security-related exceptions.

There is a certain irony worth savouring here. Manufacturers are expected to file structured reports within 24 hours starting 11 September 2026. The platform they must file them through was as of mid-2026 still not operational! The Commission plans for it to be ready by the same 11 September with a testing period beforehand. So the deadline discipline demanded of industry apparently comes with a more relaxed interpretation when applied to the infrastructure industry must use. Plan accordingly: assume the platform arrives at the last minute and do not assume there will be time to rehearse with it.

None of this changes your homework. The internal process that produces the report is your work and does not depend on the platform. Know your coordinating CSIRT now (for a manufacturer with main establishment in Germany, that is BSI’s designated national CSIRT function) and watch ENISA’s SRP page and FAQ for onboarding details.

Why an SBOM alone is not enough

Many teams equate CRA readiness with “we generate an SBOM in CI.” Modern embedded Linux build systems can emit SPDX or CycloneDX documents per image build. That is necessary groundwork, but an SBOM is an inventory, not a process.

An SBOM does not:

tell you which CVEs affect the versions you ship
tell you whether a vulnerability is exploitable in your configuration (a CVE in an unused kernel module compiled out of your defconfig is noise)
detect exploitation in the field
notify your CSIRT
ship a fix to devices

The 24-hour clock starts at awareness and awareness comes from monitoring and intake, not from a document in an artifact store. The SBOM is the data layer under a vulnerability-management and incident-response process, not the deliverable.

Building the process: practical engineering steps

What follows are engineering recommendations, not legal requirements. They describe how a small team can realistically operate the reporting duty.

Product and component inventory. Maintain a machine-readable mapping from shipped firmware versions to their SBOMs. Archive the SBOM of every release build together with the image and tag both against the exact source revision of the build. Without per-release SBOMs, you cannot answer “which fielded devices contain the affected component” inside 24 hours.

Vulnerability monitoring. Run automated CVE matching against your SBOMs, using tools that consume SPDX or CycloneDX and match against NVD, OSV and vendor advisories. Schedule this in CI on a daily basis against released builds, not only on new ones. Route findings into your issue tracker automatically.

CVE triage. Define a written triage procedure: who assesses, against what criteria (exploitability in your configuration, exposure of the interface, CVSS as an input rather than a verdict) and what the escalation path is when exploitation evidence appears. Record triage decisions in the tracker. If an authority asks why an issue was not reported, a documented “not exploitable in our configuration, module not built” is your answer.

Coordinated vulnerability disclosure. Publish a security contact and a security.txt and answer it. External researchers and downstream customers are a primary source of the “reliable evidence of exploitation” that triggers Article 14. A CVD policy is formally an Annex I Part II obligation for 2027, but the intake channel is what makes you aware in time in 2026.

Incident-response procedure. Write a short runbook: detection sources, severity assessment against the Article 14(5) criteria, who drafts the early warning, who approves it, who submits and how users are informed. Then run a tabletop exercise against the 24/72-hour timeline with a realistic scenario, for example “customer reports devices beaconing to an unknown host after exploitation of the web UI.”

Secure OTA updates. The final report for an exploited vulnerability is due 14 days after a corrective measure is available, which presumes you can deliver one. The CRA does not mandate any particular update architecture. What matters practically is a tested, remotely deliverable update path: if your only option is “customer use an USB stick or SD card for updates” your remediation timeline is not credible.

Release traceability. Keep an auditable chain from source revision to build to SBOM to released artifact to fleet deployment record. Without it, you cannot say within 24 hours which fielded devices are affected and the early warning becomes guesswork.

Readiness checklist for small manufacturers

Product list mapped to fielded firmware versions and per-release SBOMs
Automated CVE matching running daily against released SBOMs
Written triage criteria and documented triage decisions
Published, monitored security contact (CVD intake)
Incident-response runbook aligned to the 24h / 72h / final-report stages
Identified coordinating CSIRT and tracking of ENISA SRP onboarding
Procedure for informing impacted users
Tested OTA update path capable of fleet-wide remediation
One simulated incident walkthrough exercise completed before September 2026

Conclusion

September 2026 is not a paperwork deadline. It is the date by which your organisation must be able to detect a reportable event, assess it and file a structured notification within 24 hours. The legal obligation is narrow: actively exploited vulnerabilities and severe incidents only. The engineering work behind it is broad: inventories, monitoring, triage, intake, response and a working secure-update path.

Teams that build this now will find that most of the December 2027 vulnerability-handling obligations are already in place as a by-product. Teams that wait for Brussels to finish its own platform before starting will be reacting under a running clock, with less patience extended to them than the EU extends to itself.

Sources and further reading

Embetrix helps embedded-product teams establish practical vulnerability monitoring, SBOM, secure-update and incident-response processes for CRA readiness.