Reporting on ENISA's Single Reporting Platform

This page is about the plumbing rather than the deadlines. If you need the clocks — the 24 hours, the 72 hours, and the two different final reports — those are in the reporting deadlines. This is what the thing you report into actually is.

What Article 16 establishes

Article 16(1) is the legal basis, and it is short:

For the purposes of the notifications referred to in Article 14(1) and (3) and Article 15(1) and (2) and in order to simplify the reporting obligations of manufacturers, 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. The architecture of the single reporting platform shall allow Member States and ENISA to put in place their own electronic notification end-points.

Note what Article 16 does not contain: any obligation on a manufacturer. Every duty in its six paragraphs falls on ENISA, on the CSIRTs designated as coordinators, or on market surveillance authorities. Your duty is in Article 14. Article 16 is the machinery Article 14 points at.

There is also a curiosity in the commencement dates that nobody has explained. Article 71(2) applies Article 14 from 11 September 2026 but leaves Article 16 — the article that establishes the platform — to apply from 11 December 2027, with the rest of the Regulation. ENISA has nonetheless built and launched the platform, citing Article 16(1) as its basis. It makes practical sense that the duty to build must precede the date of use; we have not found a source that says so, and we are not going to invent one.

What is live, and what is missing

ENISA's announcement used a specific phrase: it has deployed the initial operating capability of the platform, and will continue to improve and expand its functionalities over the coming months. Both halves of that matter.

The absence of an API is the single most consequential fact on this page, and it is worth being blunt about what follows from it, including for anyone selling you software. The act of submitting cannot be automated. Not by you, not by us, not by anyone. A tool's usefulness has to sit on the near side of the portal: knowing which CSIRT, having the account, drafting the content against the deadline, and keeping the record afterwards. Any vendor who implies they will file for you is describing something that does not currently exist.

Registering, and why it has to be done now

ENISA's guidance describes a registration flow along these lines: open the platform, choose the role of the person who will submit notifications, select your CSIRT designated as coordinator from a list, authenticate with EU Login, accept the legal terms, confirm your personal details, and enter your manufacturer details. A backup submitter can then be added by invitation and goes through the same authentication.

Three things to take from that.

• EU Login with multi-factor authentication is a prerequisite. If nobody at your company has an EU Login account, that is the first task, and it is not a five-minute one under pressure.
• You must already know which CSIRT is yours, because you pick it from a list at registration. That determination is not your registered address — see which CSIRT you report to, because Article 14(7) keys it to where your cybersecurity decisions are predominantly taken.
• Register a second person. A 24-hour deadline and one named individual with an authenticator app is a single point of failure, and incidents do not wait for someone to come back from leave.

One clarification that is useful and is easy to get wrong in both directions: no article of the CRA requires you to register anywhere. Article 14 requires the notification; Article 16 imposes nothing on manufacturers. The registration, the EU Login account and the multi-factor requirement are ENISA's platform preconditions. That distinction matters legally and changes nothing practically — the platform is how the notification is submitted, so the account has to exist.

Where your notification goes

Article 14(7) decides the destination, and Article 16(2) decides what happens next.

You submit to the endpoint of the CSIRT designated as coordinator of the Member State where you have your main establishment in the Union, and the notification is simultaneously accessible to ENISA. The receiving CSIRT then, under Article 16(2), disseminates it via the platform to the CSIRTs designated as coordinators in the territories where you have indicated the product was made available.

So the platform does the fan-out. You file once; you do not notify each Member State where you sell. That is what Article 16(1) means by “in order to simplify the reporting obligations of manufacturers”, and it is a genuine simplification.

Article 16(3) then requires the coordinating CSIRTs to pass to their own market surveillance authorities the information those authorities need to do their job under the Regulation. Worth knowing: a report you make for cybersecurity purposes reaches the authority that enforces the Regulation against you. That is not a reason to report late. It is a reason for the notification to be written carefully, and for the internal record of what you said and when to be kept.

The misconception worth correcting

It is widely said that a manufacturer can, on cybersecurity grounds, report only to its national CSIRT and keep ENISA out. That is not what the Regulation says, and this is the single most commonly misstated point about CRA reporting.

What Article 16(2) actually provides, in its second subparagraph, is that in exceptional circumstances and in particular upon request by the manufacturer, and in light of the sensitivity of the notified information as the manufacturer has indicated it, the dissemination of the notification may be delayed on justified cybersecurity-related grounds for a period strictly necessary. Where the CSIRT decides to withhold a notification it must immediately inform ENISA of the decision, with a justification and an indication of when it will disseminate.

Three corrections follow:

1. The decision is the CSIRT's, not yours. You can ask, and you can flag sensitivity. You cannot decide.
2. What is delayed is dissemination to the other CSIRTs, not your obligation to submit.
3. ENISA is told either way. Even in the narrowest case — the third subparagraph of Article 16(2), which requires the manufacturer to have indicated that the vulnerability is being actively exploited in no other Member State, or that further dissemination would be contrary to that Member State's essential interests, or that dissemination poses an imminent high cybersecurity risk — ENISA still receives, simultaneously, the fact that a notification was made, general information about the product, the general nature of the exploit, and the fact that security grounds were raised. And if ENISA considers there is a systemic risk to the internal market on the basis of that information, it may recommend that the CSIRT disseminate the full notification anyway.

A separate delay ground sits in Article 16(6): where the coordinating CSIRT has been made aware that the vulnerability is subject to a coordinated vulnerability disclosure procedure under Article 12(1) of Directive (EU) 2022/2555, it may delay dissemination for no longer than strictly necessary and until the parties to that procedure consent to disclosure. Again: the CSIRT's decision, after you have reported. Your coordinated vulnerability disclosure policy does not buy you time against Article 14.

There is a delegated act on these grounds — Commission Delegated Regulation (EU) 2026/881, adopted on 11 December 2025 and published in the Official Journal in April 2026, which specifies the terms and conditions for applying the cybersecurity-related grounds for delaying dissemination. Note what it governs: the CSIRT's delay decision. It does not give a manufacturer a right to withhold.

Two different things called “AR”

A genuine trap, and one we have not seen flagged anywhere else.

• In the Regulation, an authorised representative is a natural or legal person established in the Union with a written mandate from a manufacturer to act on its behalf for specified tasks. It is a legal appointment, and under Article 14(7) it is also the first step of the cascade that decides your CSIRT when you have no main establishment in the Union.
• On ENISA's platform, the role is described as an “Assigned Representative” — the individual person who submits notifications, holding an EU Login account.

Same abbreviation, different concepts: one is a mandated legal person, the other is a named human with a login. We have found nothing from ENISA stating whether a CRA authorised representative must be the party who registers, or how the two map onto each other. So we will not tell you they are the same and we will not tell you they are different — only that if you are a non-EU manufacturer with an appointed authorised representative, this is a question worth resolving explicitly rather than by assumption.

The format is not prescribed by law — yet

Article 14(10) provides that the Commission may, by implementing acts, specify further the format and procedures of the notifications referred to in Articles 14, 15 and 16. “May”, and no deadline.

No such implementing act appears on the Commission's published implementation pages. So today the format is set by ENISA's own form — its field set, its naming, its structure — as a matter of practice rather than law.

Two implications worth holding onto. First, if that implementing act is ever adopted, it will change a form manufacturers are by then used to. Second, Article 14(10) reaches “procedures” as well as format, which makes it the one route by which platform registration could become an actual legal requirement rather than an operational one. Worth watching for both reasons.

The pre-incident checklist

Everything above reduces to a short list of things that must be true before anything goes wrong. None of it is difficult; all of it is impossible to do in an hour.

1. An EU Login account with multi-factor authentication, for at least two people.
2. Both registered on the platform, primary and backup.
3. Your coordinating CSIRT determined and written down, with the reasoning — Article 14(7) keys it to where cybersecurity decisions are predominantly taken, and the determination is expressly made “based on the information available to the manufacturer”, so the reasoning is the defensible artefact, not the verdict.
4. Your manufacturer details as the form asks for them.
5. A triage step that asks whether a vulnerability is being actively exploited, wired to escalate immediately rather than into the normal queue. This is how the 24-hour deadline is actually met or missed.
6. A record of what you filed and when. The platform is not your archive, and under Article 16(3) your notification reaches your market surveillance authority.
7. A plan for informing users, because Article 14(8) is a separate duty to tell impacted users about the vulnerability or incident and any mitigations — where appropriate in a structured, machine-readable format — and if you do not do it in a timely manner, the notified CSIRTs may do it for you.