Summary

  • From 11 September 2026, manufacturers of covered products with digital elements must report actively exploited vulnerabilities and severe security incidents through the Cyber Resilience Act Single Reporting Platform. The early-warning and fuller-notification limits are 24 and 72 hours after awareness.
  • The portal creates one filing point, not one all-powerful regulator. A manufacturer selects a national CSIRT coordinator; that team ordinarily routes the report to ENISA, other relevant CSIRTs and, where needed, market-surveillance authorities. The first release is English-only, has no API, excludes voluntary reports and does not yet activate open-source software steward duties.

The first operational deadline under Europe’s new product-security regime does not begin with a certification test. It begins with knowledge.

On 11 September 2026, Article 14 of the Cyber Resilience Act started applying to manufacturers of covered hardware and software. Once a manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of a product with digital elements, it must send an early warning without undue delay and within 24 hours. A fuller notification follows within 72 hours. The European Commission’s reporting page says a final vulnerability report is due no later than 14 days after a corrective measure becomes available; a severe-incident final report is due within one month after the 72-hour filing.

Most of the CRA’s product design, vulnerability handling, conformity and market obligations do not become generally applicable until 11 December 2027. The implementation timetable therefore exposes an unusual but intentional sequence: the reporting nervous system is live before the broader body of obligations.

That sequence matters. Authorities can begin receiving structured evidence from products already on the EU market, including products placed there before the main rules apply. Manufacturers cannot treat the next fifteen months as an empty preparation period. The reporting clock is already real.

One form does not mean one authority

The CRA Single Reporting Platform is operated by ENISA. It lets a manufacturer make one notification for a given actively exploited vulnerability or severe incident, even when the company has several EU branches or subsidiaries or a parent outside the Union. The company must coordinate internally and choose the correct Computer Security Incident Response Team designated as coordinator.

That national choice is generally anchored to the manufacturer’s main establishment. It is not a cosmetic address field. The selected CSIRT receives and assesses the report, ordinarily disseminates it to relevant CSIRTs in Member States where the product is available, and may pass information to market-surveillance authorities so they can perform enforcement functions. ENISA receives the report simultaneously in the normal path and manages the platform, but it does not replace the coordinator’s first institutional judgment.

The filing layer is centralised. The responsibility layer is not.

This is the governance design hidden inside the promise to “report once.” A manufacturer supplies the product and event facts. A national CSIRT controls the initial public-authority route. ENISA operates the shared infrastructure and can analyse the aggregate stream. Market-surveillance authorities decide whether the evidence supports investigation or corrective action. Cross-border distribution follows where the product is available, not merely where the reporting company has offices.

The current list of designated coordinators is therefore part of the compliance surface. Choosing the wrong coordinator can invalidate a submission and require refiling, according to ENISA’s FAQ. A legal team that has mapped the regulation but not its product availability and establishment facts has not completed the operational map.

The exception preserves national discretion

The default is fast dissemination. The exception is deliberately narrower.

For a 72-hour report about an actively exploited vulnerability, a reporter may flag Particularly Exceptional Circumstances, or PEC, when immediate sharing could create cybersecurity risk under the statutory grounds. ENISA’s operational guidance makes the division of labour clear: the reporter raises the case; the selected national coordinator decides whether dissemination should be delayed.

If the exception is accepted, the full filing is not immediately exposed through the ordinary path. ENISA initially receives limited information, and the coordinator remains responsible for deciding when and how the full notification can be shared with other concerned CSIRTs and ENISA.

This is not a secrecy switch controlled by the vendor. Nor is every vulnerability report eligible. It is a bounded safety valve inside the 72-hour actively exploited vulnerability flow, with the authority decision held by the national coordinator. That distinction matters whenever a company describes a delayed disclosure as “required” or an authority describes it as a simple platform state. The evidence should show who requested the exception, who decided it and when the routing state changed.

The launch is a minimum viable legal surface

ENISA’s FAQ, updated 10 September, documents a narrower first release than the eventual statutory platform.

It accepts mandatory manufacturer reports for actively exploited vulnerabilities and severe incidents. Voluntary Article 15 reporting is not yet implemented. People and organisations that are not manufacturers are directed to contact the relevant national CSIRT. The reporting duties for open-source software stewards do not begin until 11 December 2027. The platform is available in English only at launch, and no application programming interface is provided. A manufacturer may automate its own internal preparation, but it must submit through the interface.

Access also has a human identity layer. Assigned representatives use personal EU Login accounts with multi-factor authentication. The association between a representative and a manufacturer is validated by the selected coordinator. Validation runs in parallel with reporting rather than blocking the first urgent filing; an unverified representative may submit up to 20 notifications for that manufacturer before verification becomes mandatory.

These details are not footnotes to the regulation. They determine whether a security team can move from awareness to a legally attributable report within a day. A company that waits for an incident before naming representatives, creating EU Login accounts and resolving its coordinator is consuming its 24-hour window on identity administration.

The portal’s timer is useful, but the law owns the deadline

ENISA discloses one especially important launch limitation. The platform’s current 72-hour counter calculates a due time 48 hours after submission of the 24-hour early warning. Because the law calculates the 72 hours from awareness, the displayed counter may mark a report overdue before 72 hours have actually passed. ENISA says the logic will be updated to use the recorded awareness time.

That is a model example of why an interface should not silently become the policy mirror. The portal can send reminders and surface workflow state. It cannot amend Article 14. A cautious manufacturer should preserve its own timestamp for when reliable internal awareness was reached, the early-warning submission time, the 72-hour legal deadline and the platform’s displayed time as separate fields.

The reverse failure is also possible: a portal reminder can never extend a deadline that started before the early warning was filed. Treating the interface as the authoritative clock would turn an implementation detail into a legal interpretation.

The same separation applies during downtime. ENISA says a manufacturer should wait for restoration and then submit through the platform. If immediate communication is necessary, it may contact the designated CSIRT directly, but that contact does not remove the later platform filing requirement. One network probe, failed login or helpdesk exchange does not establish a general outage; the relevant record is the manufacturer’s timed attempt, the service state and the eventual submission.

A live rule needs a visible version history

The public does not need access to active vulnerability contents to test whether this governance mechanism is functioning. It does need a stable description of the operating rules.

ENISA should maintain a privacy-preserving status and version log for the platform: availability incidents, supported reporter classes, supported report types, interface languages, API state, reminder-counter logic and the effective time of each change. The log should never identify a reporter, product weakness or exploit before safe disclosure. It should make the execution boundary inspectable.

That is my editorial recommendation, not a present CRA requirement or an ENISA commitment. It follows the authority-chain discipline in The Policy Mirror, the implementation test in Running Code Primary and the separation of evidence from advocacy in Why BTW Media Exists.

The CRA’s reporting regime is no longer a future promise. Its first clock is running, through a portal whose launch limits are unusually well documented. The next test is whether manufacturers and authorities preserve the authority trail as carefully as the incident data.

Sources