CRA: vulnerability reporting starts 11 September
News · Upcoming deadline
On 11 September 2026, in twenty days, Article 14 of Regulation (EU) 2024/2847 becomes applicable. Any manufacturer of a product with digital elements that learns of an actively exploited vulnerability then has 24 hours to file an early warning. This is the first binding obligation of the Cyber Resilience Act, it applies to products already on the market, and there is no transitional period. The platform that is supposed to receive those reports is described by the Commission as still undergoing functional and security testing.
In short:
- Article 14 applies on 11 September 2026. The CE marking obligations follow separately on 11 December 2027.
- There are two reporting cascades, not one, and their final-report clocks differ.
- The 24-hour clock starts when the manufacturer becomes aware, not when a fix exists.
- The report goes to the CSIRT of your main establishment, which the regulation defines as where cybersecurity decisions are predominantly taken, not where the company is registered.
- ENISA states the platform "will be used" from 11 September; the Commission states testing is under way. It is not open today.
Two clocks, not one
Section titled “Two clocks, not one”Article 14 separates actively exploited vulnerabilities (paragraphs 1 and 2) from severe incidents (paragraphs 3 and 4). The first two steps look identical. The final report does not.
| Step | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | 24 hours from becoming aware | 24 hours from becoming aware |
| Full notification | 72 hours from becoming aware | 72 hours from becoming aware |
| Final report | 14 days after a corrective or mitigating measure is available | one month after the 72-hour notification was submitted |
The difference matters when a fix takes a long time. For a vulnerability, the final-report clock does not start until a corrective or mitigating measure exists, so a hard problem does not put you in breach of the 14-day step. For a severe incident, the clock starts from your own 72-hour notification regardless of whether the matter is resolved.
The early warning is deliberately thin: for a vulnerability it need only indicate, where applicable, the Member States where the manufacturer knows the product has been made available. For an incident it must state at least whether the incident is suspected of being caused by unlawful or malicious acts.
What counts as a "severe" incident
Section titled “What counts as a "severe" incident”Article 14(5) defines it, and the threshold is lower than the word suggests. An incident is severe where either condition holds:
- it negatively affects or is capable of negatively affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or
- it has led or is capable of leading to the introduction or execution of malicious code in the product, or in the network and information systems of a user of the product.
Both limbs include capability, not just realised harm. An incident that could have led to malicious code execution is reportable even if nothing was executed.
Which CSIRT receives it, and the rule most summaries get wrong
Section titled “Which CSIRT receives it, and the rule most summaries get wrong”The notification goes through the single reporting platform of Article 16, using the electronic notification endpoint of the CSIRT designated as coordinator for a specific Member State. Article 14(7) sets out how that Member State is determined, and it is not simply "where your office is".
For a manufacturer with a main establishment in the Union, the regulation defines main establishment as the Member State where the decisions related to the cybersecurity of its products are predominantly taken. Only if that cannot be determined does it fall back to the Member State where the manufacturer has the establishment with the highest number of employees in the Union.
That is a deliberate choice of criterion. A company registered in one Member State whose security engineering is run from another reports to the second, not the first.
For a manufacturer with no main establishment in the Union, Article 14(7) sets an ordered cascade:
| Order | Member State determined by |
|---|---|
| 1 | where the authorised representative acting for the highest number of that manufacturer's products is established |
| 2 | where the importer placing the highest number of that manufacturer's products on the market is established |
| 3 | where the distributor making available the highest number of that manufacturer's products is established |
The authorised representative therefore determines the CSIRT only for manufacturers without a main establishment in the Union, and only as the first step of a cascade. It is commonly reported as the general rule; it is not.
Whatever endpoint is used, the notification must be simultaneously accessible to ENISA. Article 14(6) also allows the receiving CSIRT to request an intermediate status report.
The platform, twenty days out
Section titled “The platform, twenty days out”The single reporting platform exists so a manufacturer reports once rather than notifying authorities in 27 Member States separately. Its status is worth reading precisely, because the obligation does not wait for the tooling.
The ENISA page states that as of 11 September 2026 onwards, the SRP will be used by national CSIRT teams and manufacturers for mandatory reporting, and describes the current period as one in which it "is taking the necessary steps to support the successful implementation of the platform". The Commission's reporting page states the platform will be operational by 11 September 2026 and that functional and security testing are under way.
Neither page publishes a contingency for the platform being unavailable on the day. ENISA does publish guidance on user registration and notification procedures, and runs a support desk at cra-srp-helpdesk@enisa.europa.eu.
A separate delegated act adopted on 11 December 2025 governs when a CSIRT may delay passing a notification to other national teams on justified cybersecurity grounds. That concerns dissemination between authorities, not the manufacturer's own deadline.
What to do before 11 September
Section titled “What to do before 11 September”- Decide who owns the 24-hour clock. It starts on awareness, including awareness reaching a support inbox or a researcher's email on a Friday evening. Name the role, not the person, and give it an out-of-hours path.
- Determine your reporting Member State now, using the Article 14(7) test rather than the registered address. Write down the reasoning: predominant cybersecurity decision-making is a question of fact you may have to defend.
- Register on the platform as soon as registration opens. Discovering the onboarding flow during a live incident is the failure mode this deadline creates.
- Write the two cascades into the incident procedure, with the differing final-report clocks, rather than a single 14-day rule.
- Check the severity test against your own triage. Article 14(5) captures capability, so an internal "no impact observed" verdict does not by itself put an incident out of scope.
Going further
Section titled “Going further”- Cyber Resilience Act, 2026 and 2027 timeline: the full staged calendar to 11 December 2027
- Cyber Resilience Act guide: scope, product classes and assessment routes
- CRA: 17 draft ETSI standards open for comment: why no product yet has a presumption of conformity
Sources & references
- Regulation (EU) 2024/2847, Cyber Resilience Act, articles 14 and 16 , EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj
- Single Reporting Platform (SRP) , ENISA www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
- Cyber Resilience Act, reporting obligations , European Commission digital-strategy.ec.europa.eu/en/policies/cra-reporting