Anmeldelsespligten i Cyber Resilience Act, artikel 14 i forordning (EU) 2024/2847, forklares som regel ved sine ure: 24 timer, 72 timer og en endelig rapport. Urene starter først, når en af to ting sker, og begge er defineret i forordningen snævrere, end de fleste resuméer antyder. At anmelde alt er lige så meget en fejl som at anmelde intet: Det oversvømmer CSIRT'et, fortæller brugerne intet og træner organisationen i at ignorere sin egen procedure.

Her er de to udløsere, som teksten definerer dem, og den grænse, hver af dem trækker.

Udløser ét: en aktivt udnyttet sårbarhed

Artikel 14, stk. 1, kræver, at fabrikanten anmelder "enhver aktivt udnyttet sårbarhed i produktet med digitale elementer, som fabrikanten får kendskab til".

Artikel 3, nr. 42, definerer begrebet: En aktivt udnyttet sårbarhed er "en sårbarhed, for hvilken der foreligger pålidelige beviser for, at en ondsindet aktør har udnyttet den i et system uden systemejerens tilladelse".

Tre ord bærer definitionen.

"Pålidelige beviser." Ikke en scanners alvorlighedsscore, ikke et proof of concept på en sikkerhedsblog, ikke en CVE med et rygte om "udnyttet i naturen" hæftet på. Beviser for, at udnyttelsen er sket, af en kvalitet, I ville handle på. Kommissionens retningslinjer af 27. juli 2026 sætter kendskab ved en rimelig grad af sikkerhed: ikke det første rygte, ikke den afsluttede efterforskning.

"En ondsindet aktør." Udnyttelse af jeres egne penetrationstestere, af en forsker, der har indberettet den ansvarligt, eller af en kunde, der tester sin egen installation, er ikke udnyttelse af en ondsindet aktør. Sårbarheden kan være alvorlig; den er ikke, alene på det grundlag, en udløser.

"I et system." Ethvert system, ikke kun jeres kundes. Pålidelige beviser for, at sårbarheden i jeres produkt er blevet udnyttet af en angriber et hvilket som helst sted, er nok; I venter ikke på, at en af jeres egne brugere bliver ramt.

Hvad der er ude: teoretiske sårbarheder, ikke-udnyttede proofs of concept, sårbarheder fundet af jeres egne test og sårbarheder i komponenter, der er kendte og under afhjælpning, men uden beviser for udnyttelse. Det er arbejde under bilag I, del II, håndteret og offentliggjort efter kravene til håndtering af sårbarheder, ikke anmeldelser efter artikel 14.

Udløser to: en alvorlig hændelse med indvirkning på produktets sikkerhed

Artikel 14, stk. 3, kræver anmeldelse af "enhver alvorlig hændelse med indvirkning på sikkerheden i produktet med digitale elementer". Artikel 14, stk. 5, siger, hvornår en hændelse er alvorlig:

a) den påvirker eller kan påvirke negativt evnen hos et produkt med digitale elementer til at beskytte tilgængeligheden, autenticiteten, integriteten eller fortroligheden af følsomme eller vigtige data eller funktioner, eller b) den har ført eller kan føre til indførelse eller udførelse af ondsindet kode i et produkt med digitale elementer eller i net- og informationssystemerne hos en bruger af produktet.

To ting at bemærke.

"Kan." Begge led dækker hændelser, der kunne have virkningen, ikke kun dem, der havde den. En hændelse, der blev inddæmmet, før data gik tabt, er stadig alvorlig, hvis den kunne have ført til tabet.

Det handler om produktets sikkerhed, ikke jeres virksomheds. Et indbrud i jeres firmamail er en hændelse, og efter NIS2 kan den være anmeldelsespligtig, men den er kun en udløser efter artikel 14, hvis den har indvirkning på sikkerheden i det produkt, I bringer i omsætning: jeres build-pipeline, jeres opdateringsserver, signeringsnøglen, den cloud-backend, et produkt afhænger af. Testen er, om produktets evne til at beskytte sine brugeres data eller funktioner er påvirket, eller om ondsindet kode kunne nå produktet eller dets brugeres systemer gennem hændelsen.

Den tredje pligt, der følger med begge: informer jeres brugere

Artikel 14, stk. 8: Efter at have fået kendskab til en af de to udløsere "informerer fabrikanten de berørte brugere af produktet med digitale elementer og, hvor det er relevant, alle brugere om sårbarheden eller hændelsen og, hvor det er nødvendigt, om risikobegrænsende og afhjælpende foranstaltninger, som brugerne kan iværksætte for at afbøde virkningen", hvor det er relevant i et struktureret, maskinlæsbart format. Hvis fabrikanten ikke informerer brugerne rettidigt, kan CSIRT'et gøre det i stedet.

Det er den pligt, de fleste anmeldelsesprocedurer glemmer. CSIRT'et og ENISA er den ene modtager. Brugerne er den anden, og måden at nå dem på, ordlyden og det maskinlæsbare format er ting, der skal besluttes før dagen.

Ikke anmeldelsespligtig skal stadig noteres

En sårbarhed eller hændelse, der ikke opfylder nogen af de to definitioner, anmeldes ikke efter artikel 14, men afgørelsen om, at den ikke gør, er en registrering, der er værd at gemme: hvad der skete, hvorfor den blev vurderet til ikke at falde under 3, nr. 42, eller 14, stk. 5, hvem der vurderede det, og hvornår. Ændrer beviserne sig, begynder kendskabet i artikel 14's forstand da, og registreringen viser, at uret blev holdt øje med. Det er forskellen på en virksomhed, der besluttede ikke at anmelde, og en, der ikke opdagede det.

Hvad I skal gøre

Skriv de to definitioner ordret ind i hændelsesproceduren med de tre spørgsmål til hver: Foreligger der pålidelige beviser, for udnyttelse af en ondsindet aktør, i et hvilket som helst system; påvirker eller truer hændelsen produktets beskyttelse af følsomme data eller funktioner, eller ondsindet kode i produktet eller en brugers systemer. Navngiv, hvem der afgør det, og registrer hver afgørelse, også "nej". Så urene, til jeres CSIRT og ENISA, og beskeden til brugerne.

Kilder

  • Forordning (EU) 2024/2847, artikel 3, nr. 42 (citeret), artikel 14, stk. 1, 3, 5 (citeret) og 8 (citeret). Læst i EU-Tidende-teksten på EUR-Lex den 11. september 2026.
  • Europa-Kommissionens retningslinjer C(2026) 5252 af 27. juli 2026 om betydningen af kendskab.

Dette er ikke juridisk rådgivning. De to definitioner er to sætninger i forordningen; de hører hjemme i jeres procedure, som de er skrevet, ikke som de huskes.