Hvad forordningen om cyberrobusthed kræver, at du indberetter

Hvad forordningen om cyberrobusthed kræver, at du indberetter

Forordningen om cyberrobusthed kræver ikke, at producenter indberetter enhver sårbarhed eller straks afhjælper enhver CVE. Dens tidlige indberetningsforpligtelser begynder den 11. september 2026, mens bredere forpligtelser til håndtering af sårbarheder generelt gælder fra den 11. december 2027.

Skeln mellem indberetning og håndtering af sårbarheder

To almindelige antagelser om forordningen om cyberrobusthed (CRA), forordning (EU) 2024/2847, er misvisende: at enhver sårbarhed skal indberettes fra september 2026, og at enhver CVE, der påvirker en komponent, skal rettes. Forordningen siger ingen af delene.

Den skelner mellem øjeblikkelig indberetning af visse hændelser og det bredere, løbende arbejde med at håndtere sårbarheder i produkter med digitale elementer.

Forpligtelse Udløser Hvad der kræves Anvendelsesdato
Indberet til den udpegede CSIRT-koordinator og ENISA Producenten bliver bekendt med en aktivt udnyttet sårbarhed i sit produkt eller en alvorlig hændelse, der påvirker produktets sikkerhed Indsend en tidlig advarsel inden for 24 timer, en underretning inden for 72 timer og den relevante endelige rapport; underret berørte brugere og, hvor det er relevant, alle brugere 11. september 2026
Håndter sårbarheder i produktet En sårbarhed i produktet eller dets komponenter bliver kendt Vurder relevans, praktisk udnyttelighed og risiko; håndter og afhjælp sårbarheder uden unødig forsinkelse i forhold til risikoen; dokumentér arbejdet Generelt 11. december 2027
Overvåg og modtag oplysninger om sårbarheder Løbende Oprethold processer for interne og eksterne sårbarhedskilder, test, koordineret offentliggørelse og et kontaktpunkt for indberetning Generelt 11. december 2027

Artikel 71, stk. 2, gør tidspunktet klart: Forordningen finder anvendelse fra den 11. december 2027, men indberetning efter artikel 14 gælder fra den 11. september 2026. Den tidligere dato fremrykker ikke alle CRA-forpligtelser til håndtering af sårbarheder.

Overgangsreglerne er også vigtige. Artikel 69 anvender indberetning efter artikel 14 på produkter inden for anvendelsesområdet, som er bragt i omsætning før den 11. december 2027. Et ældre produkt bør derfor ikke betragtes som uden for indberetningsordningen, blot fordi det går forud for den generelle anvendelsesdato. De bredere forpligtelser kræver deres egen vurdering i forhold til forordningens anvendelsesområde og overgangsbestemmelser.

Hvad der skal indberettes

Artikel 14 fastlægger to primære udløsere for indberetning.

For det første skal en producent indberette en aktivt udnyttet sårbarhed i sit produkt, når producenten bliver bekendt med den. Dette er snævrere end en sårbarhed, der kan udnyttes. CRA definerer en aktivt udnyttet sårbarhed som en sårbarhed, hvor der foreligger pålidelig dokumentation for, at en ondsindet aktør har udnyttet den i et system uden systemejerens tilladelse.

For det andet skal en producent indberette en alvorlig hændelse, der påvirker produktets sikkerhed. I henhold til artikel 14, stk. 5, er en hændelse alvorlig, når den påvirker eller kan påvirke produktets evne til at beskytte tilgængeligheden, autenticiteten, integriteten eller fortroligheden af følsomme eller vigtige data eller funktioner negativt. Den er også alvorlig, når den har medført eller kan medføre, at ondsindet kode introduceres eller eksekveres i produktet eller i en brugers net- og informationssystemer.

En ny databasepost, et fund ved en penetrationstest eller en rapport fra en sikkerhedsforsker er derfor ikke automatisk en indberetning efter artikel 14. Den skal stadig indgå i producentens proces for håndtering af sårbarheder. Men uden pålidelig dokumentation for ondsindet udnyttelse opfylder et fund, der er opdaget gennem test i god tro, forskning, afhjælpning eller offentliggørelse, ikke i sig selv udløseren for aktivt udnyttede sårbarheder, som er beskrevet i CRA.

Indberetningsfristerne er trinvise

Forordningen fastsætter forskellige trin og frister for endelige rapporter for sårbarheder og hændelser.

Indberetningstrin Frist
Tidlig advarsel Inden for 24 timer efter at være blevet bekendt med forholdet
Underretning Inden for 72 timer efter at være blevet bekendt med forholdet
Endelig rapport om en aktivt udnyttet sårbarhed Senest 14 dage efter, at en korrigerende eller afbødende foranstaltning er tilgængelig
Endelig rapport om en alvorlig hændelse Inden for en måned efter 72-timersunderretningen

Rapporter indsendes samtidig til den udpegede CSIRT-koordinator og ENISA. Den nuværende operationelle kanal er ENISA's Single Reporting Platform. ENISA anbefaler i øjeblikket, at producenter bruger EU Login og arrangerer adgang gennem udpegede repræsentanter; disse operationelle detaljer kan ændre sig, så de bør kontrolleres i den aktuelle vejledning om ENISA-platformen, før den anvendes.

Information til brugere er en del af beredskabet

Indberetning til myndigheder er ikke den eneste umiddelbare opgave. Artikel 14, stk. 8, kræver, at producenten informerer berørte brugere og, hvor det er relevant, alle brugere om sårbarheden eller hændelsen. Hvor det er nødvendigt, skal producenten også formidle risikobegrænsende og korrigerende foranstaltninger, som brugerne kan træffe.

En praktisk beredskabsordning for september 2026 omfatter derfor:

  • adgang til indberetningsplatformen og klarhed over den relevante CSIRT-koordinator;
  • en navngiven indberetter og en brugbar stedfortræderordning uden for normal arbejdstid;
  • en hurtig proces til at gennemgå troværdige rapporter og registrere, hvornår producenten blev bekendt med forholdet; og
  • en pålidelig måde at kontakte brugere på med klar hændelseskommunikation forberedt på forhånd.

Et fuldt udviklet team til håndtering af produktsikkerhedshændelser kan understøtte dette arbejde, men artikel 14 foreskriver ikke en bestemt organisationsmodel. Det afgørende er, at producenten kan genkende en udløser, handle inden for fristerne og nå de berørte brugere.

En CVE er et input, ikke udløseren for indberetning

En CVE-identifikator hjælper med at identificere og katalogisere en offentliggjort sårbarhed. Den er nyttig infrastruktur for koordinering, men den er ikke CRA's generelle udløser for indberetning og er ikke en generel betingelse for overholdelse.

Den juridiske udløser er aktiv udnyttelse i producentens produkt eller en alvorlig produktsikkerhedshændelse. ENISA's aktuelle indberetningsvejledning angiver et CVE-id som valgfrit i skabelonen til 24-timersrapporten. Det betyder ikke, at CVE-oplysninger aldrig vil være nyttige eller blive anmodet om senere; det betyder, at en CVE-identifikator ikke kan erstatte en vurdering af de produktspecifikke forhold.

ENISA's roller i CVE-programmet og organisationens drift af EU's sårbarhedsdatabase kan understøtte identifikation og koordinering. De afgør ikke, om et problem i en komponent er relevant for et bestemt produkt, eller om en indberetning efter artikel 14 er påkrævet.

Vurder sårbarheder i komponenter i deres kontekst

CRA kræver, at producenter identificerer og dokumenterer sårbarheder og komponenter, herunder ved at udarbejde en softwarestykliste. Den kræver også, at de håndterer og afhjælper sårbarheder uden unødig forsinkelse i forhold til de risici, produktet medfører.

Et match i en database er kun begyndelsen på analysen. En producent skal fastslå, om:

  1. den berørte komponent og version findes i produktet;
  2. sårbarheden påvirker den måde, komponenten anvendes på i produktet;
  3. en modstander effektivt kan udnytte den under praktiske driftsforhold; og
  4. den deraf følgende risiko kræver afhjælpning, begrænsning eller en anden dokumenteret reaktion.

CRA definerer en udnyttelig sårbarhed som en sårbarhed, der potentielt kan anvendes effektivt af en modstander under praktiske driftsforhold. Det kræver en produktspecifik vurdering, ikke en automatisk konklusion på baggrund af et scannerresultat.

Vurderingsresultat Passende næste skridt
Komponenten er ikke til stede, eller versionen er ikke berørt Registrér vurderingen og dens grundlag
Komponenten er til stede, men problemet kan ikke udnyttes under praktiske driftsforhold Dokumentér begrundelsen, overvej relevante forpligtelser til underretning om komponenter, og fortsæt med at overvåge relevante ændringer
Problemet i komponenten er relevant og kan udnyttes Håndter og afhjælp det uden unødig forsinkelse i forhold til risikoen, dokumentér beslutningen og formidl relevante korrigerende oplysninger
Der foreligger pålidelig dokumentation for ondsindet udnyttelse i produktet Tag skridt til håndtering af sårbarheden og indsend rapporterne efter artikel 14; underret brugere som påkrævet

Et ikke-udnytteligt fund bør ikke blot forsvinde fra synsfeltet. Artikel 13 kræver systematisk og forholdsmæssig dokumentation af relevante cybersikkerhedsaspekter, herunder kendte sårbarheder. En klar registrering af, hvorfor et fund påvirker eller ikke påvirker produktet, er ofte lige så vigtig som det tekniske resultat.

Opbyg den bredere proces for december 2027

Fra den generelle anvendelsesdato bliver håndtering af sårbarheder en bredere operationel disciplin. CRA kræver risikovurdering, processer for håndtering af sårbarheder, regelmæssig og effektiv sikkerhedstest, foranstaltninger til koordineret offentliggørelse af sårbarheder og en kontaktadresse til indberetning af sårbarheder. Producenter har også behov for en SBOM, der hjælper dem med at knytte eksterne oplysninger til deres egne produkter.

Nyttige input omfatter offentlige sårbarhedsdatabaser, oplysninger om komponenter og leverandører, intern test og rapporter fra eksterne parter. Ingen af disse input træffer den juridiske afgørelse alene. Producenten skal sætte dem i relation til sit produkt, dets implementeringsforhold og de relevante risici.

Værktøjer til analyse af softwaresammensætning, SBOM-styring og matchning af sårbarheder kan hjælpe med at identificere mulig eksponering i stor skala. De fastslår normalt ikke, om en sårbar funktion kan nås, om udnyttelse er praktisk mulig i produktets driftsmiljø, eller hvilken risiko der følger. Fastlæg først processen for vurdering og dokumentation, og automatisér derefter de gentagelige dele.

Fokusér på den rette forpligtelse på det rette tidspunkt

For den 11. september 2026 er den umiddelbare prioritet en velfungerende proces for indberetning og brugerkommunikation. Producenter bør kunne genkende aktivt udnyttede sårbarheder og alvorlige hændelser, indsende trinvise rapporter til tiden og underrette brugere, hvor det kræves.

For den 11. december 2027 udvides fokus til løbende håndtering af sårbarheder: identifikation, vurdering, risikobaseret afhjælpning, dokumentation, test, ordninger for offentliggørelse og synlighed over komponenter.

Kort sagt: Indberet det, der opfylder udløseren i artikel 14. Vurder hver kendt sårbarhed i produktets kontekst. Afhjælp sårbarheder i forhold til risikoen, og opbevar den dokumentation, der understøtter beslutningen. Dette er generel regulatorisk information og ikke juridisk rådgivning.

Brug for hjælp til implementering af cyber-regulering?

Kontakt Secuvi →