Artikel 14(7) i Cyber Resilience Act, forordning (EU) 2024/2847, siger, at en fabrikants anmeldelser af en aktivt udnyttet sårbarhed eller en alvorlig hændelse "indgives via den fælles anmeldelsesplatform, der er omhandlet i artikel 16". Ikke pr. e-mail til et CSIRT, ikke gennem en national portal: via platformen. ENISA åbnede den den 11. september 2026, den dag pligten begyndte, på portal.cra-srp.enisa.europa.eu, og udgav ved siden af en brugermanual, en ordliste over hvert felt, en række vejledningssider og 31 svar på ofte stillede spørgsmål.
Denne artikel er de dokumenter læst fra ende til anden, for en fabrikant, der aldrig har set platformen og vil møde den i time et af en hændelse. Alt nedenfor stammer fra ENISA's egne sider, som de så ud den 12. september 2026, eller fra forordningen. Hvor platformen gør noget, forordningen ikke gør, står det der.
Hvad platformen er, og hvad den endnu ikke er
ENISA's platform er den, artikel 16(1) pålagde den at bygge: "ENISA opretter en fælles anmeldelsesplatform. Den daglige drift af denne fælles anmeldelsesplatform forvaltes og vedligeholdes af ENISA." Pointen er, at I indgiver én gang. Anmeldelsen stilles til rådighed for ENISA og for det CSIRT udpeget som koordinator, I har valgt, og det CSIRT videregiver den til koordinatorerne i de andre medlemsstater, hvor I har angivet, at produktet er tilgængeligt, og til sin markedsovervågningsmyndighed. Videregivelsen er deres arbejde, ikke jeres.
Fire grænser ved starten, hver nævnt i ENISA's FAQ:
- Den tager kun obligatoriske anmeldelser efter artikel 14. Frivillig anmeldelse efter artikel 15, fra fabrikanter eller andre, er ikke tilgængelig ved starten. Forpligtelserne for forvaltere af open source-software efter artikel 24(3) gælder fra den 11. december 2027, og platformen tager dem til den tid.
- Den findes kun på engelsk. Flere sprog skal vurderes i en senere fase; faktaarket oversættes, platformen gør ikke.
- Der er ingen API. Med ENISA's ord: Der leveres ingen programmeringsgrænseflade i den første udgave, så anmeldelser skal indgives gennem platformens brugerflade. En fabrikant med mange produkter indgiver hver enkelt i hånden.
- Én anmeldelse pr. sårbarhed eller hændelse, for hele koncernen. Uanset hvor mange EU-datterselskaber en fabrikant har, og hvor moderselskabet ligger, siger FAQ'en, at der kræves én anmeldelse, og at den interne koordinering, så præcis én indgives, er fabrikantens ansvar.
Hvem logger ind: de udpegede repræsentanter
Platformen kender ikke virksomheder. Den kender personer, kaldet udpegede repræsentanter, som handler for en fabrikant. Hver af dem har brug for en personlig EU Login-konto med multifaktorgodkendelse slået til; FAQ'en siger, at kontoen kan oprettes på forhånd, at der ikke bruges nogen virksomhedsgodkendelse, og at fordi EU Login-konti er personlige, bruger den, der anmelder, sin egen.
Der er to roller. Primary AR registrerer sig direkte: åbner platformen, vælger rollen, vælger det CSIRT udpeget som koordinator i en rullemenu, logger ind via EU Login, accepterer den juridiske aftale, bekræfter det navn og den e-mail, EU Login leverer, og indtaster fabrikantens navn. Det opretter fabrikanten på platformen og sender tilknytningen mellem person og fabrikant til koordinatoren til validering. Der er én Primary AR pr. fabrikant. En Secondary AR kommer med via en e-mailinvitation fra en Primary AR, hvis tilknytning allerede er valideret og vises som Verified; invitationslinket udløber efter 7 dage. Der kan være op til 20 Secondary AR'er pr. fabrikant. En Secondary AR kan indgive og opdatere anmeldelser, men ser kun dem, vedkommende selv har indgivet; Primary AR ser alt, der er indgivet for fabrikanten, forvalter tilknytningen og inviterer eller fjerner de andre. En Secondary AR kan gøre krav på Primary-rollen, med forbehold for koordinatorens godkendelse.
To ting om validering tæller i time et. For det første blokerer den jer ikke: Koordinatoren validerer tilknytningen efter registreringen og parallelt med anmeldelsen, og en ikke-verificeret repræsentant kan indgive op til 20 anmeldelser, før verificering bliver obligatorisk. For det andet beder ENISA jer om ikke at gøre det tidligt. Vejledningen siger, at fabrikanter "rådes til først at registrere sig og sætte valideringsprocessen i gang, når de skal indgive en konkret anmeldelse, frem for at registrere sig på forhånd", for at holde koordinatorernes valideringsbyrde nede, og tilføjer, at med et EU Login på plads tager registreringen få minutter. Forberedelsen er altså EU Login med MFA, for den, der anmelder, og en stedfortræder; registreringen er en opgave til selve dagen.
Vilkårene, version 1.0 af 10. september 2026, tilføjer den del, jeres juridiske afdeling vil se: Ved at registrere sig eller indgive "erklærer og garanterer" brugerne, "at de er deres organisations udpegede repræsentant(er) og er bemyndiget til at handle på dens vegne", og koordinatoren må efterprøve det. Skriv bemyndigelsen ned, før den dag kommer, hvor den skal bruges.
Hvilken koordinator I vælger
Rullemenuen ved registreringen, og feltet i hver anmeldelse, er det CSIRT udpeget som koordinator i den medlemsstat, hvor fabrikanten har sit hovedforretningssted i Unionen, som artikel 14(7) definerer som den stat, "hvor beslutningerne vedrørende cybersikkerheden i dens produkter med digitale elementer overvejende træffes", eller, hvis det ikke kan afgøres, staten med flest ansatte; og uden hovedforretningssted i Unionen den bemyndigede repræsentants stat, dernæst importørens, distributørens og staten med flest brugere. ENISA's FAQ gentager hele kaskaden og tilføjer en følge, forordningen ikke udtaler: "Hvis den forkerte CDaC vælges, kan anmeldelsen blive erklæret ugyldig og skal indgives igen til den rigtige CDaC." En rød advarsel på dashboardet er den måde, I finder ud af det på.
ENISA offentliggjorde listen over koordinatorer den 10. september 2026, og i to stater er det ikke det nationale CSIRT. Listen, og de to undtagelser, står i en selvstændig artikel; tabellen står også på siden med anmeldelsesfrister.
De tre indgivelser, og hvad hver spørger om
Artikel 14 kræver tre indgivelser: en tidlig varsling inden 24 timer efter kendskab, en anmeldelse inden 72 timer og en endelig rapport. På platformen er det tre faner på én anmeldelsespost. I opretter en ny anmeldelse til den tidlige varsling, vender så tilbage til den samme post til 72-timersanmeldelsen og igen til den endelige rapport; hvert senere trin er forudfyldt med det, I indtastede før, og ordlisten markerer hvert felt som påkrævet, valgfrit eller overført fra det forrige trin. Tabellen nedenfor er ordlistens kravkolonne, pr. trin. Felter, der kun gælder for én type, er markeret AEV for en aktivt udnyttet sårbarhed og SI for en alvorlig hændelse.
| Felt | Tidlig varsling | 72-timersanmeldelse | Endelig rapport |
|---|---|---|---|
| Anmeldelsestype: sårbarhed eller hændelse | Påkrævet | Overført | Overført |
| Titel og resumé | Påkrævet | Overført | Overført |
| Medlemsstater, hvor produktet er tilgængeligt | Påkrævet | Overført | Overført |
| Produktnavn og version | Påkrævet | Overført | Overført |
| Dato og klokkeslæt for kendskab, i UTC | Påkrævet | Overført | Overført |
| SI: dato og klokkeslæt for hændelsen | Valgfrit | Påkrævet | Valgfrit |
| SI: om der er mistanke om ulovlige eller ondsindede handlinger | Påkrævet | Overført | Overført |
| Produkttype, klasse og bilagskategori; komponent; ophør af support | Valgfrit | Overført | Overført |
| Om en afhjælpende foranstaltning ventes snart | Valgfrit | Overført | Overført |
| Hvad brugerne kan gøre nu; hvor følsom I anser oplysningen for | Valgfrit | Overført | Overført |
| AEV: CVE-ID og EUVD-ID | Valgfrit | Overført | Overført |
| AEV: generelle oplysninger om sårbarheden, og hvordan udnyttelsen virker | Valgfrit | Påkrævet | Overført |
| SI: generelle oplysninger om hændelsens art; første vurdering | Valgfrit | Påkrævet | Overført |
| Angrebsvektor | Ikke spurgt | Valgfrit | Valgfrit |
| AEV: særligt ekstraordinære omstændigheder, med en begrundelse | Ikke spurgt | Valgfrit | Ikke spurgt |
| Trufne korrigerende eller afhjælpende foranstaltninger; foranstaltninger, brugerne kan træffe | Valgfrit | Valgfrit | Påkrævet |
| AEV: dato, hvor den korrigerende foranstaltning blev tilgængelig, og hvad den er | Valgfrit | Valgfrit | Påkrævet |
| AEV: fuld beskrivelse af alvor og konsekvens | Valgfrit | Valgfrit | Påkrævet |
| AEV: den ondsindede aktør, hvor der findes oplysninger | Valgfrit | Valgfrit | Påkrævet, hvis tilgængeligt |
| SI: detaljeret alvor og konsekvens; trussel eller grundårsag; anvendt og igangværende afhjælpning | Valgfrit | Valgfrit | Påkrævet |
Det er forordningens egen struktur med feltgrænser tegnet på. Artikel 14(2)(a) beder den tidlige varsling om "i givet fald at angive de medlemsstater, på hvis område fabrikanten har kendskab til, at deres produkt med digitale elementer er blevet gjort tilgængeligt"; det er feltet med medlemsstater, påkrævet fra første minut. Artikel 14(2)(b) beder 72-timersanmeldelsen om generelle oplysninger om produktet, udnyttelsens og sårbarhedens generelle art, de trufne korrigerende eller afhjælpende foranstaltninger og dem, brugerne kan træffe, og hvor følsom fabrikanten anser oplysningen for; det er de felter, der skifter fra valgfri til påkrævet på andet trin. Artikel 14(2)(c) beder den endelige rapport om alvor og konsekvens, aktøren, hvor den kendes, og sikkerhedsopdateringen eller den korrigerende foranstaltning; den tredje kolonne.
To praktiske begrænsninger fra ordlisten: En titel rummer 255 tegn og et resumé 4.000, og hvert tidsstempel indtastes i UTC. Ordlisten beder også om ikke at sætte fortrolige tekniske detaljer i titlen, og om at sige det i beskrivelsen, hvis tidspunktet for kendskab er et skøn. Én fodnote er værd at kende, før man leder efter et felt, der ikke er der: For en sårbarhed markerer ordlisten datoen for kendskab som påkrævet og siger så, at feltet "vil være tilgængeligt i platformens næste udgave"; for en hændelse findes det i dag under navnet "dato og klokkeslæt, hvor hændelsen blev opdaget".
Tælleren, som platformen efter eget udsagn regner forkert
Dashboardet viser tællere for 72-timersanmeldelsen og den endelige rapport, med påmindelsesmails og advarsler om overskridelse styret af dem. FAQ 26 siger, hvordan de beregnes, og det er værd at læse to gange. 72-timerstælleren "viser en frist 48 timer efter indgivelsen af den tidlige varsling på 24 timer", ikke 72 timer efter kendskab. Har I indgivet den tidlige varsling i time fire, viser platformen anmeldelsen som forfalden i time 52, og "i nogle tilfælde kan en anmeldelse blive vist som overskredet, før der er gået 72 timer, siden fabrikanten eller forvalteren af open source-software fik kendskab til hændelsen". ENISA siger, at logikken ændres i en kommende udgave til at bruge feltet for kendskab. Indtil da er platformens ur ikke forordningens ur, og FAQ'en siger, at tællerne "ikke erstatter fabrikanternes ansvar" for at overholde artikel 14's egne frister.
For den endelige rapport er der to tællere, og én mangler med vilje. For en alvorlig hændelse tæller platformen en måned fra indgivelsen af 72-timersanmeldelsen, hvilket er artikel 14(4)(c). For en aktivt udnyttet sårbarhed er der ingen tæller, fordi artikel 14(2)(c) løber 14 dage fra, at en korrigerende eller afhjælpende foranstaltning er tilgængelig, og platformen ikke kan kende den dato, før I indtaster den. Det er den samme sondring, som de fleste fremstillinger af CRA-fristerne overser, og grunden til, at beregneren på vores side med frister spørger særskilt om datoen for rettelsen.
Når I har trykket på indgiv
En gemt kladde er kun synlig for jer. Indgivelse af den tidlige varsling gemmer den, gør den tilgængelig for koordinatoren og ENISA og sender en e-mail og en advarsel til koordinatoren, til ENISA og til hver repræsentant for fabrikanten. Koordinatorerne i de andre medlemsstater, I har nævnt, modtager intet automatisk: ENISA's vejledning siger, at berørte CSIRT'er "først modtager den tidlige varsling efter manuel videregivelse fra det CSIRT, der er udpeget som koordinator". Det samme gælder 72-timersanmeldelsen og den endelige rapport.
I kan opdatere en anmeldelse på ethvert trin, indtil den endelige rapport er indgivet; derefter gør platformen den uredigerbar, og en anmeldelse, koordinatoren har lukket, kan heller ikke opdateres. En opdatering advarer koordinatoren, ENISA og ethvert CSIRT, der allerede har modtaget anmeldelsen. Advarsler på dashboardet er blå, mens de er ulæste; røde "vises kun, når der er sket en ekstraordinær eller kritisk handling", og ENISA's eksempel er, at koordinatoren har erklæret en indgivelse ugyldig.
At bede om udsat videregivelse
Artikel 16(2) siger, at koordinatoren "straks videregiver anmeldelsen" til koordinatorerne i de medlemsstater, hvor produktet er tilgængeligt, og gør så to undtagelser. Under ekstraordinære omstændigheder, "navnlig på fabrikantens anmodning og i lyset af den følsomhed af de anmeldte oplysninger, fabrikanten har angivet", må koordinatoren udsætte videregivelsen af begrundede cybersikkerhedsrelaterede hensyn i den strengt nødvendige periode. Og under "særligt ekstraordinære omstændigheder", hvor fabrikanten i 72-timersanmeldelsen angiver en af tre ting, går kun det forhold, at der er anmeldt, de generelle oplysninger om produktet, udnyttelsens generelle art og det forhold, at der er rejst hensyn, til ENISA, indtil den fulde anmeldelse videregives. De tre, ordret:
(a) at den anmeldte sårbarhed er blevet aktivt udnyttet af en ondsindet aktør og ifølge de tilgængelige oplysninger ikke er blevet udnyttet i nogen anden medlemsstat end den, hvis CSIRT udpeget som koordinator fabrikanten har anmeldt sårbarheden til; (b) at enhver øjeblikkelig yderligere videregivelse af den anmeldte sårbarhed sandsynligvis ville føre til afgivelse af oplysninger, hvis offentliggørelse ville stride mod denne medlemsstats væsentlige interesser; eller (c) at den anmeldte sårbarhed udgør en overhængende høj cybersikkerhedsrisiko, der udspringer af den yderligere videregivelse;
På platformen er det en kontakt, og den findes præcis ét sted: i 72-timersanmeldelsen af en aktivt udnyttet sårbarhed. Slås den til, vises en "PEC delay reason" med de tre hensyn som afkrydsningsfelter og en valgfri begrundelse på 800 tegn, "som kan hjælpe det CSIRT, der er udpeget som koordinator, med at beslutte". Videregivelsesstatus bliver "72h Submitted under PEC", ENISA modtager kun de begrænsede oplysninger, og beslutningen om, hvorvidt og hvornår der videregives, er koordinatorens, ikke fabrikantens. En kontakt er en anmodning.
Hvad koordinatoren må gøre med den anmodning, er nu fastlagt i Kommissionens delegerede forordning (EU) 2026/881 af 11. december 2025, offentliggjort i EU-Tidende den 20. april 2026. Artikel 3 lader kun koordinatoren udsætte videregivelsen, hvor cybersikkerhedsrisiciene ved at videregive overstiger gevinsten, hvor de risici ikke kan håndteres med begrænsninger som Traffic Light Protocol, og hvor en af fire betingelser gælder: Fabrikanten har oplyst, at en effektiv afhjælpning ventes inden 72 timer, og udsættelsen ophører, hvis den udebliver; anmeldelsen indeholder nok til at bygge et exploit, "navnlig når sårbarheden let kan identificeres og udnyttes af aktører med begrænsede færdigheder og ressourcer"; koordinatoren kan dele nok til, at de andre CSIRT'er kan afhjælpe uden den fulde anmeldelse; eller koordinatoren fik kendskab til sårbarheden som betroet mellemmand i en koordineret offentliggørelse. I andet og tredje tilfælde sendes den fulde anmeldelse, så snart en afhjælpning er tilgængelig. Artikel 4 og 5 tilføjer hensyn, der handler om modtagerne, ikke om fabrikanten: et CSIRT, eller platformen selv, der har været udsat for en hændelse, som sår tvivl om dets evne til at holde anmeldelsen fortrolig.
Den ærlige beskrivelse af kontakten er altså denne: Hvis I har en rettelse på vej inden tre dage, eller detaljerne ville give en angriber med få færdigheder et virkende exploit, så sig det, sæt kryds ved det hensyn, der passer, og giv koordinatoren fakta i de 800 tegn. Planlæg derefter, som om videregivelsen sker alligevel.
Hvis platformen er nede
FAQ 25: Er platformen midlertidigt utilgængelig, så vent, til den er tilbage, og indgiv da. Finder I imens øjeblikkelig kommunikation nødvendig, må I kontakte jeres koordinator direkte, men "anmeldelsen skal stadig indgives via SRP, når den igen er tilgængelig". Nogle koordinatorer har offentliggjort en nødløsning: Det irske NCSC angiver en nød-e-mailadresse til det tilfælde, hvor ENISA har erklæret platformen offline, og siger, at indsendelser dertil kun accepteres da. Artikel 17(6) forpligter hver koordinator til at yde helpdesk-støtte om artikel 14, "navnlig" til fabrikanter, der er mikrovirksomheder eller små og mellemstore virksomheder; ENISA's egen helpdesk kan nås pr. e-mail fra FAQ-siden.
Fem ting, FAQ'en afgør
- Ingen anmeldelse med tilbagevirkende kraft. En fabrikant, der allerede havde kendskab til den aktive udnyttelse før den 11. september 2026, skal ikke anmelde den nu; kendskab efter den dato udløser pligten, selv hvor selve sårbarheden var gammel eller kendt.
- Produkter, der allerede er på markedet, er omfattet. Artikel 14 gælder fra den 11. september 2026 for ethvert produkt med digitale elementer inden for forordningens anvendelsesområde, herunder produkter bragt i omsætning før den 11. december 2027.
- Tredjepartskomponenter. For en sårbarhed i en komponent, I integrerer, henviser ENISA til afsnit 5.4 i Kommissionens FAQ om gennemførelsen og til punkt 218 i Kommissionens vejledning af 27. juli 2026 frem for at svare med egne ord. Læs dem, før I beslutter, at det ikke er jer, der skal anmelde.
- Anmeldelsen øger ikke jeres ansvar. Artikel 17(4): "Selve anmeldelsen ... medfører ikke et øget ansvar for den anmeldende fysiske eller juridiske person."
- Efter rettelsen bliver sårbarheden offentlig. Artikel 17(5): Når en sikkerhedsopdatering eller anden korrigerende foranstaltning er tilgængelig, føjer ENISA den anmeldte sårbarhed til den europæiske sårbarhedsdatabase efter aftale med fabrikanten.
Hvad I forbereder, før I får brug for noget af det
- EU Login-konti med multifaktorgodkendelse til den, der anmelder, og en stedfortræder, oprettet i dag, og en skriftlig bemyndigelse til begge.
- Jeres medlemsstat og koordinator, afgjort efter artikel 14(7) og skrevet ind i hændelsesproceduren, så ingen vælger mellem punkter i en rullemenu i time et.
- En produktfortegnelse med de præcise versions-, build-, model- eller firmwarebetegnelser, versionsfeltet spørger om, og en liste over de medlemsstater, hvor hvert produkt gøres tilgængeligt, fordi det felt er påkrævet i den tidlige varsling.
- En konvention for "få kendskab" og en regel om, at tidsstemplet noteres i UTC i det øjeblik, det fastsættes.
- Et udkast på én side med den tidlige varslings felter i et dokument, I kan kopiere fra: titel under 255 tegn, resumé under 4.000, de to datoer, medlemsstaterne.
- Et navn på den, der inden for de første 72 timer beslutter, om feltet for ekstraordinære omstændigheder skal krydses af, og på hvilke fakta.
Platformen gør intet af dette for jer, og det gør denne artikel heller ikke. Hvad den kan, er at gøre time et til et spørgsmål om at taste frem for at læse.
Kilder
- ENISA, sider om Single Reporting Platform: hovedsiden, FAQ'en (opdateret den 11. september 2026), vejledningssiderne om brugerregistrering, indgivelse og opdatering af anmeldelser, brugerfladefunktioner og særligt ekstraordinære omstændigheder (opdateret den 9. og 10. september 2026), SRP-ordlisten, AR User Manual og vilkårene v1.0 af 10. september 2026, alle læst den 12. september 2026.
- ENISA, List of CSIRTs Designated as Coordinators, senest opdateret den 10. september 2026.
- Forordning (EU) 2024/2847, artikel 14, 16 og 17 samt artikel 71(2).
- Kommissionens delegerede forordning (EU) 2026/881 af 11. december 2025, artikel 3 til 5, EUT L af 20. april 2026.
- Europa-Kommissionen, vejledning C(2026) 5252 af 27. juli 2026 og FAQ om gennemførelsen af CRA, afsnit 5.
- NCSC Irland, side om anmeldelsespligterne i Cyber Resilience Act, opdateret den 11. september 2026.
Dette er ikke juridisk rådgivning. Ordlisten er en tabel med 39 felter, og FAQ'en er 31 spørgsmål; begge er korte nok til at læse, før I får brug for dem.