How to file a CRA notification on ENISA's single reporting platform, from its own manual

Article 14(7) of the Cyber Resilience Act, Regulation (EU) 2024/2847, says that a manufacturer's notifications of an actively exploited vulnerability or a severe incident "shall be submitted via the single reporting platform referred to in Article 16". Not by email to a CSIRT, not through a national portal: via the platform. ENISA opened it on 11 September 2026, the day the duty started, at portal.cra-srp.enisa.europa.eu, and published a user manual, a glossary of every field, a set of guidance pages and 31 answers to frequently asked questions alongside it.

This article is those documents read end to end, for a manufacturer who has never seen the platform and will meet it at hour one of an incident. Everything below comes from ENISA's own pages as they stood on 12 September 2026, or from the Regulation. Where the platform does something the Regulation does not, it says so.

What the platform is, and what it is not yet

ENISA's platform is the one Article 16(1) told it to build: "a single reporting platform shall be established by ENISA. The day-to-day operations of that single reporting platform shall be managed and maintained by ENISA." Its point is that you file once. The notification is made available to ENISA and to the CSIRT designated as coordinator you selected, and that CSIRT disseminates it onward to the coordinators of the other member states where you said the product is available, and to its market surveillance authority. Sharing is their job, not yours.

Four limits at launch, each stated in ENISA's FAQ:

• It takes mandatory Article 14 notifications only. Voluntary reporting under Article 15, by manufacturers or anyone else, is not available at launch. The obligations of open-source software stewards under Article 24(3) apply from 11 December 2027, and the platform will take those then.
• It is in English only. More languages are to be reviewed in a later phase; the factsheet is being translated, the platform is not.
• There is no API. ENISA's words: no application programming interface is provided at the initial release, so notifications must be submitted through the platform interface. A manufacturer with many products submits each one by hand.
• One notification per vulnerability or incident, for the whole group. However many EU subsidiaries a manufacturer has, and wherever its parent sits, the FAQ says one notification is required and that coordinating internally so that exactly one is filed is the manufacturer's responsibility.

Who logs in: the assigned representatives

The platform does not know companies. It knows people, called assigned representatives, who act for a manufacturer. Each one needs a personal EU Login account with multi-factor authentication switched on; the FAQ says the account can be created in advance, that no corporate authentication mechanism is used, and that because EU Login accounts are personal, the person who reports uses their own.

There are two roles. The Primary AR registers directly: opens the platform, selects the role, selects the CSIRT designated as coordinator from a drop-down, authenticates through EU Login, accepts the legal agreement, confirms the name and email EU Login supplies, and enters the manufacturer's name. That creates the manufacturer in the platform and submits the association between person and manufacturer to the coordinator for validation. There is one Primary AR per manufacturer. A Secondary AR joins by email invitation from a Primary AR whose association has already been validated and shows as Verified; the invitation link expires after 7 days. Up to 20 Secondary ARs can exist per manufacturer. A Secondary AR can submit and update notifications but sees only the ones they submitted themselves; the Primary AR sees everything filed for the manufacturer, manages the association and invites or removes the others. A Secondary AR can claim the Primary role, subject to the coordinator's approval.

Two things about validation matter at hour one. First, it does not block you: the coordinator validates the association after registration and in parallel with reporting, and an unverified representative can submit up to 20 notifications before verification becomes mandatory. Second, ENISA asks you not to do it early. Its guidance says manufacturers "are advised to register and initiate the validation process only when they need to submit a specific notification, rather than registering pre-emptively", to keep the coordinators' validation workload down, and adds that with an EU Login already in place registration takes a few minutes. So the preparation is the EU Login with MFA, for the reporter and a deputy; the registration is a task for the day.

The terms and conditions, version 1.0 of 10 September 2026, add the part your legal team will want to see: by registering or submitting, users "represent and guarantee that they are the Assigned Representative(s) of their organisation and are authorized to act on its behalf", and the coordinator may verify that. Put the authorisation in writing before the day it is needed.

Which coordinator to pick

The drop-down at registration, and the field on every notification, is the CSIRT designated as coordinator of the member state where the manufacturer has its main establishment in the Union, which Article 14(7) defines as the state "where the decisions related to the cybersecurity of its products with digital elements are predominantly taken", or, if that cannot be determined, the state with the most employees; and where there is no main establishment in the Union, the authorised representative's state, then the importer's, the distributor's, and the state with the most users. ENISA's FAQ repeats the whole cascade and adds a consequence the Regulation does not spell out: "if the wrong CDaC is selected, the notification may be invalidated and will need to be resubmitted to the correct CDaC". A red alert on the dashboard is how you find out.

ENISA published the list of coordinators on 10 September 2026, and in two states it is not the national CSIRT. The list, and the two exceptions, are in a separate article; the table is also on the reporting deadlines page.

The three submissions, and what each one asks for

Article 14 requires three submissions: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report. On the platform they are three tabs on one notification record. You open a new notification for the early warning, then return to the same record for the 72-hour notification and again for the final report; each later stage is pre-filled with what you entered before, and the glossary marks each field as required, optional, or carried forward from the previous stage. The table below is the glossary's requirement column, per stage. Fields that apply to only one type are marked AEV for an actively exploited vulnerability and SI for a severe incident.

That is the Regulation's own structure with field boundaries drawn on it. Article 14(2)(a) asks the early warning to indicate "where applicable, the Member States on the territory of which the manufacturer is aware that their product with digital elements has been made available"; that is the member-state field, required from the first minute. Article 14(2)(b) asks the 72-hour notification for general information on the product, the general nature of the exploit and the vulnerability, the corrective or mitigating measures taken and those users can take, and how sensitive the manufacturer considers the information; those are the fields that flip from optional to required at the second stage. Article 14(2)(c) asks the final report for the severity and impact, the actor where available, and the security update or corrective measure; the third column.

Two practical constraints from the glossary: a title takes 255 characters and a summary 4,000, and every timestamp is entered in UTC. The glossary also asks that you not put confidential technical detail in the title, and that if the awareness time is an estimate you say so in the description. One footnote is worth knowing before you look for a field that is not there: for a vulnerability, the glossary marks the awareness date as required and then says the field "will be available in the next release of the Platform"; for an incident it exists today under the name "date and time when the incident was detected".

The counter the platform gets wrong, by its own account

The dashboard shows counters for the 72-hour notification and the final report, with reminder emails and overdue alerts driven by them. FAQ 26 says how they are calculated, and it is worth reading twice. The 72-hour counter "displays a due date/time 48hrs after submission of the 24-hour Early Warning", not 72 hours after you became aware. If you filed the early warning at hour four, the platform will show the notification due at hour 52, and "in some cases, a notification may be displayed as overdue before 72 hours have elapsed since the manufacturer or open-source software steward became aware of the event". ENISA says the logic will be changed in a future release to use the awareness field. Until then the platform's clock is not the Regulation's clock, and the FAQ says the counters "do not replace the responsibility of manufacturers" to meet Article 14's own deadlines.

For the final report there are two counters and one is missing on purpose. For a severe incident the platform counts one month from the submission of the 72-hour notification, which is Article 14(4)(c). For an actively exploited vulnerability there is no counter, because Article 14(2)(c) runs 14 days from a corrective or mitigating measure becoming available, and the platform cannot know that date until you enter it. That is the same distinction most write-ups of the CRA deadlines miss, and it is the reason the calculator on our deadlines page asks for the fix date separately.

After you press submit

Saving a draft keeps it visible to you alone. Submitting the early warning stores it, makes it accessible to the coordinator and to ENISA, and sends an email and an alert to the coordinator, to ENISA, and to every representative of the manufacturer. The coordinators of the other member states you named receive nothing automatically: ENISA's guidance says concerned CSIRTs "will receive the Early Warning only after manual dissemination by the CSIRT Designated as Coordinator". The same is true of the 72-hour notification and the final report.

You can update a notification at any stage until the final report is submitted; the platform then makes it non-editable, and a notification the coordinator has closed cannot be updated either. An update alerts the coordinator, ENISA and any CSIRT that already received the notification. Alerts on the dashboard are blue when unread; red ones "appear only when an exceptional or critical action has occurred", ENISA's example being that the coordinator has invalidated a submission.

Asking for dissemination to be delayed

Article 16(2) says the coordinator "shall, without delay, disseminate the notification" to the coordinators of the member states where the product is available, and then carves out two exceptions. In exceptional circumstances, "in particular, upon request by the manufacturer and in light of the level of sensitivity of the notified information", the coordinator may delay dissemination on justified cybersecurity-related grounds for the period strictly necessary. And in "particularly exceptional circumstances", where the manufacturer indicates in the 72-hour notification one of three things, only the fact of the notification, the general information about the product, the general nature of the exploit and the fact that grounds were raised go to ENISA until the full notification is disseminated. The three, verbatim:

(a) that the notified vulnerability has been actively exploited by a malicious actor and, according to the information available, it has been exploited in no other Member State than the one of the CSIRT designated as coordinator to which the manufacturer has notified the vulnerability; (b) that any immediate further dissemination of the notified vulnerability would likely result in the supply of information the disclosure of which would be contrary to the essential interests of that Member State; or (c) that the notified vulnerability poses an imminent high cybersecurity risk stemming from the further dissemination;

On the platform this is a toggle, and it is available in exactly one place: the 72-hour notification of an actively exploited vulnerability. Switching it on reveals a "PEC delay reason" with the three grounds as check boxes and an optional 800-character justification "that can help the CSIRT Designated as Coordinator decide". The dissemination state becomes "72h Submitted under PEC", ENISA receives only the limited information, and the decision on whether and when to disseminate is the coordinator's, not the manufacturer's. A toggle is a request.

What the coordinator may do with that request is now set out in Commission Delegated Regulation (EU) 2026/881 of 11 December 2025, published in the Official Journal on 20 April 2026. Article 3 lets the coordinator delay dissemination only where the cybersecurity risks of disseminating outweigh its benefits, those risks cannot be handled by restrictions such as the Traffic Light Protocol, and one of four conditions holds: the manufacturer has said an effective mitigation is expected within 72 hours, in which case the delay ends if it does not arrive; the notification contains enough to build an exploit, "particularly when the vulnerability can be easily identified and exploited by actors with limited skills and resources"; the coordinator can share enough for the other CSIRTs to mitigate without the full notification; or the coordinator learned of the vulnerability as trusted intermediary in a coordinated disclosure. In the second and third cases the full notification goes out once a mitigation is available. Articles 4 and 5 add grounds that are about the recipients, not the manufacturer: a CSIRT, or the platform itself, that has suffered an incident casting doubt on its ability to keep the notification confidential.

So the honest description of the toggle is this: if you have a patch coming within three days, or the details would hand a low-skill attacker a working exploit, say so, tick the ground that fits, and give the coordinator the facts in the 800 characters. Then plan as if dissemination happens anyway.

If the platform is down

FAQ 25: if the platform is temporarily unavailable, wait until it is back and submit then. If you consider immediate communication necessary in the meantime, you may contact your coordinator directly, but "the notification must still be submitted through the SRP once it is available again". Some coordinators have published a fallback: Ireland's NCSC gives an emergency email address for the case where ENISA has declared the platform offline, and says submissions to it are accepted only then. Article 17(6) obliges every coordinator to provide helpdesk support on Article 14, "in particular" to manufacturers that are micro, small or medium-sized; ENISA's own helpdesk is reachable by email from the FAQ page.

Five things the FAQ settles

1. No retrospective reporting. A manufacturer that was already aware of the active exploitation before 11 September 2026 is not required to report it now; awareness after that date triggers the duty even where the vulnerability itself was old or known.
2. Products already on the market are in scope. Article 14 applies from 11 September 2026 to every product with digital elements in scope of the Regulation, including products placed on the market before 11 December 2027.
3. Third-party components. For a vulnerability in a component you integrate, ENISA points to section 5.4 of the Commission's implementation FAQ and to paragraph 218 of the Commission's guidance of 27 July 2026, rather than answering in its own words. Read those before deciding you are not the one who has to report.
4. The notification does not raise your liability. Article 17(4): "the mere act of notification ... shall not subject the notifying natural or legal person to increased liability".
5. After the fix, the vulnerability becomes public. Article 17(5): once a security update or other corrective measure is available, ENISA adds the notified vulnerability to the European vulnerability database, in agreement with the manufacturer.

What to prepare before you need any of it

• EU Login accounts with multi-factor authentication for the person who reports and a deputy, created today, and a written authorisation for both.
• Your member state and coordinator, decided under Article 14(7) and written into the incident procedure, so that nobody chooses between drop-down entries at hour one.
• A product inventory with the exact version, build, model or firmware identifiers the version field asks for, and a list of the member states where each product is made available, because that field is required in the early warning.
• A convention for "became aware", and a rule that the timestamp is recorded in UTC the moment it is set.
• A one-page draft of the early-warning fields in a document you can paste from: title under 255 characters, summary under 4,000, the two dates, the member states.
• A name for who decides, inside the first 72 hours, whether to tick the exceptional-circumstances box, and on what facts.

The platform will not do any of this for you, and neither will this article. What it can do is make hour one a matter of typing rather than reading.

Sources

• ENISA, Single Reporting Platform pages: the main page, the FAQ (updated 11 September 2026), the guidance pages on user registration, notification submission and update, interface functions and particular exceptional circumstances (updated 9 and 10 September 2026), the SRP Glossary, the AR User Manual, and the Terms and Conditions v1.0 of 10 September 2026, all read on 12 September 2026.
• ENISA, List of CSIRTs Designated as Coordinators, last updated 10 September 2026.
• Regulation (EU) 2024/2847, Articles 14, 16 and 17, and Article 71(2).
• Commission Delegated Regulation (EU) 2026/881 of 11 December 2025, Articles 3 to 5, OJ L of 20 April 2026.
• European Commission, guidance C(2026) 5252 of 27 July 2026, and the FAQs on the CRA implementation, section 5.
• NCSC Ireland, Cyber Resilience Act reporting obligations page, updated 11 September 2026.

This is not legal advice. The glossary is a table of 39 fields and the FAQ is 31 questions; both are short enough to read before you need them.