The EU Cyber Resilience Act Reporting Duty Started on 11 September 2026: What Manufacturers Now Have to Do in 24 Hours

On 11 September 2026, Article 14 of the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) became directly applicable. It is the first hard compliance milestone of the regulation, and it arrived more than a year before the CRA's general application date of 11 December 2027.

The obligation is narrow but strict. It does not require every manufacturer to report every vulnerability. It requires a manufacturer that has become aware of an actively exploited vulnerability in a product with digital elements, or of a severe incident affecting that product's security, to notify through the European Union Agency for Cybersecurity (ENISA) Single Reporting Platform.

For security teams at hardware and software vendors, this changes the clock. A vulnerability that used to be handled as an internal engineering problem now has an externally enforced deadline attached to it, and the deadline starts when the organisation becomes aware, not when a patch is ready.

What actually triggers the duty

Article 14 distinguishes two reportable situations.

An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it without the system owner's permission. The wording matters. A proof of concept, a theoretical exploit path, or a vulnerability that only appears in a scanner feed does not by itself trigger the obligation. Evidence of real exploitation does.

A severe incident is an event that has or may have a serious impact on the confidentiality, integrity, availability or authenticity of the product. The CRA explicitly includes incidents that introduce or execute malicious code, and it also covers severe incidents in the manufacturer's own environment when those have a direct impact on product security.

Both categories are assessed from the moment the manufacturer knows. There is no grace period for products already on the market. Under Article 69(3), the reporting duty applies to products placed on the EU market before the CRA's full application date as well, provided they are still in circulation.

The three-stage timeline

The CRA sets a graduated reporting schedule rather than a single deadline.

• Within 24 hours of awareness: submit an early warning to ENISA through the Single Reporting Platform. This is a short notification, not a full technical write-up. Its purpose is to give authorities and CSIRTs a head start.
• Within 72 hours of awareness: submit a fuller notification covering the nature of the vulnerability or incident, the affected products and versions, the assessed impact, and any mitigation or remediation already applied or planned.
• After remediation: submit a final report. For vulnerability-related notifications, the CRA ties this to the availability of a corrective or mitigating measure, with a further window measured from that point. For incident notifications, the final report follows the 72-hour notification on a longer schedule.

Manufacturers must also inform affected users about the risk and about any mitigation measures, which is a separate duty from notifying the authority.

Who is in scope

The CRA is a horizontal regulation covering products with digital elements placed on the EU market. That includes hardware with embedded software, standalone software, IoT devices and components that are integrated into larger systems. The responsible party is the manufacturer, and non-EU manufacturers are covered as well; they generally need an authorised representative in the Union.

This is the point that catches exporters off guard. A company outside Europe that ships a connected device into the EU market is a manufacturer for CRA purposes. The reporting duty does not stop at the EU border.

Penalties for non-compliance can reach 15 million euros or 2.5 percent of total worldwide annual turnover from the preceding financial year, whichever is higher.

What the 24-hour clock means operationally

A 24-hour early warning is difficult to meet if the organisation has no defined path from detection to notification. The practical work is mostly preparation:

1. Know what you shipped. A manufacturer cannot assess whether a vulnerability affects its product without an accurate inventory of products, versions and supported maintenance windows. The CRA also expects security updates to remain available for a defined support period, so version tracking has to survive past the release.
2. Define the awareness point. The clock starts when the organisation knows. Decide in advance which function — product security, incident response, legal — is authorised to declare that awareness has occurred, and record the timestamp.
3. Pre-build the notification content. The 24-hour warning is short, but it still needs product identification, a description of the issue, and initial impact assessment. Having a template and a named submitter removes delay.
4. Separate the vulnerability decision from the patch decision. The reporting duty is triggered by exploitation evidence, not by patch availability. Teams that wait for a fix before notifying will miss the deadline.
5. Coordinate the user notification. Telling affected users is a separate obligation with its own timing, and it usually needs legal and communications review. Start that review in parallel with the authority notification, not after it.

Why this is more than a compliance exercise

The CRA reporting duty formalises something defenders have argued for years: the speed of disclosure should be driven by exploitation, not by the vendor's release calendar. When a vulnerability is being exploited, the organisations running the affected product need to know early enough to compensate, even if no patch exists yet.

The regulation also pushes manufacturers toward the practices that make fast reporting possible. You cannot report accurately within 24 hours without an SBOM-like understanding of what is in your product, a maintained support period, and a vulnerability handling process that produces decisions rather than meetings.

For defenders on the buying side, the practical implication is a new question for vendors: not only whether they will patch, but how quickly they will tell you that exploitation has begun. From 11 September 2026, for products in the EU market, that answer has a legal deadline behind it.

References

• Regulation (EU) 2024/2847 (Cyber Resilience Act), in particular Article 14 and Article 69(3).
• ENISA Single Reporting Platform information for CRA reporting.
• Public analyses of the 11 September 2026 applicability date published by EU-focused law firms and compliance bodies.