CRA Single Reporting Platform (SRP): how ENISA vulnerability reporting works

The Single Reporting Platform (SRP) is the central EU system, operated by ENISA, through which manufacturers report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act (CRA) from 11 September 2026, submitting once rather than to each Member State separately. This post explains what the SRP is, what you report and in how much detail at each stage, who receives a report and how it is disseminated, the voluntary reporting it also supports, and the confidentiality and delay mechanisms that protect sensitive notifications.

This post is a companion to our guide on the September 2026 vulnerability reporting deadline, which covers scope, what qualifies as a reportable event, and how to prioritize the work. Here the focus is the ENISA SRP platform itself and the reporting flow.

What is the SRP?

The SRP is a single electronic platform established, operated, and maintained by ENISA under Article 16 of the CRA. It is scheduled to be operational by 11 September 2026, the date the reporting obligations enter into application, with a testing period expected beforehand. ENISA maintains an overview of the SRP and a set of frequently asked questions that it updates as implementation progresses.

Its purpose is consolidation. Instead of notifying multiple national authorities separately, a manufacturer reports once through the platform. The SRP is the channel for mandatory reporting by manufacturers, and it also supports voluntary reporting by any natural or legal person. It does not replace your other obligations, such as informing users under Article 14(8) or reporting a component vulnerability to the component maintainer under Article 13(6).

Failure to meet the Article 14 reporting obligations can carry administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)).

What you report at 24 hours, 72 hours, and the final report

Reporting is staged. The early warning at 24 hours is deliberately minimal, the notification at 72 hours fills in the details about vulnerabilities or incidents, and the final report carries the full account.

ENISA has recently published obligatory reporting fields. The tables below reproduces the field structure from ENISA's website. The codes are:

• X: obligatory

• O: optional

• I: obligatory if such information is available

• C: by default copied from the previous step, or updated

• A: automated, not visible to the submitter

The three stages are the 24-hour early warning, the 72-hour notification, and the final report.

Common fields

These apply to both vulnerability and incident reports.

Vulnerability fields

Incident fields

Fields that need judgment, not just data entry

Several fields look like simple data entry but call for judgment under time pressure, and some carry CRA-specific meaning that differs from how the same information is handled in ordinary vulnerability management. The points below illustrate the kinds of considerations involved. ENISA is expected to publish further detail and examples as the platform is implemented, so these are considerations rather than settled answers.

• Considered sensitivity of information. This field is easy to treat as a formality, but it appears to carry weight beyond the report itself. Under Article 16(2), the sensitivity a manufacturer indicates is part of what a coordinator CSIRT weighs when deciding whether to delay onward dissemination, and in particularly exceptional cases it relates to whether ENISA initially receives only partial information. Marking it thoughtfully matters in both directions: understating sensitivity may forfeit protection you were entitled to for an unpatched, actively exploited vulnerability, while overstating it could slow information reaching defenders who need it. How this is applied in practice is an area where further guidance would help.

• Severity and impact of the vulnerability or incident. It is tempting to equate severity with a CVSS base score, but the CRA frames cybersecurity risk as a combination of the magnitude of loss or disruption and the likelihood of an incident (Article 3(37) and (38)). That is a product-and-context judgment, not only an abstract score. A high base score for a component may translate into low real severity if the component is barely reachable in your product, and a moderate score may be serious in a product deployed in sensitive environments. Assessing this well depends on understanding how the vulnerability behaves in your specific product.

• Member States where the product is available. This field can be obligatory already in the early warning if the information is available, and it influences routing, since the coordinator disseminates the notification to CSIRTs in the Member States where the product is available. For products sold through distributors or integrated into other products, establishing the actual Member State footprint can be harder than it first appears.

Fields like these are worth working through in advance, so that when a report is due the answers come from applying a method rather than improvising under pressure. Settling how such judgment calls will be assessed before a live event is what keeps a 24-hour deadline manageable.

Who receives a CRA report: coordinator CSIRT and ENISA

When a manufacturer submits a notification, it goes simultaneously to the CSIRT designated as coordinator and to ENISA. The coordinator CSIRT, is then responsible for disseminating the notification without delay to other relevant CSIRTs in the Member States where the product is available, and to market surveillance authorities as needed. You submit once; the onward distribution is handled for you.

Your coordinator CSIRT is determined by where you are established, under Article 14(7). If you are established in the EU, it is the coordinator in the Member State of your main establishment, meaning where decisions on the cybersecurity of your products are predominantly taken. If you are not established in the EU, it is the coordinator in the Member State where your authorised representative is established.

This is why determining your main establishment in advance matters more than it might seem. It is what fixes your coordinator CSIRT, and the coordinator is also your point of contact during a case, for example if it requests an intermediate status update or provides helpdesk support. For non-EU manufacturers, it makes the authorized representative arrangement a prerequisite to settle before a live event, not during one.

Can you delay a CRA vulnerability or incident report?

Not yourself as a manufacturer. You submit once to the SRP, and the platform makes the notification available to your coordinator CSIRT and ENISA. Whether onward sharing to other authorities is held back is decided by the coordinator CSIRT, not by you.

What you can do is flag the sensitivity of the information when you submit, using the sensitivity field, and request a delay. Under Article 16(2), the coordinator CSIRT may then hold back dissemination to other Member States' CSIRTs on justified security grounds, for the time strictly necessary, for example while a patch is expected shortly or while a vulnerability is in coordinated disclosure. Flagging sensitivity puts that option on the table; the decision rests with the CSIRT. The Commission's delegated act of 11 December 2025 sets out the conditions the CSIRT applies.

Voluntary reporting via SRP

The platform also supports voluntary reporting under Article 15. Any natural or legal person, not only manufacturers, may notify a vulnerability contained in a product with digital elements, a cyber threat that could affect a product's risk profile, an incident affecting the security of a product, or a near miss that could have led to such an incident. Voluntary reporting does not place the notifying party under additional obligations it would not otherwise have, and coordinators may prioritize mandatory notifications over voluntary ones. This is the route for events that fall outside mandatory reporting, for example a vulnerability that is not actively exploited.

ENISA's wider role around the platform

Beyond running the platform, ENISA has several related responsibilities. It operates a helpdesk, with particular attention to the needs of small and medium-sized enterprises. It prepares a technical report on emerging cybersecurity risk trends in products with digital elements every 24 months, with the first due within 24 months of the reporting obligations starting. And, in agreement with the manufacturer, it adds publicly known vulnerabilities to the European Vulnerability Database (EUVD) once a security update or other corrective or mitigating measure is available. ENISA is also required to secure the platform and to notify the CSIRTs network and the Commission of any security incident affecting it.

Preparing for the platform

The SRP is where you submit, but the things that make reporting work are better settled in advance. The following points should be done before a reportable event arrives.

• Determine your main establishment, and therefore your coordinator CSIRT, in advance.

• Decide in advance who is authorized to submit a report and availability of necessary personel, since awareness can arrive at any time and the early-warning window is short.

• Make sure the people who will report can produce the staged content the SPR requires, the minimal early warning first, then the detailed notification, then the final report, within the deadlines.

• Decide in advance how your process will assess the judgment-based fields, particularly sensitivity and severity, since those are the ones least suited to being worked out for the first time while a clock is running.

The SRP platform is the endpoint of a reporting process that has to work quickly and correctly under pressure. At Tributech, we work with manufacturers preparing for CRA reporting, and we are happy to discuss how these requirements apply to your products. Book a meeting with a CRA expert here.