The CRA Single Reporting Platform (SRP): status, registration and what to prepare

Short answer: The Single Reporting Platform (SRP) is the ENISA-operated system through which manufacturers report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act, mandatory from 11 September 2026. Till now the platform is not live, its public URL has not been published, the list of coordinating CSIRTs is still pending, and ENISA states plainly that no API will be provided at this stage. Everything you can actually prepare for sits outside the platform: an EU Login account, named representatives, the notification fields, and a triage process that notices the 24-hour deadline.

The SRP in 30 seconds:

• What it is: a single electronic channel, established under Article 16 CRA, that lets manufacturers and open-source software stewards report once instead of notifying several national authorities.
• Who runs it: ENISA establishes, manages and operates it day to day.
• When it matters:11 September 2026, the day Article 14 reporting obligations become applicable.
• Current status:not live. The access URL is described by ENISA as forthcoming, and the list of CSIRTs designated as coordinators has not been published.
• ENISA, verbatim: "No Application Programming Interfaces will be provided at this stage." Submission is a web form, filled in by a human.
• Deadlines: early warning within 24 hours, notification within 72 hours, final report within 14 days (vulnerability) or one month (severe incident).
• Registration: via EU Login, as an Assigned Representative. CSIRT validation runs in parallel and is not a precondition for filing.
• Cross-border sharing is manual: other affected CSIRTs receive the early warning, the 72-hour notification and the final report only after the coordinator forwards them by hand.
• Voluntary reporting (vulnerabilities, cyber threats, near misses) is enabled only after 11 September 2026.
• Penalties: up to 15 million € or 2.5 % of global annual turnover.

What the Single Reporting Platform actually is

The Single Reporting Platform exists because the CRA would otherwise have produced a reporting nightmare. A manufacturer selling across the EU could have faced separate notifications to every national CSIRT in every market. Article 16 CRA therefore tasks ENISA with a single platform, and Articles 14 to 17 supply the surrounding regime, together with the Delegated Regulation of 11 December 2025 governing exceptions to dissemination.

Mechanically, one submission reaches two recipients at once: the CSIRT designated as coordinator in the Member State of your main establishment, and ENISA. The coordinating CSIRT then passes the information on to other CSIRTs and authorities that need it. That second hop is where the practical detail hides. We will return to it below.

Status check: the platform is not live, and there is no API

At the time of writing the SRP is not in operation. ENISA continues to name 11 September 2026 as the date from which the platform will be used for mandatory reporting, describes the access URL as still to come, and has not published the list of coordinating CSIRTs. What exists today is documentation: registration guidance dated 3 August 2026, a description of platform interface functions dated 14 August 2026, a factsheet, and a FAQ.

The single most consequential line in that FAQ is this: "No Application Programming Interfaces will be provided at this stage." There is no machine interface at launch. Every notification is a web form completed by a human.

If your compliance design assumed that your vulnerability management platform, your SIEM or your ticketing system would file the report automatically, that assumption is void for the launch window. Rewrite the process around a human with a working account who can be reached at any hour, because the 24-hour clock does not pause for weekends or holidays.

ENISA also does not document a fallback channel for the case where the platform is unreachable, at launch or later. The deadline still runs. Keep your CSIRT contact route and the ENISA helpdesk address (cra-srp-helpdesk at enisa.europa.eu) documented, so that you can document a timely attempt if the platform fails you.

Who has to register, and who does not

Two groups file through the SRP: manufacturers of products with digital elements, and open-source software stewards, whose obligations sit in Article 24(3) CRA and apply to the extent they are involved with products with digital elements. ENISA's registration guidance addresses both explicitly.

Importers and distributors are not the filing party for Article 14 notifications. Their CRA duties lie elsewhere. If you are a distributor who discovers an exploited vulnerability, your route is the manufacturer, not the SRP.

Which national CSIRT is yours follows from the location of your main establishment, under Article 14(7) CRA. For a manufacturer established in Germany that is the BSI. For a manufacturer with no EU establishment, the question is genuinely harder and interacts with the authorised-representative rules, which is a different provision from the platform role of the same-sounding name.

The naming trap: Assigned Representative is not the Authorised Representative

This deserves its own heading because it is the mistake most likely to end up frozen inside an internal procedure.

The Assigned Representative (AR) is a platform account role. It is the person who logs in and files. The authorised representative under Article 18 CRA is a legal function, a party established in the EU mandated to act for a manufacturer. A company can perfectly well have the first without needing the second.

Treat them as one thing in your documentation and you will eventually name the wrong person: a lawyer with a mandate but no operational role, or an engineer who can fill in the form but holds no authority. Search your procedures for both terms and separate them now, while it costs nothing.

Registration: what you can do today, and what you should not rush

The registration flow published in August runs as follows:

1. Open the SRP and select the Assigned Representative role.
2. Choose your designated CSIRT from a dropdown.
3. Authenticate through EU Login (ecas.ec.europa.eu).
4. Accept the legal agreement.
5. Confirm the pre-filled personal details (first name, last name, email, legal name).
6. Add the manufacturer details (name, address, additional information).

A Primary AR invites further Secondary ARs by email, and that invitation is valid for seven days. Use it. A sole individual is a single point of failure against a 24-hour deadline.

Counter-intuitively, ENISA suggests waiting to register on the SRP until you actually need to file, since validation runs afterwards in any case. What you should not wait on, is the EU Login: those accounts can be created today, need no authority involvement, and are the one hard dependency you can remove from the critical path beforehand.

ENISA has additionally published a table of the notification data fields per reporting stage, marking which are obligatory, conditional and optional, plus guidance documents, a factsheet, videos and a webinar roughly two weeks before launch. Build your internal early-warning template from that field table rather than guessing at it.

CSIRT validation does not block your notification

ENISA's August guidance settles a question that could otherwise have produced an absurd outcome. Validation of an assigned representative's registration by the CSIRT designated as coordinator (CDaC) is not a prerequisite for fulfilling the CRA reporting obligation. It happens after first platform access and runs in parallel.

Without that clarification a manufacturer could have faced an actively exploited vulnerability, a running 24-hour clock, and an account awaiting government approval. That scenario is off the table. It is also the single most reassuring fact in the whole guidance package, and almost nobody writing about the SRP mentions it.

Cross-border sharing is a manual step

A change in the August documentation has gone largely undiscussed. Affected CSIRTs in other Member States receive the early warning, the 72-hour notification and the final report only after manual dissemination by the coordinating CSIRT. Previously only the final report required a human to forward it.

ENISA itself still receives the submission simultaneously. Your obligation is unchanged: you file once. Your expectations should change considerably. Do not assume that authorities, operators of critical infrastructure or customers across your markets have been informed in step with your filing. If you sell into several Member States, your own notification and communication plan still has work to do after the SRP submission is accepted.

Dissemination can also be delayed in exceptional circumstances on cybersecurity grounds, under the Delegated Regulation of 11 December 2025, where the manufacturer flags that the conditions in Article 16(2)(a) to (c) apply.

Legacy products: in scope, but not retroactive

A widely repeated shorthand overshoots here, so precision matters. The obligation is not limited to newly placed products: vulnerabilities in products already on the EU market can be reportable. But the duty attaches to the manufacturer's awareness, and it does not reach back to awareness that arose before the obligation applied. Knowledge you had before 11 September 2026 does not have to be retro-filed. Knowledge you gain after that date is reportable, even for an old product.

In practice this moves the burden from your roadmap to your installed base. Firmware from 2019 that you still maintain or ship belongs to the set. Without a dependable inventory of live product versions and their components, a Software Bill of Materials being the usual instrument, the 24-hour deadline is not reliably achievable, because the prior question stays open: does this affect us, and in which version?

The standardisation gap behind the deadline

A second delay runs in parallel and matters for 2027 rather than for September. In July 2026 the Commission published a draft amendment to the CRA standardisation request (mandate M/606) moving the 2026 drafting deadlines back by two months: horizontal A and B standards to 31 October 2026, product-specific C standards to 31 December 2026.

Two caveats belong with that. The corresponding decision is not yet published in the Official Journal, so those dates are proposed rather than legally fixed. And to date no harmonised CRA standard has been cited in the Official Journal for any product category. Until a citation exists, the presumption of conformity under Article 27 is unavailable and the self-assessment route under Article 32(2) for Class I products cannot be relied upon.

None of this affects 11 September 2026, because reporting obligations do not depend on harmonised standards. It affects the December 2027 milestone, and it is the more consequential news for anyone planning conformity work.

Checklist: what must be in place before 11 September 2026

1. Create EU Login accounts for at least two people. No authority, no platform needed.
2. Determine your coordinating CSIRT from your main establishment (Article 14(7)). The official list is still pending.
3. Name a Primary and Secondary AR, with explicit cover for holidays and weekends.
4. Separate Assigned Representative from Article 18 authorised representative in every procedure.
5. Route platform confirmations to a monitored shared mailbox, never a personal one.
6. Draft your first 24-hour early warning from ENISA's field table, per reporting stage.
7. Define triage: what makes a vulnerability "actively exploited", and when the clock starts.
8. Inventory the installed base, including old versions you still maintain.
9. Check whether you are an open-source software steward under Article 24(3).
10. Document a fallback: how you evidence a timely attempt if the platform is unreachable.

Conclusion

The deadline is fixed and the platform behind it is not. That asymmetry is the story: a legally binding obligation arrives on 11 September 2026, while the system meant to discharge it is unreachable till now, offers no automation at launch, and documents no fallback for its own unavailability.

The practical consequence is that you cannot prepare the tool, only the procedure. Named people with working credentials, a clear definition of when the clock starts, a pre-drafted notification built from the official field list, and an installed base you can search in minutes. None of it depends on the SRP. All of it decides whether 24 hours is enough.

For a full walkthrough of the obligation itself, deadlines, affected products, SBOM and penalties, see our guide on the CRA reporting requirement from September 2026. This article covers the platform.

Frequently asked questions

Is the Single Reporting Platform live yet?

No. As of 31 August 2026 the SRP is not in operation, its public URL has not been published, and ENISA has not released the list of CSIRTs designated as coordinator. ENISA continues to name 11 September 2026 as the date from which the platform is used for mandatory reporting, and published registration guidance, a factsheet and a FAQ during August 2026.

Is there an API for the CRA Single Reporting Platform?

Not at launch. ENISA's SRP FAQ states that no Application Programming Interfaces will be provided at this stage. Notifications are submitted through a web form by a person, so automated filing from a vulnerability management or ticketing system is not possible on 11 September 2026.

Who has to register on the SRP?

Manufacturers of products with digital elements and open-source software stewards, through a nominated Assigned Representative. Importers and distributors are not the filing party for Article 14 notifications. Registration uses EU Login.

Does CSIRT validation have to be complete before I can file?

No. Validation of an assigned representative's registration by the CSIRT designated as coordinator is not a prerequisite for fulfilling the CRA reporting obligation. It takes place after first platform access and runs in parallel, so a pending approval does not block the 24-hour clock.

What are the CRA reporting deadlines?

Three stages. An early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available for an actively exploited vulnerability, or within one month for a severe incident.

What is the difference between the Assigned Representative and the authorised representative?

The Assigned Representative is a platform account role that files notifications on the SRP. The authorised representative under Article 18 CRA is a legal function for manufacturers without an EU establishment. A company can have the first without needing the second, and conflating them in a procedure leads to naming the wrong person.

Which CSIRT receives my notification?

The CSIRT designated as coordinator in the Member State of your main establishment, under Article 14(7) CRA, together with ENISA at the same time. That coordinating CSIRT then forwards the information to other relevant CSIRTs and authorities, and since August 2026 that forwarding is a manual step for all three reporting stages.

Does the CRA reporting obligation cover products already on the market?

Yes, but not retroactively. Vulnerabilities in products already on the EU market can be reportable. The duty attaches to the manufacturer's awareness and does not extend to awareness that arose before the obligation applied, so knowledge held before 11 September 2026 does not require a retrospective filing.

Can I report voluntarily through the SRP?

Yes, but only after 11 September 2026. ENISA plans to enable voluntary reporting of vulnerabilities, cyber threats, incidents and near misses once the platform is operational for mandatory reporting.

What are the penalties for missing a CRA reporting deadline?

For breaches of the essential cybersecurity and reporting requirements, up to EUR 15 million or 2.5 % of global annual turnover, whichever is higher. Lower ceilings apply to other CRA obligations and to supplying incorrect or misleading information.

Do open-source projects have to report under the CRA?

Open-source software stewards have their own reporting obligations under Article 24(3) CRA, to the extent they are involved with products with digital elements, and ENISA's SRP registration guidance addresses them explicitly. Their duties are not identical to those of a manufacturer.

What happens if the SRP is unavailable when I need to report?

ENISA does not document a fallback channel, and the deadline continues to run. Keep your CSIRT contact route and the ENISA SRP helpdesk address on record so that a timely attempt can be evidenced if the platform is unreachable.