Uafhængig vejledning til forordning (EU) 2024/2847 · Status: i kraft
Denne side er en automatisk (AI-)oversættelse og er ikke blevet gennemgået af en person. Blogartikler er kun tilgængelige på engelsk.
← All news
CRA Insights24 August 2026Opdateret 11. september 2026

Eighteen Days to CRA Reporting: What You Can Prepare Before the Platform Opens on 11 September 2026

Eighteen Days to CRA Reporting: What You Can Prepare Before the Platform Opens on 11 September 2026

On 11. september 2026, Article 14 of the Cyber Resilience Act starts to apply and manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's den fælles indberetningsplatform. That was eighteen days away when this piece first ran. The platform opened on the day, and the duty is now running. Almost every decision that makes a first report go smoothly is still a decision you take away from the platform, which is why the checklist below outlived the countdown that produced it.

Updated 11 September 2026

Reporting has started and the platform is open, so this is a checklist against a live duty rather than a countdown. Three things changed after publication and are corrected below. The liste over CSIRTs udpeget som koordinatorer appeared on 4. september 2026, so step 3 can now be finished. The mandatory fields at 24 hours grew when ENISA rewrote its FAQ the same day, so step 4 was incomplete. And the platform carries a deadline counter that does not track the legal deadline, covered in step 7, a defect that went live with it.

Status at 11 September 2026

Platformen er live. ENISA publishes it at portal.cra-srp.enisa.europa.eu, where you select the Assigned Representative role and sign in through EU Login with multi-factor authentication enabled. The address was published in ENISA's FAQ on 10. september 2026, the day before opening, alongside an AR User Manual and platform terms and conditions. Three things are confirmed absent: frivillig indberetning under Article 15, a reporting API, and the field that records when you became aware of an actively exploited vulnerability. The steps below are no longer preparation for a future date, because the duty is running now.

1. Create the EU Login accounts today

Registration runs through EU Login, and ENISA says the account can be created in advance. Nothing about it involves a CSIRT, a queue or an approval, so nobody who might file should be creating one during an incident. Do it for the primary filer and at least one deputy. Accounts are personal and multi-factor authentication is required.

Platform registration itself is a different matter. ENISA advises manufacturers to register on the SRP and start validation only when they have a specific notification to submit, so as not to overload the national teams before launch. Both things can be true: create the EU Login now, leave the SRP account until you need it.

2. Settle your product classification in advance

The notification form asks for the product type, meaning default, important or critical, and, where the product is not default, the Bilag III or Bilag IV category. That answer is informed by Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025, which describes the core functionality of each category. It is not a question to work through with an exploited vulnerability in front of you. Our klassificeringsværktøj og den overensstemmelsesmatrix will get you to a defensible answer in a short sitting, and the result belongs in your incident runbook, not in someone's memory.

3. Work out which CSIRT is yours

Reports route to the CSIRT udpeget som koordinator in the Member State of your main establishment, and Article 14(7) sets out how to determine that. ENISA published the list of designated coordinators on 4. september 2026, giving contact points for all 27 Member States, so this step can now be finished rather than parked.

The list tells you who each Member State's coordinator is, not which one is yours. That test is narrower than most organisations assume: your main establishment is where decisions about your products' cybersecurity are overvejende træffes, which may be a development site rather than a registered office. Our indberetningsvejledning sets out the fallbacks. Because this fixes the recipient for every future filing, write down the reasoning as well as the answer.

4. Draft the wording before you need it

The mandatory set at the 24-hour early warning is still short, but it is longer than it was. ENISA's rewritten FAQ of 4. september 2026 requires notification type and level, a title, a summary, the manufacturer name, the product name og product version, the date and time you became aware, and for incidents whether unlawful or malicious acts are suspected. The Member States where the product is available are required where you already know them. The substance still arrives at 72 timer, and the full description, severity and impact in the final report.

Summary and product version are the additions worth noting. The early warning is still an alert rather than an investigation, but it now expects a few lines on what happened and exactly which build is affected.

Two details from ENISA's guidance shape where that drafting should live. Drafts saved in the platform are visible only to the representative who created them, so a colleague picking up a handover will not see them. And there is no API at this stage, so every notification is typed in by a person. Keep skeleton wording for each stage in a document your incident team already shares, and use the platform to transcribe rather than to compose. Our indberetningsvejledning sets out what each stage has to contain.

5. Decide who is on the clock

A 24-hour deadline running from the moment the organisation becomes aware is, in practice, a staffing question. The platform provides a primary representative and a backup who joins by email invitation. Decide now who holds each seat, who covers holidays and weekends, and how an engineer who spots active exploitation on a Saturday reaches that person. Our support planner is a good place to record it.

6. Know which clocks run, and do not trust the platform's countdown

This is frequently muddled. The 24-hour og 72 timer windows run from awareness, and nothing pauses them. What can be delayed is dissemination: the receiving CSIRT may hold a notification back from other Member States on the grounds specified in Commission Delegated Regulation (EU) 2026/881, adopted on 11 December 2025. A manufacturer may separately flag the narrow conditions in artikel 16, stk. 2 in its 72-hour notification, which limits what ENISA sees until the coordinating CSIRT releases the full text. That restricts content, not timing. The final report has its own clock: for a vulnerability, no later than 14 dage after a corrective measure is available; for a severe incident, within en måned of the 72-hour notification.

The platform itself does not help you here, which was not public when this first ran. ENISA's FAQ of 4. september 2026 explains that its 72-timers tælleren shows a due date 48 timer efter at 24-timers rapporten er indsendt, not 72 hours after awareness, so a notification can display as forsinket before the legal deadline has run. ENISA says the counters do not replace the duty in Article 14.

There is a second layer. ENISA's SRP-ordliste, revised to version 1.1 on 5. september 2026, notes that the field recording when you became aware of an actively exploited vulnerability arrives only in a later release, and that for a severe incident the current field records when the incident was detected. Detection normally precedes awareness, which the Commission's guidance of 27 July 2026 ties to an initial assessment reaching reasonable certainty. The platform will therefore not hold the moment Article 14 measures from, so keep your own timestamped note of when that assessment concluded and who made the call.

Also new: if the platform is unavailable, ENISA says to wait and submit once it is back, contacting your designated CSIRT directly if immediate communication is necessary. Nothing in the CRA pauses your deadlines during an outage, so timestamp that too.

Where this leaves you

None of the six items above needs the platform, a URL or an announcement. They need an afternoon. The companies that will find their first Article 14 report uneventful are the ones that spent that afternoon in advance, so that the only unfamiliar thing on the day is the login screen. If you have not spent it yet, the deadline is no longer approaching, it is running. Our state of play page tracks what is still outstanding.

Published 24 August 2026, opdateret 11. september 2026 · CRA Insights. Part of the CRA insights blog on cyberresilienceact.eu.