EU software makers face new cyber reporting deadlines

Software manufacturers selling into the European Union must now meet new reporting obligations under Article 14 of the Cyber Resilience Act. The rules apply to products already on the market as well as new ones.

The requirements set a formal timetable for reporting actively exploited vulnerabilities and severe incidents, with potential penalties of up to €15 million or 2.5% of global annual turnover, whichever is higher. Notifications must be submitted through the ENISA Single Reporting Platform, a centralised system intended to cover all EU member states where a product is distributed.

Reporting deadlines

Once a manufacturer becomes aware of a qualifying event, the reporting clock starts immediately. The first step is an early warning within 24 hours of confirming credible evidence of active exploitation or a severe incident.

That initial alert requires basic administrative information, product details and geographic distribution data. Technical root causes, patches and mitigation measures do not need to be included at that stage.

Manufacturers must then update the same case file within 72 hours with available general technical details, risk assessments and any early mitigation steps. The law also requires direct, clear notifications to affected users and, where appropriate, all users, explaining the vulnerability or incident and any practical mitigation advice.

A final report closes the process. For actively exploited vulnerabilities, it is due within 14 days after a patch or corrective workaround becomes available to users. For severe incidents, a final submission is required within one month of the 72-hour notification.

These obligations extend beyond newly launched products. Software and connected products already being sold in the bloc are also within scope, increasing the compliance burden for companies with large installed bases and legacy portfolios.

Broader shift

Lawyers and security specialists say the reporting rules signal a wider shift in how the EU intends to regulate software security. Rather than treating compliance as a post-incident matter, the act ties legal exposure more closely to how vendors design, maintain and document security processes across a product's lifecycle.

"Legally, the Cyber Resilience Act is a paradigm shift. Unlike the GDPR, where security-related fines historically followed post-incident investigations, the CRA mandates a highly proactive, continuous approach to security throughout a product's entire lifecycle, from design to sunsetting. If you have products on the market, the reporting anchor is live from September 11, 2026. A good lawyer can help you navigate, but compliance under the CRA is an ongoing, tangible engineering obligation that cannot be solved by simply writing policies or terms of service," said Lara Brito, Tech Lawyer and Legal Researcher.

Application security practitioners echo that emphasis on process, arguing that manufacturers will need incident response plans, internal escalation paths and product inventories that support rapid decision-making within the legal timetable.

"Compliance has never been a good proxy for real security. CRA is about to fundamentally change that as it sets security in the driver's seat for any software product sold in the EU. Checkbox-driven compliance is unlikely to fly, because what the CRA asks for is a continuous and verifiable application security program behind it. Compliance becomes a side effect of doing security well, instead of a substitute for it," said Dr. Aram Hovsepyan, Application Security Expert and Co-Host of the CRA Sessions podcast.

The 24-hour and 72-hour thresholds are likely to be especially difficult for companies with fragmented security operations or limited visibility across product teams. A manufacturer must first establish that a vulnerability is being actively exploited or that an incident is severe, then gather enough internal information to file on time and notify users.

That challenge becomes more acute for multinational software groups whose engineering, legal and security teams are spread across different jurisdictions. Internal reporting lines, evidence gathering and sign-off procedures may need to be revised so regulatory notifications can be made without waiting for lengthy investigations.

Industry gaps

Some specialists argue that many organisations still fall short of the level of documentation and operational discipline the law assumes. They point to persistent weaknesses in software lifecycle governance, security testing and post-release monitoring.

"Both the OWASP Benchmarks and academic research have pointed to major gaps between the state of the industry today and what is required by CRA. Organisations will have to set up new processes and become much better at documenting process, risk and mitigations. The tight timelines also force us to have an incidence response plan ready and known by the relevant teams. We hope the new regulation will lift all boats, and we will soon see if it does," said Dr. Dag Flachet, Professor and AppSec Leader.

Another view is that the act pushes software assurance beyond the long-running idea of moving security checks earlier in development. The expectation now is that vendors can show a chain of evidence linking scope, risk assessment, control selection, implementation and ongoing detection.

Brian Glas, OWASP Top 10 and OWASP SAMM Leader, described the moment as a starting point for organisations that need verifiable product lifecycle security assurance. That means demonstrating assurance from product scope through risk assessment, security controls, implementation, verification and detective controls, rather than relying on a narrower development-stage approach.

The reporting platform itself remains an operational point to watch, because all notifications are meant to pass through the ENISA Single Reporting Platform. One submission is intended to cover every EU member state where the affected product is distributed, which could reduce duplication once the system is fully available.

For manufacturers, the immediate issue is less the theory of the regulation than the practical readiness it demands. The law assumes companies know what products they have on the market, can identify affected users, can distinguish a reportable event from a non-reportable one and can document what they know at each stage of an unfolding security problem.

Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.