Legislation · 10 Aug 2026 · Rob Nidschelm

The CRA Reporting Clock Starts on 11 September 2026

On 11 September 2026, the Cyber Resilience Act becomes operational in a very specific way. Manufacturers will need to report actively exploited vulnerabilities and severe product-security incidents through ENISA’s Single Reporting Platform. The first clock can expire within 24 hours.

The CRA’s main product-security obligations will not apply until 11 December 2027. That later date still appears on many programme plans. It is not, however, the first date that can create a live regulatory duty.

Article 14 starts applying on 11 September 2026. From that date, an organisation that becomes aware of an actively exploited vulnerability or a severe incident affecting the security of an in-scope product may need to submit an early warning without undue delay and, in any event, within 24 hours.

This is not a future documentation exercise. It is an incident-response capability that needs to work next month.

The first operational CRA deadline arrives early

The reporting obligations apply before the wider conformity, technical-documentation and product requirements become fully applicable in December 2027. That sequencing is deliberate: exploited vulnerabilities and serious product incidents cannot wait for the rest of the implementation period.

It also creates an easy misunderstanding. A manufacturer may conclude that a product placed on the market before December 2027 falls outside the immediate programme. The European Commission’s CRA summary makes clear that the Article 14 reporting obligations apply to products with digital elements that have been made available on the Union market, including products already on the market before the main obligations apply.

The reporting inventory can therefore be wider than the 2027 conformity roadmap. Supported legacy versions, products nearing end of sale and older products still in use may all matter when a reportable event arises.

Not every vulnerability is reportable

The CRA establishes two central mandatory reporting triggers:

1 – An actively exploited vulnerability

An actively exploited vulnerability is not simply a vulnerability with a high severity score or a publicly available proof of concept. The regulation defines it around reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner’s permission.

This distinction matters operationally. Vulnerability teams need a way to evaluate exploitation evidence, not only technical severity. Threat intelligence, customer reports, telemetry, incident investigations, supplier notifications and public reporting may all contribute to that judgement.

The challenge is that evidence may emerge gradually. Product security, threat intelligence and incident response should agree in advance who can decide that the threshold has been reached and when the organisation is considered aware.

2 – A severe incident affecting product security

The second trigger is a severe incident having an impact on the security of a product with digital elements.

Under Article 14, an incident can be severe when it negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It can also be severe when it has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user’s network and information systems.

That definition should be built into the incident-classification process. Teams should not rely only on internal labels such as priority one or critical incident, because those labels may measure business impact differently from the CRA test.

Three stages, several clocks

The reporting process is phased because complete information will rarely be available during the first hours of an event:

1 – Within 24 hours: early warning

The early warning is due without undue delay and, in any event, within 24 hours after the manufacturer becomes aware of the actively exploited vulnerability or severe incident.

The objective is speed, not perfect certainty. The report starts the regulatory process with the information that is available. Waiting for root-cause analysis, a complete customer list or a finished patch can cause the deadline to be missed.

2 – Within 72 hours: notification

A more complete notification follows without undue delay and no later than 72 hours after awareness. It should contain general information about the vulnerability or incident, an initial assessment and available information about corrective or mitigating measures.

The 72-hour stage requires teams to turn technical evidence into a coherent product view: which products and versions are affected, where they were made available, what exploitation or incident behaviour has been observed, what users can do and how sensitive the reported information is.

3 – Final report

The final deadline depends on the trigger.

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available.
For a severe incident, the final report is due within one month after the 72-hour incident notification.

A national CSIRT acting as coordinator may also request an intermediate status report where necessary.

These are not three independent submissions owned by different teams. They are stages of one evidence chain. Facts, decisions and timestamps need to remain consistent as the investigation develops.

The Single Reporting Platform is the route, not the process

Notifications will be submitted through the CRA Single Reporting Platform established and operated by ENISA. The platform is designed as a single entry point. A notification is routed to ENISA and to the CSIRT designated as coordinator, generally based on the location of the manufacturer’s main establishment or, in certain cases, its authorised representative.

ENISA’s current guidance explains that representatives will use EU Login and that the relevant CSIRT will validate the representative’s authority. The detailed user guidance was updated at the end of July 2026 and organisations should consult the latest version before using the platform.

The platform simplifies external submission. It does not decide whether the event is reportable, identify affected products, collect evidence or approve the message. Those capabilities remain the manufacturer’s responsibility.

ENISA also states that organisations may automate their internal reporting workflows, but that no application programming interface is being provided at this stage. A manufacturer expecting a large volume of product-security events should therefore design an internal case record that can produce the required platform fields without repeated manual investigation.

The real problem is knowing when the clock started

Most organisations can write a report in 24 hours if the right people are already working from the right facts. The difficult part is recognising that the obligation has been triggered.

Awareness can begin in many places:

a customer reports suspicious behaviour;
a security researcher provides exploitation evidence;
a managed service detects malicious activity;
a third-party component supplier issues an urgent warning;
telemetry shows unexpected code execution;
an internal red team discovers that a real attacker used the same path;
a public advisory identifies exploitation affecting a component embedded in the product.

If these signals remain in separate support, security, engineering and supplier-management systems, the organisation may not see the reportable event until much later.

A defensible process records when relevant information arrived, who assessed it, what product was involved, how the reporting threshold was evaluated and when the decision was escalated. The process should allow an early warning to proceed while technical investigation continues.

Eight checks to complete before 11 September

The deadline is too close for a large transformation programme. It is still possible to establish a minimum reliable reporting capability.

Confirm the reporting population. Identify products with digital elements that have been made available on the EU market, including supported products released before 2027. Record the responsible manufacturer and relevant establishment.
Name the decision owner. Assign a person who can determine whether the Article 14 threshold is met, supported by legal, product-security and incident-response expertise. Name alternates for nights, weekends and holidays.
Define awareness. Document which events and sources enter the CRA assessment process and how the time of awareness is recorded. Avoid a process in which every team starts its own clock.
Build the two-trigger decision tree. Separate actively exploited vulnerabilities from severe incidents, then link both routes to the 24-hour, 72-hour and final-report stages.
Map the required information. Know where product identifiers, versions, product category, affected Member States, vulnerability data, incident evidence and mitigations can be obtained. Assign an owner to each field.
Prepare platform access and representation. Review ENISA’s current Single Reporting Platform guidance, EU Login requirements and the coordinator-CSIRT route. Keep the primary and alternate reporter details current.
Connect reporting to user protection. Article 14 also requires manufacturers to inform impacted users, and where appropriate all users, about the vulnerability or incident and any measures they can take. Make sure product updates and user instructions can move at the same speed as the regulatory report.
Run a timed exercise. Use a realistic exploited-component or malicious-code scenario. Start with an imperfect alert and test whether the team can reach a decision, create an early warning and preserve a clean record within 24 hours.

One event may trigger several laws

A product-security incident can create obligations beyond the CRA. Depending on the organisation, product, data and services involved, NIS2, GDPR, DORA, sector-specific rules, contractual notification clauses and insurance requirements may also apply.

Separate reporting teams can create contradictory facts and missed deadlines. A better design uses one incident record with several regulatory decision tracks. Technical facts should be collected once, while each legal test, recipient and deadline remains visible.

This also improves customer communication. Users should not receive disconnected explanations from product support, security and account management while regulators receive a fourth version.

The 24-hour report is not supposed to be perfect

Teams sometimes delay notification because they are afraid of changing an early assessment. The phased model recognises that investigations evolve.

The early warning should be accurate about what is known and transparent about what remains under investigation. The 72-hour notification adds detail. The final report explains impact, root cause and corrective action when the evidence is mature.

The operational discipline is to separate facts from assumptions, timestamp important changes and keep the decision trail intact. That is more credible than waiting for certainty that cannot exist during the first day.

September is a maturity test, not the finish line

On 27 July 2026, the European Commission published additional non-binding guidance addressing practical CRA questions, including scope, substantial modification, support periods, reporting and risk assessments. Organisations now have more implementation material, but the reporting deadline does not move while teams interpret it.

The September obligation tests whether product security already functions as an operational capability. Can the organisation recognise exploitation? Can it identify every affected product? Can it contact the right decision-makers? Can it communicate with users and produce a fix? Can it explain what happened without waiting weeks for information from suppliers?

Work done for Article 14 will also support the broader December 2027 obligations. Product inventories, vulnerability processes, support-period ownership, supplier evidence and tested update mechanisms are not temporary reporting controls. They are the foundation of a secure product lifecycle.

The first CRA clock starts on 11 September. The organisation should be ready before the first reportable event starts it for real.

Sources and further reading

This article provides general technical and operational context, not legal advice.

Continue the series: European National Cyber & Digital Law Series index

The CRA Reporting Clock Starts on 11 September 2026

The first operational CRA deadline arrives early