Legislation · 11 Sep 2026 · Rob Nidschelm

Europe Just Started the 24-Hour Cyber Reporting Clock for Digital Products

Europe’s Cyber Resilience Act moved from preparation into live incident response on 11 September 2026. ENISA has launched the first operational version of its Single Reporting Platform, and manufacturers must now use it to report actively exploited vulnerabilities and severe product-security incidents. The first notification can be due within 24 hours.

The wider Cyber Resilience Act requirements for products with digital elements will not apply until 11 December 2027. That later date remains important, but it no longer describes the whole compliance timetable. Article 14 reporting duties apply from today.

ENISA describes the launch as the platform’s “initial operating capability” and says it will expand the system over the coming months. The portal is publicly reachable at portal.cra-srp.enisa.europa.eu.

For manufacturers, this is not merely a new website. It changes what must happen when product-security teams receive credible evidence of exploitation or discover a severe security incident. The organisation must recognise the reporting trigger, establish when it became aware, identify the correct national coordinator and submit an accurate early warning while the technical investigation is still developing.

What must be reported from today

The platform currently accepts the two mandatory Article 14 report types:

1. Actively exploited vulnerabilities. The CRA defines these around reliable evidence that a malicious actor has exploited a vulnerability without the system owner’s permission. A high CVSS score, public proof of concept or theoretical exploitability does not by itself establish that threshold.
2. Severe incidents affecting product security. These are incidents that negatively affect, or are capable of negatively affecting, a product’s ability to protect the availability, authenticity, integrity or confidentiality of important data or functions. The definition also reaches incidents capable of introducing or executing malicious code in the product or a user’s systems.

The distinction matters. The SRP is not a general vulnerability mailbox at launch, and ENISA says voluntary reporting under Article 15 will arrive in a future phase. People who are not reporting as a manufacturer should currently contact the relevant national CSIRT directly.

The reporting obligations for open-source software stewards do not begin until 11 December 2027. ENISA’s launch materials refer to those future users, but Article 14 applies to manufacturers now.

The first report is due before the investigation is finished

The CRA uses a staged reporting process:

• Within 24 hours: submit an early warning without undue delay after becoming aware of an actively exploited vulnerability or severe incident.
• Within 72 hours: provide the fuller vulnerability or incident notification, including the general nature of the event, an initial assessment and available corrective or mitigating measures.
• Final report for an exploited vulnerability: submit it no later than 14 days after a corrective or mitigating measure becomes available.
• Final report for a severe incident: submit it within one month after the 72-hour notification.

Those stages recognise that the first day of an incident rarely produces a complete root cause, affected-product inventory or impact assessment. The early warning is not supposed to wait for forensic certainty. It should state what is known, what remains under investigation and when the organisation became aware.

Only one SRP notification is required for a given event, even when a manufacturer has several EU branches or a parent company outside the Union. The manufacturer is responsible for coordinating that submission across its corporate structure.

One portal now distributes the report across Europe

The Assigned Representative submitting the notification selects the CSIRT designated as coordinator. That choice is generally based on the manufacturer’s main establishment under Article 14(7).

The notification is then made available to ENISA and the receiving coordinator. The coordinator disseminates it to relevant CSIRTs in other Member States where the affected product is available and can provide information to market-surveillance authorities.

That is the administrative benefit of the SRP: manufacturers report through one route instead of separately notifying authorities across several Member States.

It also makes the initial routing decision important. ENISA warns that choosing the wrong coordinator can invalidate a notification and require it to be submitted again. Organisations should establish the correct CSIRT before an incident starts, even though ENISA advises Assigned Representatives to begin the platform registration and validation process only when they have a specific notification to submit.

The launch version is deliberately manual

Assigned Representatives access the portal through EU Login, with multi-factor authentication required. ENISA provides Primary and Secondary or backup representative roles. CSIRT validation that a representative is authorised to act for a manufacturer occurs after registration and in parallel with reporting; ENISA says it is not a prerequisite for submitting a notification.

There is no API in the first release. Companies can automate their internal evidence collection, decision-making and case management, but the final notification must be entered through the web interface. That increases the value of a prepared field map that can turn incident records into the information required at the early-warning, 72-hour and final-report stages.

The platform is available only in English at launch. ENISA has published an Assigned Representative user manual, a tutorial video, a detailed SRP glossary, registration guidance, notification submission and update instructions and a downloadable SRP factsheet.

Do not let the portal’s counter define the legal deadline

ENISA has documented an important limitation in the launch release. The platform’s current 72-hour counter displays a deadline 48 hours after the 24-hour early warning was submitted.

That does not always equal 72 hours after the manufacturer became aware of the event. If the early warning is filed quickly, the interface can mark the fuller notification as overdue before 72 hours have elapsed from awareness.

ENISA says a future release will calculate the deadline using the recorded awareness time. Until then, the counter is a reminder, not the legal clock. Manufacturers remain responsible for meeting the Article 14 deadline and should calculate it from the moment of awareness recorded in their incident system.

The platform also lacks a final-report counter for actively exploited vulnerabilities because that deadline depends on when a corrective or mitigating measure becomes available. The organisation must track that date itself.

What manufacturers should do today

1. Name the reporting owner and backup. Product security, incident response, legal and communications should know who can decide that the Article 14 threshold has been met and who can submit during nights, weekends and absences.
2. Prepare EU Login with MFA. ENISA advises against pre-emptive SRP registration, but the underlying EU Login and multi-factor authentication can be made ready.
3. Confirm the correct coordinator CSIRT. Record the Article 14(7) reasoning so the representative does not have to determine the route during the first reporting hour.
4. Use one awareness timestamp. Support, threat intelligence, engineering and incident-response teams must feed a shared decision process. Several competing clocks are an invitation to miss the earliest one.
5. Map the SRP fields to evidence owners. Product identifiers, affected versions, Member States, exploitation evidence, mitigations and user guidance should already have named sources.
6. Plan for manual submission. The lack of an API means the process needs an available human representative and a controlled way to transfer information from the incident record.
7. Track deadlines outside the portal. Do not treat the current 72-hour display or the absence of an exploited-vulnerability final counter as the authoritative calculation.
8. Test the unavailable-platform route. ENISA says manufacturers should submit once the SRP returns. If immediate communication is necessary during an outage, they may contact the designated CSIRT directly, but the SRP submission is still required afterwards.

The obligations are not retrospective where a manufacturer was already aware of active exploitation before 11 September. If awareness begins after today, however, the duty can apply even when the underlying vulnerability or product is older.

The portal is live; the difficult part remains inside the organisation

The SRP solves the external routing problem. It does not decide whether evidence is reliable, determine which products contain an affected component, establish when awareness began, prepare customer guidance or reconcile CRA reporting with NIS2, GDPR, DORA and contractual duties.

BlackTree’s earlier CRA reporting readiness guide examined those internal decisions in detail. The launch makes its central point immediate: the platform is the destination, not the reporting capability.

From 11 September 2026, a manufacturer that learns of real exploitation no longer has the luxury of treating CRA reporting as part of its 2027 programme. The first clock is already running.

Sources

• ENISA: The CRA Single Reporting Platform is launched, 11 September 2026.
• ENISA: Single Reporting Platform, accessed 11 September 2026.
• ENISA: CRA SRP frequently asked questions, updated 10 September 2026.
• ENISA: Assigned Representative registration guidance, updated 10 September 2026.
• ENISA: Notification submission and update guidance, updated 9 September 2026.
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act.
• European Commission: Cyber Resilience Act, updated 7 September 2026.

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