ENISA's Single Reporting Platform went live on 11 September and asks manufacturers not to register until they have something to report. What the portal and Article 14(7) expect you to have settled before that day.
ENISA's Single Reporting Platform went live on 11 September and asks manufacturers not to register until they have something to report. What the portal and Article 14(7) expect you to have settled before that day.
On 11 September 2026, ENISA deployed "the initial operating capability" of the Single Reporting Platform, the portal through which manufacturers now file the reports the Cyber Resilience Act requires. The date comes from the regulation itself. Regulation (EU) 2024/2847 applies in full from 11 December 2027, but Art. 71(2) carves out one article:
"However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026."
Article 14 is the reporting article, and Art. 69(3) applies it "to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027." A product that has been on sale for years is in scope for reporting today, fifteen months before the regulation's main requirements apply.
Art. 14(1) and (3) set the mechanism. A manufacturer notifies an actively exploited vulnerability, or a severe incident affecting the security of its product, "simultaneously to the CSIRT designated as coordinator … and to ENISA", and does so through the platform. You submit once, both recipients get it, and the coordinating CSIRT passes it on to the CSIRTs of the other Member States where the product has been made available.
An earlier post covered when the reporting clock starts. The other half of the problem is where the report goes, who may send it, and what the portal does once the clock is running.
ENISA's FAQ, updated on 17 September, is plain about registration:
"To limit the validation workload for designated CSIRTs, manufacturers and, once applicable, open-source software stewards are advised to register and initiate the validation process only when they need to submit a notification."
The registration guidance repeats it: register "only when they need to submit a specific notification, rather than registering pre-emptively." The reason is in the quote: every registration is a validation job for a CSIRT, and pre-emptive ones would be jobs for reports that may never come.
Waiting costs little at the moment of submission. Validation runs in parallel and does not block reporting, an AR whose association is still unverified "may submit up to 20 notifications for that manufacturer before verification becomes mandatory", and ENISA says registration "takes just a few minutes" for someone who already has an EU Login account. Where waiting does cost something is the account model. The platform works through Assigned Representatives (ARs):
EU Login accounts "are personal" and MFA is required, so there is no shared team login. "A Primary AR must first have a validated AR–manufacturer association, displayed as 'Verified', before inviting Secondary ARs", and an invitation not accepted within seven days expires. Read together, those rules mean that a manufacturer following ENISA's advice registers its first person while an incident is under way, and cannot add a deputy until a CSIRT has verified that person. Drafts don't help with a handover either: they are "stored locally in the individual AR's account and are therefore not visible to other ARs associated with the same manufacturer."
The BSI's page on the platform recommends, for the security-response roles behind these reports, that "reliable cover should be ensured by at least two people." Nothing in ENISA's advice stops you from deciding today who those two people are and creating their personal EU Login accounts with MFA, which ENISA explicitly allows "in advance". Registration can wait until there is something to report; choosing the two people can't, because the second one can only join after a CSIRT has verified the first.
Early in registration, the portal asks you to pick the coordinating CSIRT from a drop-down, with a note: "The manufacturer is responsible for identifying the correct CDaC in accordance with Article 14(7) of the CRA." FAQ 18 says what happens if you pick wrong: "the notification may be invalidated and will need to be resubmitted to the correct CDaC." The 24-hour clock does not pause while you resubmit.
Art. 14(7) gives the default. Notifications go to the CSIRT of the Member State "where the manufacturers have their main establishment in the Union", and main establishment means where "the decisions related to the cybersecurity of its products with digital elements are predominantly taken". If that cannot be determined, it falls back to the Member State with the most employees in the Union.
For a manufacturer based in Switzerland with no establishment in the Union, the third subparagraph applies instead. The CSIRT is the one in the first Member State that fits this order, "based on the information available to the manufacturer":
An authorised representative holds "a written mandate from a manufacturer" and is "established within the Union" (Art. 3(15)); appointing one is optional under Art. 18(1). A Swiss vendor with no authorised representative, importer or distributor in the Union lands on point (d), which is also the step that needs data you may not have: where your users are. Point (d) has one mercy: after reporting there once, a manufacturer "may submit notifications related to any subsequent actively exploited vulnerability or severe incident … to the same CSIRT".
Here is one case I can't settle from the text. Take a Swiss group with a sales subsidiary in Germany, where product-security decisions are made in Zurich. Is there a "main establishment in the Union"? The decision test points outside the Union; the employee test points to Germany. ENISA's FAQ 8 says only one notification is required even when "its parent company is headquartered outside the EU", but not which CSIRT receives it. If that is your structure, it is a question for counsel, better asked now than in hour 20.
Vulnerabilities and incidents share the first two steps and part ways at the third. From Art. 14(2) and (4):
| Step | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | within 24 hours of becoming aware; Member States where the product is available | within 24 hours; also "whether the incident is suspected of being caused by unlawful or malicious acts" |
| Notification | within 72 hours; general nature of the exploit and vulnerability, measures taken and measures users can take, how sensitive the information is | within 72 hours; nature of the incident, "an initial assessment", measures taken and measures users can take |
| Final report | "no later than 14 days after a corrective or mitigating measure is available" | "within one month after the submission of the incident notification" |
An incident counts as severe under Art. 14(5) if it affects, or could affect, the product's ability to protect "the availability, authenticity, integrity or confidentiality of sensitive or important data or functions", or if it has led or could lead to malicious code running in the product or in a user's systems. The coordinating CSIRT may also ask for an intermediate report (Art. 14(6)). The submission guidance adds that the notification can be updated until the final report goes in, and "becomes non‑editable" after that.
The reports are written in English. ENISA's FAQ 24 says the platform is available "in English only" at launch, and the BSI states it outright: "Reports must be written in English to enable efficient EU-wide coordination." For a team in Lausanne or Lugano, that is one more thing better prepared before an incident than during one.
The platform shows counters, and FAQ 26 describes how they work in the current release:
"the 72-hour counter displays a due date/time 48hrs after submission of the 24-hour Early Warning. As a result, 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 a future release will anchor the counter to the awareness timestamp instead. Until then, the arithmetic cuts both ways. If you file the early warning two hours after becoming aware, the counter shows the 72-hour notification due at hour 50, earlier than the law requires. If you file it at hour 23, the counter shows hour 71, which happens to be close. The counter is anchored to your submission; the regulation is anchored to your awareness.
For vulnerabilities there is no final-report counter at all, "as the Final Report deadline depends on the date and time when a corrective or mitigating measure becomes available." That date lives in your release process, not in the portal. ENISA says it directly: the counters "do not replace the responsibility of manufacturers … to comply with the obligations laid down in CRA".
The two dates that decide your deadlines, when you became aware and when the fix became available, have to be recorded somewhere you control. The portal will not reconstruct either.
FAQ 25 covers an outage: wait for the platform to come back and then submit. If you "consider that immediate communication is necessary", you can contact the designated CSIRT directly, but "the notification must still be submitted through the SRP once it is available again". Knowing which CSIRT that is, and how to reach it, is the same Art. 14(7) question again.
There is no API: FAQ 15 says "notifications must be submitted through the platform interface", so internal tooling can prepare the text, and a person with an EU Login still enters it. Voluntary reporting under Art. 15 "will be introduced in a future phase". Informing users is a separate duty under Art. 14(8), "where appropriate in a structured, machine-readable format", and filing with the CSIRT does not discharge it.
NIS2 is a separate channel as well. In the BSI's reading for Germany, a severe incident can fall under both regimes, and "the incident must be reported both under NIS-2 (via the BSI portal) and under the CRA (via the CRA-SRP)." The BSI adds that the Commission's Digital Omnibus proposal would let a CRA report count for NIS2 "if the provision is adopted in this form"; for now it is a proposal.
One Swiss date to keep in view: in August 2025 the Federal Council tasked the BACS, with BAKOM and SECO, to prepare a consultation draft on cyber-resilience legislation for digital products "bis Herbst 2026". Whatever it proposes, Art. 14 already applies to in-scope products you have placed on the EU market.
ENISA asked manufacturers not to register yet, and there is no reason to argue with that. What it leaves is short enough to fit on a page: the coordinating CSIRT under Art. 14(7), with the reasoning behind the choice; the two named people who will act as Primary and Secondary AR, each with a personal EU Login and MFA; where the awareness timestamp and the fix date get recorded; and the English text of what your product is, so the early warning doesn't start from a blank field. If you haven't yet decided what "becoming aware" means for your team, the earlier post is the place to start.
devguard keeps the incident register a report like this starts from, with its timestamps and a named owner: devguard.ch/platform.
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.