Cyber Resilience Act Reporting Is Live: What Software Teams Need in Place Now
For years, the EU Cyber Resilience Act felt like a 2027 problem. That changed on September 11, 2026. Cyber Resilience Act reporting obligations now apply, and they come with a 24-hour clock. If your company ships software or connected devices into the EU, your development team is now part of a regulated reporting chain. This holds even if you are based in the US.
Most of the law’s product rules still do not apply until December 11, 2027. The reporting piece is different. It is already in force, and it covers products that are on the market today. Here is what that means for engineering teams and the people who hire for them.
Who Cyber Resilience Act Reporting Applies To
The CRA covers “products with digital elements.” That includes standalone software and hardware with embedded software. It also includes systems built from parts supplied separately to work together. The key test is whether the product connects, directly or indirectly, to another device or network.
According to a September 2026 briefing from the law firm McCann FitzGerald, the Act applies no matter where a company is established. A software vendor in Ohio selling into Germany is in scope.
The definition of “manufacturer” is also broader than many teams expect. Importers and distributors can take on manufacturer duties. That happens if they sell a product under their own name or make a substantial modification to it. Systems integrators who rebrand or heavily customize a vendor platform should check where they stand.
One more detail matters a great deal. Goodwin’s September 2026 alert notes that the reporting duty covers products placed on the EU market before December 11, 2027. Your legacy product line is not exempt. The duty is not retroactive, though. It applies to issues a manufacturer becomes aware of on or after September 11, 2026.
What Has to Be Reported, and How Fast
Two kinds of events trigger a report.
The first is an actively exploited vulnerability. This means there is reliable evidence a malicious actor has exploited the flaw in a real system. A theoretical bug found in code review does not count. A flaw being used in the wild does.
The second is a severe incident. This is an incident that affects, or could affect, the product’s ability to protect sensitive data or functions. It also covers incidents that could let malicious code run on the product.
The timelines are tight:
– Early warning: within 24 hours of becoming aware.
– Full notification: within 72 hours.
– Final report for an exploited vulnerability: within 14 days after a fix or mitigation is available.
– Final report for a severe incident: within one month of the notification.
Reports go to the national CSIRT where the manufacturer has its main EU establishment. They also go to ENISA through its Single Reporting Platform, so one submission reaches both. Manufacturers must also tell affected users without undue delay. Goodwin reports that penalties for reporting failures can reach 15 million euros or 2.5% of worldwide annual turnover, whichever is higher.
Why This Is an Engineering Problem, Not Just a Legal One
Lawyers can draft the policy. They cannot tell you within 24 hours whether a reported exploit affects firmware version 4.2 or only 4.3. That answer lives with your developers.
The 24-hour window starts when the company becomes aware, not when the right engineer gets the ticket. A report sitting in a shared inbox over a weekend still counts against you. Many teams will find their current process cannot move that fast.
The core question is simple. Can you quickly map a vulnerability to the products and versions you ship? If your dependencies are not tracked, you will spend the first day just finding out whether you are affected.
Practical Steps for Development Teams
You do not need to rebuild your security program to meet this deadline. You do need a few things working reliably.
Build an accurate product inventory. List every product with digital elements you sell into the EU, along with supported versions. Note your legal role for each one, since importers can carry manufacturer duties.
Generate SBOMs as part of the build. A software bill of materials lists the components in each release. When a new exploit hits a common library, an SBOM lets you search instead of guess. Goodwin lists SBOM preparation as a core readiness step for the wider 2027 obligations.
Set up an intake path for vulnerability reports. Publish a clear security contact. Route reports to a monitored queue with an on-call owner, including weekends.
Write a reporting runbook. Decide in advance who confirms exploitation. Then name the person who drafts and submits the early warning. Run a tabletop exercise so the first real event is not the first rehearsal.
Define support periods. The CRA expects security updates throughout a product’s support period. Your product and engineering leaders should agree on what that period is for each line.
Review supplier contracts. Much of your exposure sits in third-party components. Make sure suppliers will tell you quickly when their code is exploited.
What This Means for Hiring
These duties create demand for skills that many teams lack. Product security engineers who understand both secure development and incident response are in short supply. So are developers who can automate SBOM generation and dependency tracking in CI pipelines.
Embedded and firmware teams feel this most. Their products often stay in the field for a decade or more. Hiring managers should look for candidates with vulnerability management experience, not only feature delivery. Asking how a candidate would triage a reported exploit is a useful interview question.
Conclusion
Cyber Resilience Act reporting is no longer a future item on the roadmap. It is a live obligation with a 24-hour clock, and it covers products you shipped years ago. The teams that handle it well will know exactly what is in their software. They will also have practiced the response before it counts.
If you are building out product security or embedded development capacity, Converge Resources helps companies find engineers with this experience. You can learn more at
This post is general information and is not legal advice. Check with counsel on how the CRA applies to your products.
