Guide · updated 17 October 2026

ENISA Single Reporting Platform: how to file a CRA report

Since 11 September 2026, every report under Article 14 of the Cyber Resilience Act goes through one web portal run by ENISA. Here is how access works, who may file, and what each form asks for.

What the SRP is

The CRA Single Reporting Platform (SRP) is the portal manufacturers use to notify actively exploited vulnerabilities and severe incidents affecting their products with digital elements. ENISA switched it on on 11 September 2026, the day the reporting obligations started to apply. A notification goes to the CSIRT you designate as coordinator and reaches ENISA at the same time, so you file once rather than once per country.

The platform is a web form. There is no API for manufacturers to submit through, so whoever files needs the facts gathered in advance and a person available to type them in.

Who can file: assigned representatives

Access is personal. Each person who files uses their own EU Login account with multi-factor authentication. On the platform, people act for a manufacturer as assigned representatives:

one primary assigned representative per manufacturer, and
up to 20 secondary assigned representatives.

ENISA's manual describes an assigned representative as a user acting on behalf of a manufacturer. The national CSIRT then validates that the person is authorised to submit for that manufacturer. Validation runs alongside reporting rather than blocking it, and procedures vary by CSIRT, so keep written proof of authorisation (for example a signed mandate letter) for anyone outside your company who files for you.

Practical tip: set up at least two people with working EU Login and MFA before you need them. A single person on holiday, or a lost phone with the authenticator app, should not stop a 24-hour filing.

Choosing your coordinating CSIRT

You notify the CSIRT designated as coordinator in the Member State of your main establishment in the EU. If you have no main establishment in the EU, Article 14(7) sets an order of fallbacks: the Member State where your authorised representative is established, then where your importer is, then your distributor, then where most of your users are. Choose carefully: reports sent to the wrong coordinator may be treated as invalid and need resubmitting, which costs time you don't have.

What each report asks for

The forms follow Article 14 closely. The table summarises what you need for an exploited vulnerability; incidents follow the same rhythm with slightly different content.

Stage	Deadline	Content
Early warning	24 hours after you become aware	The product concerned and, where applicable, the Member States where it has been made available. For incidents, also whether it's suspected to be caused by unlawful or malicious acts.
Notification	72 hours after you become aware	General information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures taken and those users can take, and how sensitive you consider the information.
Final report	14 days after a fix or mitigation is available (one month after the notification, for incidents)	Description including severity and impact, information about the malicious actor if available, and details of the security update or other corrective measures.

In practice the hardest field under time pressure is the exact affected versions. Teams without a product and version register spend most of the first day just establishing which firmware builds shipped to which markets.

A filing, step by step

Record the moment of awareness: when and how you learned of the exploitation or incident. Your 24 hours start here.
Confirm it's in scope: a vulnerability in your product with reliable evidence of exploitation by a malicious actor, or an incident that affects your product's security.
Pull the facts: product, model, affected versions, Member States, CVE if assigned, evidence of exploitation.
Log in to the SRP with EU Login and MFA, select the manufacturer you act for, and choose the coordinating CSIRT.
Submit the early warning, then save the confirmation and reference in your incident record.
Inform your users about the issue and the mitigations they can apply, and follow up with the 72-hour notification and final report against the same record.

When to register

ENISA's guidance has suggested registering when you first need to notify, while also allowing EU Login accounts to be created in advance. A sensible middle path: create and test EU Login with MFA for your filers now, document which CSIRT you'll choose, and keep your product register current, so that registering on the day takes minutes.

Common mistakes

Waiting for a full root-cause analysis before sending the early warning. The 24-hour report needs little; send it, then add detail at 72 hours.
Treating a public proof of concept as automatically "actively exploited". The test is reliable evidence of malicious exploitation. Decide with your counsel and document why.
Forgetting the user notification. Article 14(8) requires you to inform impacted users, and where appropriate all users, about the issue and how to mitigate it.
Only one person can log in.

We can file for you

With CRA On Call we're added as your secondary assigned representative, acknowledge reports within 4 hours 7 days a week, and draft and submit each report for you to approve.

See how it works

Sources: Regulation (EU) 2024/2847, Article 14; ENISA SRP documentation for assigned representatives (2026). Not legal advice.