CRA reporting obligations from 11 September 2026: triggers, deadlines and reporting channels

What has applied since 11 September 2026?

The reporting obligation under the Cyber Resilience Act has applied since 11 September 2026. Article 14 requires manufacturers of products with digital elements to report actively exploited vulnerabilities and serious security incidents to the authorities. The remaining product, documentation and conformity obligations do not apply until 11 December 2027.

The Cyber Resilience Act is product law. NIS2 and DORA place obligations on the company as a whole; the CRA applies to the individual product, across its entire lifecycle from development to the end of the support period.

The Regulation phases in its obligations over five key dates:

• 10 December 2024: the Regulation enters into force; the implementation phase begins.
• 11 June 2026: Chapter IV becomes applicable; notified bodies may carry out conformity assessments.
• 11 September 2026: the manufacturers’ reporting obligations under Article 14 apply.
• 11 December 2027: full application with product, process, documentation and conformity obligations.
• 11 June 2028: certificate transition.

The treatment of legacy products is important in practice. Products placed on the market before 11 December 2027 are generally subject to the full requirements only in the event of a substantial modification. However, Article 14 already applies now to relevant legacy products within the scope of application. Anyone looking only at new developments underestimates their own reporting scope.

The reporting obligation is therefore the first CRA requirement to arrive in day-to-day operations, and it affects a significantly larger product portfolio than many manufacturers expect.

Which events trigger the CRA reporting obligation?

The CRA reporting obligation has exactly two triggers: an actively exploited vulnerability in a product with digital elements and a serious security incident affecting product security. If neither is present, no obligation arises under Article 14.

A high CVSS score, a published proof of concept or a known but not actively exploited CVE are not sufficient on their own. This distinction is where most processes fail. Without predefined criteria, gut feeling determines in an incident whether a report is submitted.

Even where there is no reporting obligation, remediation and documentation remain mandatory. A finding that does not trigger Article 14 therefore does not disappear from vulnerability management.

When is a vulnerability considered actively exploited?

A vulnerability is considered actively exploited where there are reliable indications that attackers are using a specific product vulnerability in practice. As a rule, the evidence comes only from a combination of several signals.

These four sources provide reliable indications:

• Threat intelligence: indications that the vulnerability is being exploited in the field.
• Telemetry: the company’s own product data showing unusual behaviour in use.
• Customer reports: reports of malfunctions, unexplained access or manipulation.
• Support and supplier information: reports from the company’s own service channel and from component manufacturers.

Without these signals, a vulnerability remains a case for vulnerability management, but not a case for the Single Reporting Platform.

What is a serious security incident?

A serious security incident is an event that significantly impairs the security of a product with digital elements, even without a product vulnerability being exploited. The classic case is a compromised update channel affecting the integrity and availability of delivery.

Whether an event reaches this threshold can only be determined in context. These five axes support the assessment:

• Technical severity: how deeply does the incident affect the security properties of the product?
• Reachability: is the affected product reachable from the network or only locally?
• Installed base: how many systems, versions and users are affected?
• Privileges: what rights does an attacker obtain through the incident?
• Data and safety impacts: are data or operational safety affected?

This assessment belongs in a predefined classification, because in an incident there is no time to develop the criteria first.

When does the 24-hour deadline start?

The three deadlines under Article 14 do not start with the first indication. The relevant point in time is when, after an initial assessment, there is reasonable certainty about the event. If a customer reports an anomaly, you assess the product connection and exploitation, and only the confirmed result starts the clock.

All three deadlines under Article 14 run from this point of confirmed knowledge. They do not add up. After the early warning within 24 hours, there are therefore not another 72 hours, but 48 hours remaining until the second notification.

Document the point in time at which knowledge was obtained with an immutable timestamp. In case of doubt, the market surveillance authority will also ask why you did not act earlier.

What information does the CRA notification require after 24 and 72 hours?

Article 14 requires three reports within three time windows, all via the same platform. The first reporting deadline ends after 24 hours with the early warning, the second after 72 hours with the actual notification. The final report then documents the cause and remediation.

Incompleteness is no reason to delay the early warning. After 24 hours, a complete situational picture is available only in the rarest cases; often, forensics is still at an early stage. State what is confirmed, label assumptions as such and leave the rest open.

In parallel with the authority notification, the CRA requires affected users to be informed depending on the risk. This user information does not run via the authority platform and therefore requires a separate process with an advisory and customer base reconciliation.

How does reporting via the Single Reporting Platform work?

CRA reporting is carried out electronically via the Single Reporting Platform operated by ENISA. A notification simultaneously reaches the coordinating CSIRT, in Germany the BSI, and ENISA. The CSIRT then handles further distribution to other bodies.

One reporting channel, however, does not mean a single addressee. The CRA does not provide for a one-stop shop. Neither ENISA nor the BSI informs the data protection supervisory authority, BaFin or your customers, and none of these parallel notifications stops the CRA deadline.

These reporting channels remain your own responsibility after a security incident:

• NIS2 and DORA: separate deadlines, separate taxonomies, separate addressees.
• GDPR: notification to the supervisory authority and, where applicable, communication to data subjects.
• Customer contracts: contractually agreed information obligations towards your customers.
• Product safety: warning the market against the continued use of affected products.

Compliance with the deadline often depends on basic preparatory work. Access to the platform must be in place beforehand. Set up access, appoint a deputy for each decision-maker and go through the process once. In an emergency, there is no time to catch up on this.

Who decides within 24 hours?

The 24-hour deadline is not a legal hurdle, but an organisational one. It is missed if, during an incident, it is unclear who establishes knowledge, who approves and who actually submits the notification. A robust minimum model distributes these tasks across five roles. At the centre is the Product Security Incident Response Team, or PSIRT.

• PSIRT lead: establishes the trigger, keeps track of the clock and coordinates the case.
• Engineering: confirms the product connection, affected versions and exploitability.
• Legal and compliance: assesses the reporting obligation, clarifies responsibility and approves the notification.
• Product and support: identifies the affected customer base and develops the workaround.
• Communications and management: assesses the reputational situation and coordinates the messaging.

Each of these roles needs a named deputy. The Cyber Resilience Act does not recognise office hours. The deadline continues to run at night and at weekends.

An equally important point is a single intake channel for all suspicions. Do not require customers or employees to decide in advance whether a report belongs in the CRA, NIS2 or data protection channel, because this sorting costs precisely the hours that are missing later.

Report or not? Three practical examples

Whether an event triggers the CRA reporting obligation depends on a small number of assessment questions: is there a product connection, is there active exploitation, and if not, is there a serious security incident? Three typical scenarios show how different the answers can be.

Actively exploited IoT camera: reporting obligation triggered

Threat intelligence and customer logs show a command injection against firmware 4.2 of a connected camera. The PSIRT confirms the product connection and active exploitation. This confirmation starts the deadline.

Within 24 hours, the early warning is submitted via the Single Reporting Platform, with narrowed-down versions. By the 72-hour notification, a workaround or hotfix and an impact assessment are available. Finally, you publish a signed patch, inform users, monitor adoption and submit the final report.

Result: product connection and active exploitation are confirmed; Article 14 therefore applies.

Open-source component without exploit: no notification under Article 14

A new CVE becomes known in an integrated library. Proof-of-concept code is public, but there are no reliable indications of active malicious exploitation in the product context. The library is actively integrated into the product.

You patch, test, distribute securely, prepare an advisory and report the finding to the maintainer. You continue to monitor the exploit situation, because a vulnerability with a low rating can relatively quickly become a serious case.

Result: proof-of-concept code alone is not sufficient; remediation and documentation remain mandatory.

Compromised cloud backend: notification on the basis of the serious incident

Attackers compromise the update orchestrator of a B2B appliance. An exploited product vulnerability has not been confirmed, but the integrity and availability of updates are seriously affected. Article 14 therefore applies via the second trigger.

You isolate the update channel, rotate keys, warn customers, preserve evidence and submit the notifications. You present the root cause and controls in the final report. In parallel, you assess NIS2, DORA, GDPR and contractual information obligations separately.

Result: Article 14 applies via the incident; parallel notifications do not stop the CRA deadline.

How do you become ready to report within 90 days?

Reporting readiness can be established in three stages, even though full CRA compliance by 11 December 2027 requires significantly more. The initial focus is on decision-making capability and the reporting channel. Complete documentation follows thereafter.

1. Days 0 to 30: clarify responsibility. Record product scope and product inventory, designate PSIRT and legal owners, define the decision tree for 24 and 72 hours, clarify responsibility for the platform and CSIRT, set up reporting templates and deputies.
2. Days 31 to 60: set up processes. Establish a channel for Coordinated Vulnerability Disclosure, start an SBOM pilot, introduce a triage model, define a hotfix release path, set up a user and advisory process, create an incident matrix for CRA, NIS2, DORA and GDPR.
3. Days 61 to 90: test effectiveness. Conduct a tabletop exercise, close identified gaps, establish KPIs and a gap analysis for Annexes I and II, review technical documentation, approve a prioritised roadmap.

Metrics show whether the process is robust. Meaningful indicators include SBOM coverage of at least 95 percent, time to triage of less than four hours in critical cases and patch SLA fulfilment of at least 90 percent. Two tabletop exercises per year provide the evidence for this.

Anyone who takes these stages now also gains the foundation for full application, because product inventory, SBOM and governance also support the obligations from December 2027.

Conclusion: the CRA reporting obligation is decided in the preparatory work

The CRA reporting obligation under Article 14 has applied since 11 September 2026 and requires three reports from confirmed knowledge. The reporting deadlines are 24 hours for the early warning and 72 hours for the notification, followed by the final report. It is triggered only by an actively exploited vulnerability or a serious security incident, not by every CVE.

It is rarely the legal text that causes failure. The deadline is missed because of the ability to make decisions during the incident. Anyone who only then clarifies which versions are affected, who may approve and how platform access works has already used up the 24 hours.

Five building blocks support the process: visibility and intake, contextual triage, remediation and testing, secure delivery and communication, as well as governance and evidence. They are also the foundation for full application of the Cyber Resilience Act on 11 December 2027.

The greater economic risk lies in market access. Products without clean processes and documentation will sooner or later disappear from the portfolios of distributors and platforms.

Frequently asked questions

#1 Does the CRA reporting obligation also apply to products that came onto the market before 11 September 2026?

Yes, Article 14 also applies to relevant legacy products within the scope of the Cyber Resilience Act. Products placed on the market before 11 December 2027 are generally subject to the full product and conformity obligations only in the event of a substantial modification. Independently of this, they are covered by the reporting obligation.

#2 Does every CVE have to be reported under the Cyber Resilience Act?

No, a known CVE does not in itself trigger a CRA reporting obligation. Reliable indications of active exploitation of the specific product vulnerability or a serious security incident are required. A high CVSS score and published proof-of-concept code are not sufficient, but they do not affect the obligation to remediate.

#3 Does a notification under NIS2 replace the CRA notification?

No, a NIS2 notification does not replace the notification under Article 14 of the Cyber Resilience Act. Both regulatory frameworks have their own addressees and their own deadlines. A single event may trigger parallel reporting obligations under the CRA, NIS2, DORA, GDPR and customer contracts, and none of these notifications stops the CRA deadline.

#4 Who is subject to the reporting obligation under Article 14?

The reporting obligation under Article 14 of the Cyber Resilience Act applies to manufacturers of products with digital elements. Importers and distributors have other obligations: they check marking and documentation and may not make a product available without them. You should therefore clarify your actor role for the respective product before any discussion about responsibility.

#5 What should you do if information is still missing after 24 hours?

The early warning is submitted nonetheless, because incompleteness does not justify a delay. Open fields remain open; uncertain information is marked as an assumption. The missing information is then provided with the 72-hour notification.