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.

Updated 22 August 2026: ENISA has published detailed Single Reporting Platform instructions for assigned-representative registration, notification submission and interface functions. The August guidance makes the operational route clearer, including EU Login, CSIRT validation, draft visibility and the absence of an API at launch.

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.

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. It is a single entry point, not a separate reporting regime. The manufacturer selects the CSIRT designated as coordinator, normally according to the location of its main establishment, and the platform makes the notification available to that CSIRT and ENISA simultaneously unless particularly exceptional circumstances apply.

The coordinator CSIRT is responsible for disseminating the report without delay to other relevant CSIRTs in Member States where the product is available. A CSIRT may delay or withhold wider dissemination only in exceptional circumstances justified on cybersecurity grounds. ENISA may temporarily receive only partial information when the manufacturer invokes the conditions for particularly exceptional circumstances in the 72-hour notification.

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

What ENISA’s August instructions add

ENISA now documents the workflow for Primary and Secondary Assigned Representatives, referred to as AR users. They authenticate through EU Login, select the designated CSIRT and associate their account with the manufacturer or open-source software steward they represent.

CSIRT validation of that association takes place after first access and in parallel with the reporting process. ENISA explicitly says that validation is not a prerequisite for meeting the CRA reporting obligation and does not prevent notification submission. Counterintuitively, ENISA advises organisations to initiate registration and validation only when they need to submit a specific notification, rather than creating SRP accounts pre-emptively. An EU Login account can still be prepared in advance.

The notification itself progresses through three tabs or stages. An early warning must be submitted before the 72-hour notification, and both must exist before the final report. Each stage can be saved as a draft, but a draft is visible only to the AR who created it, not automatically to other representatives associated with the same manufacturer. That detail needs to be reflected in shift cover and absence planning.

The published field matrix also distinguishes what is mandatory, optional, copied forward or automatically generated at the 24-hour, 72-hour and final-report stages. Organisations can automate their internal evidence workflows, but ENISA says no application programming interface will be provided at this stage. Teams expecting frequent reports need a case record that can produce the platform fields without starting a manual investigation each time.

ENISA’s interface guidance, last updated on 14 August, covers manufacturer associations, invitations for backup representatives, dashboard functions and alerts. The public SRP URL is still due to be announced before launch. The European Commission says functional and security testing are under way.

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