CRA's første frist er ikke i 2027. Kan jeres produktteam rapportere inden for 24 timer?

Mandag klokken 09.10 videresender supporten en besked fra en kunde. Kunden har fundet tegn på, at en ukendt aktør har udnyttet en fejl i loginfunktionen i jeres lokalt installerede administrationsklient. Logfilerne ser troværdige ud, men I ved endnu ikke, hvilke versioner der er berørt, hvor mange kunder der bruger dem, eller om udnyttelsen er sket andre steder.

Hvem beslutter, om signalet er en aktivt udnyttet sårbarhed? Hvornår blev virksomheden som producent bekendt med den? Og hvem ejer den første myndighedsvarsling?

De spørgsmål kan ikke vente på den fulde årsagsanalyse. Fra 11. september 2026 kan 24-timersuret være startet, mens væsentlige oplysninger stadig mangler.

Den første CRA-dato er 11. september 2026

Cyber Resilience Act er EU's forordning om cybersikkerhedskrav til produkter med digitale elementer og lægger pligter på producenter, der udvikler eller får udviklet sådanne produkter og markedsfører dem under eget navn eller varemærke.

Forordningen finder generelt anvendelse fra 11. december 2027. Men artikel 14 gælder allerede fra 11. september 2026. Den omfatter producentens rapportering af to forskellige forhold: aktivt udnyttede sårbarheder i produktet og alvorlige hændelser, der påvirker produktets sikkerhed.

For begge grene begynder forløbet med en tidlig varsling uden unødig forsinkelse og senest 24 timer efter, at producenten bliver bekendt med forholdet. En mere udfoldet anmeldelse følger senest 72 timer efter T0. Derefter er slutrapporten forskellig for de to grene.

Denne øvelse følger en aktivt udnyttet sårbarhed:

Øvelsen tester den første operationelle rapporteringsvej. Resten af CRA-programmet ligger uden for scenariet.

Før øvelsen: Test produktet, ikke brancheetiketten

Begynd ikke med spørgsmålet: “Er vi en softwarevirksomhed?” Begynd med et konkret produkt, måden det bliver gjort tilgængeligt på, og jeres rolle.

CRA definerer blandt andet en producent som den person eller virksomhed, der udvikler eller fremstiller et produkt med digitale elementer, eller får det designet, udviklet eller fremstillet, og markedsfører det under eget navn eller varemærke. Hardware, lokalt installeret software og forbundne produkter kan derfor være relevante.

Al SaaS er derfor ikke automatisk omfattet. Kommissionens vejledning fra juli 2026 forklarer, at en webapplikation, der kun tilgås gennem en browser, ikke alene af den grund er et produkt med digitale elementer. Nødvendig fjernbehandling kan derimod indgå i et omfattet produkt.

Det er vejledning, ikke lovtekstens ordlyd. Hvis afgrænsningen er uklar, skal den afklares særskilt. Tabletop-øvelsen kan stadig afdække, om jeres rapporteringsvej er brugbar.

Tabletop: Ét produkt, ét signal, fem ejere

Vælg en lokalt installeret B2B-klient, som kunder bruger til at administrere adgang til deres udstyr. Klienten markedsføres under jeres navn. En kunde har sendt logfiler, der tyder på, at en ukendt aktør har omgået autentificeringen og fået adgang uden tilladelse.

Saml produkt, sikkerhed, udvikling, jura og brugerkommunikation. Giv dem de samme ufuldstændige oplysninger. Udpeg én hændelsesleder og én ejer af myndighedsrapporteringen.

Hold fokus på de fire sammenhængende beslutninger, som organisationen skal træffe, mens undersøgelsen fortsætter. Selve sårbarheden må gerne forblive uløst under øvelsen.

Beslutning 1: Har I pålidelig evidens for aktiv udnyttelse?

En sårbarhed er ikke automatisk rapporteringspligtig efter artikel 14. Lovteksten skelner mellem en sårbarhed, der kan udnyttes, og en aktivt udnyttet sårbarhed.

En aktivt udnyttet sårbarhed kræver pålidelig evidens for, at en ondsindet aktør har udnyttet den i et system uden systemejerens tilladelse. I scenariet skal teamet derfor vurdere kundens logfiler, den berørte produktversion og forbindelsen mellem fejlen og den uautoriserede adgang.

Beslutningen skal efterlade et spor. Notér, hvilken evidens vurderingen bygger på, hvilke versioner der kan være berørt, hvem der godkendte klassifikationen, og hvornår producenten blev bekendt med den aktive udnyttelse.

Sæt et præcist klokkeslæt på kendskabet. Uret løber ikke fra den dag, koden med fejlen blev skrevet. For denne rapporteringsvej knytter lovteksten fristen til producentens kendskab til den aktivt udnyttede sårbarhed.

Beslutning 2: Hvad kan I stå inde for efter 24 timer?

Den tidlige varsling skal sendes uden unødig forsinkelse og senest 24 timer efter T0. Den indsendes via ENISA's Single Reporting Platform til den koordinerende CSIRT i det land, hvor producenten har sit hovedforretningssted i EU, og er samtidig tilgængelig for ENISA.

For en aktivt udnyttet sårbarhed kræver artikel 14, at varslingen, hvor det er relevant, angiver de medlemsstater, hvor producenten ved, at produktet er gjort tilgængeligt.

Det er et snævert juridisk minimum. Jeres interne kladde bør også gøre det let at se produkt og version, evidensstatus, ansvarlig ejer og eventuel følsomhed. De felter er praktisk forberedelse til det videre forløb. De skal ikke præsenteres som en udtømmende gengivelse af lovkravet.

Kan teamet finde de nødvendige markedsoplysninger, få en ansvarlig godkendelse og indsende varslingen, selv om årsag og omfang stadig undersøges?

Beslutning 3: Kan 72-timersanmeldelsen bruges?

Senest 72 timer efter T0 følger sårbarhedsanmeldelsen, medmindre oplysningerne allerede er givet. Her skal producenten efter artikel 14 give de oplysninger, der er tilgængelige, om produktet, udnyttelsens og sårbarhedens generelle karakter samt de korrigerende eller afbødende tiltag, der er truffet. Anmeldelsen skal også beskrive tiltag, som brugerne kan gennemføre, og hvor relevant angive, hvor følsomme oplysningerne vurderes at være.

Efter 72 timer kan undersøgelsen stadig være åben. Anmeldelsen skal alligevel kunne bruges. Hvis teamet stadig ikke kan identificere de berørte versioner, forklare den generelle udnyttelse eller give brugerne en forsvarlig midlertidig handling, har øvelsen fundet et reelt brud i beredskabet.

Brugerkommunikationen kører samtidig. Producenten skal informere de berørte brugere og, hvor det er relevant, alle brugere om sårbarheden og om nødvendige risikobegrænsende eller korrigerende tiltag. Artikel 14 opstiller ikke en særskilt 24-timersfrist for denne information. Den må heller ikke sættes på pause, blot fordi myndighedsanmeldelsen har sit eget forløb.

Den anden gren: Ved en alvorlig hændelse gælder også en tidlig varsling inden for 24 timer og en anmeldelse inden for 72 timer. Slutrapporten følger senest en måned efter hændelsesanmeldelsen og har et andet indhold. Derfor bør den testes i et separat scenarie.

Beslutning 4: Ret, kommunikér og luk sagen

Rapporteringen slutter ikke efter 72 timer. Teamet skal følge rettelsen, holde brugerne orienteret og kunne dokumentere, hvad der blev gjort.

For den aktivt udnyttede sårbarhed skal slutrapporten indsendes senest 14 dage efter, at en korrigerende eller afbødende foranstaltning er tilgængelig. Rapporten skal mindst beskrive sårbarheden, dens alvor og konsekvens, tilgængelige oplysninger om den aktør, der har udnyttet den, samt sikkerhedsopdateringen eller andre korrigerende tiltag.

Det gør tidspunktet for en tilgængelig patch eller anden afbødning til en ny vigtig markering i sagen. Hvis udvikling, support og rapportering bruger forskellige tidspunkter eller produktbetegnelser, bliver slutrapporten unødigt vanskelig.

Øvelsen bør derfor først afsluttes, når teamet kan forbinde sårbarhed, berørte versioner, rettelse, brugerinformation og slutrapport i samme spor.

Debrief: Seks brud, I skal finde nu

Tabletop-øvelsen er nyttig, hvis den finder de svage overgange, før en reel sag gør det. Afslut med seks spørgsmål:

1. Ejer: Er det navngivet, hvem der kan erklære T0, og hvem der indsender varsling og anmeldelse?
2. Produkt og version: Kan I hurtigt forbinde en sårbarhed med de berørte produktversioner og kunder?
3. Marked: Ved I, i hvilke medlemsstater produktet er gjort tilgængeligt?
4. Evidens: Har support, sikkerhed og udvikling én kendt vej til at modtage, bevare og vurdere tegn på aktiv udnyttelse?
5. Rapporteringskanal: Ved de udpegede personer, hvordan de får adgang til Single Reporting Platform, og hvem der kan træde til uden for normal arbejdstid?
6. Brugere: Kan I nå de berørte brugere med præcis information om risiko, midlertidige tiltag og rettelse?

Det er en operationel tjekliste udledt af rapporteringsforløbet, ikke en ordret liste fra forordningen. Hvis ét svar er uklart, har I fundet en konkret opgave. Giv den en ejer og en dato.

Kør øvelsen før 11. september

Vælg ét produkt, som sandsynligvis er omfattet. Brug et troværdigt signal om aktiv udnyttelse, sæt T0, og lad teamet arbejde gennem 24 timer, 72 timer, brugerinformationen og slutrapporten.

Find den første overdragelse, der bryder sammen, og ret den, før uret starter i en reel sag.