Cyber Resilience Act: hvad softwarehuse skal holde øje med

En kunde kan spørge, om jeres softwarehus er klar til Cyber Resilience Act, og spørgsmålet er sværere at besvare, end det ser ud. Forordningen stiller krav til fabrikanter af produkter med digitale elementer, men et rent SaaS-produkt og en installerbar applikation står forskelligt i den. Svaret hviler på forordningens egen tekst om, hvad den omfatter, og hvornår de enkelte dele gælder. Om netop jeres produkt er omfattet, skal vurderes for sig; teksten er ikke juridisk rådgivning, og den lover ikke, hvordan en myndighed vil se på jeres produkt.

Hvad forordningen er

Cyber Resilience Act er forordning (EU) 2024/2847 om horisontale cybersikkerhedskrav til produkter med digitale elementer. Efter artikel 2, stk. 1, gælder den for produkter med digitale elementer, der gøres tilgængelige på markedet, når deres formål eller rimeligt forudsigelige brug omfatter en dataforbindelse til en enhed eller et netværk. Artikel 2 undtager produkter, der er dækket af visse andre EU-regler, fx om medicinsk udstyr.

Et produkt med digitale elementer er ifølge artikel 3, nr. 1, et software- eller hardwareprodukt og dets fjerndatabehandlingsløsninger. Det er definitionen, I skal holde jeres produkt op imod.

SaaS eller produkt

Fjerndatabehandling er efter artikel 3, nr. 2, databehandling på afstand, hvor softwaren er designet og udviklet af fabrikanten eller under fabrikantens ansvar, og hvor produktet ikke kan udføre en af sine funktioner uden den. Betragtning 12 forklarer, at cloudløsninger kun er fjerndatabehandlingsløsninger i forordningens forstand, hvis de opfylder den definition, og at cloudtjenester, der er udviklet uden for en fabrikants ansvar for et produkt, ikke er omfattet. Samme betragtning nævner, at NIS2-direktivet gælder for cloudtjenester som software som en service.

For et softwarehus giver det tre situationer. Sælger I kun en webbaseret tjeneste, peger betragtningen mod NIS2 frem for Cyber Resilience Act. Sælger I software, som kunderne installerer, er det et produkt. Og sælger I en installerbar komponent, fx en agent eller en klient, der ikke virker uden jeres backend, kan backend være en fjerndatabehandlingsløsning til produktet. Den sidste situation er den, der kræver mest omtanke. → Kunder omfattet af NIS2

Hvornår reglerne gælder

Efter artikel 71 finder forordningen anvendelse fra den 11. december 2027. Artikel 14 om fabrikanternes rapportering gælder dog allerede fra den 11. september 2026, og kapitel IV om bemyndigede organer fra den 11. juni 2026.

Artikel 69 bestemmer, at produkter, der er bragt i omsætning før den 11. december 2027, kun er omfattet af kravene, hvis de væsentligt ændres derefter. Men rapporteringspligten i artikel 14 gælder ifølge samme artikel for alle omfattede produkter, også dem, der er bragt i omsætning før den dato. For et omfattet produkt er rapportering altså ikke noget, der først kommer i 2027.

Rapportering om aktivt udnyttede sårbarheder

Artikel 14 kræver, at fabrikanten underretter den CSIRT, der er udpeget som koordinator, og ENISA om enhver aktivt udnyttet sårbarhed i produktet, som fabrikanten får kendskab til, via en fælles indberetningsplatform. Efter stk. 2 skal der indgives en tidlig varsling senest 24 timer efter, at fabrikanten fik kendskab til den, en meddelelse senest 72 timer efter og en endelig rapport senest 14 dage efter, at en rettelse eller afbødende foranstaltning er tilgængelig. Stk. 3 og 4 indeholder tilsvarende regler for alvorlige hændelser, der påvirker produktets sikkerhed.

Det er værd at bemærke ordlyden: pligten gælder aktivt udnyttede sårbarheder, ikke ethvert fund fra en pentest. Et fund, testeren har gjort i et testmiljø, er ikke i sig selv en aktivt udnyttet sårbarhed. Men jeres proces for at modtage og vurdere sårbarheder skal kunne skelne de to. → Ansvarlig offentliggørelse

Hvor sikkerhedstest kommer ind

Bilag I, del II, beskriver fabrikantens krav til håndtering af sårbarheder. Punkt 3 kræver effektive og regelmæssige afprøvninger og gennemgange af produktets sikkerhed. De øvrige punkter handler blandt andet om en softwarekomponentliste, hurtig afhjælpning med sikkerhedsopdateringer, en politik for koordineret offentliggørelse af sårbarheder og en kontaktadresse til indberetning.

Forordningen siger ikke, at afprøvningen skal være en penetrationstest, og den fastsætter ikke en rytme. En pentest kan være en del af afprøvningen sammen med andre former for test og gennemgang. For jer betyder det, at testens dokumentation får en ny modtager: ud over kunderne kan den indgå i den tekniske dokumentation for produktet. → Sårbarheder i afhængigheder mellem to test

Hvad I kan svare kunden nu

En kunde, der spørger, om I er klar til Cyber Resilience Act, har krav på et ærligt svar. Sig, om I har vurderet, hvorvidt produktet er omfattet, og hvad vurderingen viste. Er produktet omfattet, så beskriv, hvordan I håndterer sårbarheder i dag: test, kontaktvej, opdateringer og en plan for rapportering. Er I ikke færdige med vurderingen, så sig det.

Lov ikke overensstemmelse med forordningen, og undgå formuleringer som CRA-klar. Det er en vurdering, der hviler på jer som fabrikant og i sidste ende på myndighederne. → Pligt til at underrette kunden om sårbarheder

☐ Har I vurderet, om produktet eller en del af det er omfattet?
☐ Ved I, hvem der modtager og vurderer indberetninger om sårbarheder?
☐ Kan I skelne et testfund fra en aktivt udnyttet sårbarhed?
☐ Er der en plan for rapportering inden for fristerne i artikel 14?
☐ Er test og gennemgange af produktet dokumenteret, så de kan genfindes?

Et tænkt eksempel

Et softwarehus leverer et system til adgangskontrol i kontorbygninger. Kunderne bruger en webportal, men systemet har også en lille applikation, der installeres på en server i bygningen og ikke virker uden softwarehusets backend. En ejendomsadministrator spørger, om produktet er omfattet af Cyber Resilience Act.

Softwarehuset konkluderer efter rådgivning, at applikationen er et produkt med digitale elementer, og at backend kan være dens fjerndatabehandlingsløsning. Det svarer kunden, at vurderingen er foretaget, at rapportering om aktivt udnyttede sårbarheder er sat i system, og at den årlige pentest nu også omfatter applikationen. Webportalen alene behandles fortsat som en cloudtjeneste.

Det skal I lade være med

Antage, at alt med software er omfattet · rene cloudtjenester kan falde uden for.
Antage, at intet før december 2027 er relevant · rapporteringspligten gælder fra september 2026.
Kalde et pentestfund en aktivt udnyttet sårbarhed · pligten gælder sårbarheder, der faktisk udnyttes.
Love kunden overensstemmelse · vurderingen er jeres som fabrikant.
Glemme komponenter, der installeres hos kunden · de kan gøre jer til fabrikant af et produkt.

Hvad kan og ikke kan konkluderes

Forordningens tekst viser, hvem den retter sig mod, hvornår de enkelte dele gælder, og at regelmæssig afprøvning af sikkerheden er et af kravene til håndtering af sårbarheder. Den afgør ikke, om jeres produkt er omfattet, og en pentest viser ikke, at et produkt opfylder kravene. Kommissionen kan udstede vejledning, og den kan ændre forståelsen af enkelte punkter; tjek teksten og eventuel vejledning, før I svarer en kunde.

Kilder

Cyber Resilience Act, forordning (EU) 2024/2847: artikel 2, stk. 1 (anvendelsesområde), artikel 3, nr. 1 og 2 (produkt med digitale elementer og fjerndatabehandling), betragtning 12 (cloudløsninger og SaaS), artikel 14, stk. 1 til 4 (rapportering af aktivt udnyttede sårbarheder og alvorlige hændelser), artikel 69, stk. 2 og 3 (produkter bragt i omsætning før 11. december 2027), artikel 71 (anvendelse fra 11. december 2027, artikel 14 fra 11. september 2026) og bilag I, del II, punkt 3 (effektive og regelmæssige afprøvninger).
Styrelsen for Samfundssikkerhed: Cyber Resilience Act: dansk myndighedsside om forordningen; rapporteringspligt fra 11. september 2026 og anvendelse fra 11. december 2027.

Senest gennemgået: oktober 2026.