What Changed on 11 September 2026 Under the Cyber Resilience Act?

Article 14 Became Applicable on 11 September 2026

The September 2026 milestone is the first CRA date that creates a major operational obligation directly for manufacturers. Article 71 states that Article 14 applies from 11 September 2026 even though the Regulation generally applies from December 2027. Article 14 requires manufacturers to notify specified actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements. The obligation is time-sensitive and begins from awareness, so an organisation cannot rely on a quarterly compliance review or slow legal escalation process. Product-security and incident-response teams need to know how a vulnerability or incident moves from technical discovery into a rapid assessment of the CRA reporting trigger. This makes reporting readiness an active 2026 compliance issue rather than only a future 2027 project.

• Article 14 has applied since 11 September 2026.
• The current obligation is directed at manufacturers.
• The reporting clock is linked to awareness.
• Technical and regulatory escalation need to operate together.

The Single Reporting Platform Became Operational

ENISA launched the initial operating capability of the CRA Single Reporting Platform on 11 September 2026. The platform is the electronic mechanism established to support notifications under the CRA. For manufacturers, it provides the route for notifying the relevant CSIRT designated as coordinator and ENISA without having to create separate parallel submissions to each authority. ENISA also publishes operational guidance, user information and frequently asked questions for the platform. Reporting teams should treat that guidance as a living operational layer because platform procedures can evolve while the underlying legal duties remain anchored in the Regulation. Access, account ownership, backup users and internal authorisation should therefore be prepared before an event occurs rather than during the first 24-hour reporting window.

Not Every Vulnerability Must Be Reported

Article 14 does not require manufacturers to submit every discovered software flaw to the CRA platform. The mandatory vulnerability reporting trigger concerns an actively exploited vulnerability contained in a product with digital elements that the manufacturer becomes aware of. That distinction matters for product-security teams that already receive large numbers of vulnerability reports, scanner findings and dependency alerts. The organisation still needs to assess and handle vulnerabilities under its broader security processes, but the Article 14 reporting decision depends on the statutory trigger. A practical workflow should therefore record the affected product and version, evidence relevant to exploitation, when the manufacturer became aware of the facts and who approved the reporting assessment. The goal is rapid and documented classification, not automatic reporting of every technical weakness.

• A vulnerability finding is not automatically an Article 14 report.
• The actively exploited condition is central to the mandatory vulnerability trigger.
• Awareness timing should be recorded.
• Product and version identification should be part of triage.

Severe Product-Security Incidents Are a Separate Trigger

Article 14 separately requires reporting of severe incidents having an impact on the security of a product with digital elements. The Regulation describes severity by reference to effects or potential effects on the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where an incident has led or is capable of leading to malicious code being introduced or executed in the product or a user's network and information systems. This is more specific than an organisation's ordinary internal incident severity label. A company should therefore avoid assuming that its existing P1, critical or major incident category automatically answers the CRA question. Regulatory severity needs to be assessed against the legal criteria.

• Internal incident labels do not replace the CRA definition.
• Product-security impact is central to the severe-incident analysis.
• Potential impact can matter as well as realised impact.
• The Article 14 incident trigger is separate from the vulnerability trigger.

The CRA Uses a 24-Hour and 72-Hour Reporting Sequence

For both reportable actively exploited vulnerabilities and severe incidents, Article 14 uses a staged process. The early warning must be submitted without undue delay and in any event within 24 hours after the manufacturer becomes aware of the reportable event. Unless the relevant information has already been provided, a fuller vulnerability or incident notification follows without undue delay and in any event within 72 hours after awareness. This sequence recognises that complete technical information may not be available during the first day. It also means the manufacturer needs to submit what the Regulation requires at the appropriate stage rather than waiting for a complete root-cause analysis. Internal procedures should make the 24-hour threshold visible from the first escalation and assign clear responsibility for each subsequent submission.

• Early warning: without undue delay and no later than 24 hours after awareness.
• Further notification: without undue delay and no later than 72 hours after awareness.
• Information can be developed through the staged reporting sequence.
• Waiting for a complete investigation can create deadline risk.

The Final Reporting Deadline Depends on the Type of Event

The CRA does not use the same final-report deadline for actively exploited vulnerabilities and severe incidents. For a reportable vulnerability, Article 14 requires the final report no later than 14 days after a corrective or mitigating measure is available, unless the relevant information has already been provided. The report includes information such as the vulnerability's severity and impact and details of the security update or other corrective measure. For a severe incident, the final report is due within one month after submission of the 72-hour incident notification, again unless the relevant information has already been supplied. The different deadlines should be encoded into case management so that vulnerability and incident workflows do not accidentally use one generic CRA final-report timer.

• Vulnerability final report: no later than 14 days after a corrective or mitigating measure is available.
• Severe-incident final report: within one month after the 72-hour incident notification.
• The two final-report clocks are different.
• Case records should identify which Article 14 pathway applies.

What Manufacturers Should Have in Place Now

A manufacturer subject to the CRA reporting regime should have more than access to the ENISA platform. It needs an end-to-end process connecting vulnerability intake, security monitoring, product ownership, incident response, legal analysis and regulatory submission. The process should identify who can make an Article 14 determination, who can submit through the platform, who acts as backup, how awareness time is captured and how corrective measures are tracked through the final report. Product inventories and version information need to be accessible during an event. The organisation should also test the escalation route using realistic scenarios because the first statutory deadline is measured in hours. This operational capability can then feed the wider CRA readiness programme for vulnerability handling, product support and documentation before December 2027.

• Assign an Article 14 decision owner.
• Maintain SRP access and backup users.
• Record awareness times.
• Connect reports to product and version records.
• Track corrective and mitigating measures.
• Test the workflow before a real reportable event.

Open-Source Software Stewards Have a Different Application Date

ENISA's current SRP guidance also distinguishes manufacturers from open-source software stewards. Article 24(3) connects stewards to reporting obligations, but ENISA states that those corresponding obligations apply from 11 December 2027 rather than from the September 2026 manufacturer date. This distinction is important for articles discussing the launch of the Single Reporting Platform because the platform is designed to support both categories even though their statutory application dates are not identical. Businesses should therefore identify their legal role before applying the September 2026 deadline. The fact that a project or organisation interacts with open-source software does not by itself determine whether it is a manufacturer, an open-source software steward or another actor under the CRA.

• Manufacturer Article 14 reporting applies from 11 September 2026.
• The corresponding open-source software steward obligation applies from 11 December 2027.
• Role classification should precede reporting conclusions.
• Using open-source software does not automatically make an organisation an open-source software steward.