Overalt i EU er man i gang med at rulle Cyber Resilience Act ud. Derfor har vi lavet en samlet guide til forordningen for beslutningstagere i virksomheder med digitale produkter.
I årevis har cybersikkerhed i produkter fungeret lidt som brandsikkerhed i gamle bygninger: alle vidste, at det var et problem, men kun få tog det alvorligt. Producenter sendte produkter på markedet med kendte sikkerhedshuller, opdateringerne stoppede efter et par år, og ansvaret for konsekvenserne havnede altid hos brugeren.
Det er det mønster, EU nu bryder med.
Cyber Resilience Act (CRA) indfører på EU-plan bindende, horisontale cybersikkerhedskrav til produkter med digitale elementer, der bringes i omsætning på EU-markedet. Forordning (EU) 2024/2847 trådte i kraft den 10. december 2024. Uanset om du producerer industrielt udstyr, forbrugerelektronik eller software, fastsætter CRA grundlæggende krav til produkternes cybersikkerhed gennem hele deres livscyklus.
Timingen er ikke tilfældig. Europa har i de seneste år set en markant stigning i cyberangreb rettet mod sårbare produkter og komponenter. Ifølge ENISA, EU's cybersikkerhedsagentur, stammer en stor del af vellykkede angreb fra kendte sårbarheder, der aldrig blev rettet. Som modsvar stiller CRA krav om, at sikkerhed bliver bygget ind fra starten, i stedet for at patche lappeløsninger på bagkant.
For virksomheder, der sælger til det europæiske marked, er CRA allerede en realitet – uanset om de er hjemmehørende i EU eller ej. Forpligtelserne i CRA træder i kraft over en længere periode, men de første er gældende allerede fra juni 2026, og flere kommer til frem mod december 2027, hvor forordningen gælder i sin helhed.
Vi har derfor samlet alt, hvad du skal vide om Cyber Resilience Act lige her i denne artikel, og er du stadig i tvivl, når du er færdig med den, er vores konsulenter klar til at hjælpe dig på vej.
Vi gennemgår:
CRA gælder som udgangspunkt for virksomheder, der fremstiller, importerer eller distribuerer produkter med digitale elementer på EU-markedet som led i en kommerciel aktivitet. Det lyder måske snævert, men anvendelsesområdet er bredt. Det omfatter hardware og software, hvis tilsigtede eller rimeligt forudsigelige brug indebærer en direkte eller indirekte dataforbindelse til en enhed eller et netværk.
Loven skelner mellem tre typer aktører, som alle har forpligtelser:
Producenter er dem, der designer og bringer produktet på markedet under eget navn eller varemærke. De har de mest omfattende forpligtelser og er omdrejningspunktet for CRA. Hvis du udvikler og sælger software, er du producent i lovens forstand – det gælder uanset om produktet er et stykke hardware, en app eller en softwarepakke.
Importører er virksomheder etableret i EU, der bringer produkter fra producenter uden for EU på markedet. Importøren overtager en del af producentens ansvar, hvis producenten ikke er EU-baseret.
Distributører er alle andre i forsyningskæden, der gør produkter tilgængelige på markedet. De har færre forpligtelser end producenter og importører, men er ikke fritaget – de skal bl.a. sikre, at produkter er korrekt mærket og ledsaget af den nødvendige dokumentation.
Det er det kritiske spørgsmål, som mange overser, og svaret er mere nuanceret end man måske kunne have håbet. Ren SaaS, der alene leverer en tjeneste via en browser, er ikke automatisk omfattet. Men hvis din software er en integreret del af et produkt – eller hvis din cloud-løsning er nødvendig for, at et produkt overhovedet fungerer – er du sandsynligvis i scope.
Det dækker det, vejledningen kalder Remote Data Processing Solutions (RDPS): software, der behandler data på afstand som en forudsætning for, at et produkt med digitale elementer kan udføre en af sine funktioner. Det gælder ikke kun kernefunktionen - også støtte- og ekstrafunktioner tæller med. Har din smarte dørlås fx en cloud-tjeneste, der udelukkende sender en notifikation, når nogen låser døren op, er den cloud-tjeneste stadig omfattet af CRA, selvom selve låsningen fungerer helt uden den.
Et konkret eksempel er en mobilapp til en smart-termostat: appen er ikke et produkt i sig selv, men er uløseligt knyttet til produktet og dermed i scope under CRA. Det samme gælder backend-systemer, API-lag og analyseplatforme, der er designet og udviklet af producenten som en del af et produkts funktionalitet.
Sælger du open source-software? Også her er CRA relevant, men reglerne er anderledes. Er din open source-software gratis og ikke-kommerciel, er du typisk ikke producent i CRA's forstand – men fungerer du som vedligeholder (steward) af et open source-projekt, som andre virksomheder bygger kommercielle produkter på, har du alligevel forpligtelser.
Og hvis din virksomhed integrerer open source-komponenter i sine egne produkter, er det dit ansvar at sikre, at de opfylder kravene.
Så hvad betyder det?
Jo. Hvis din virksomhed udvikler software, sælger produkter med netværksforbindelser eller leverer digitale komponenter, der indgår i andres produkter, bør du afsætte tid til at afklare din status under CRA. Udgangspunktet er ikke, om du mener at være en "teknologivirksomhed" – men hvad dit produkt faktisk gør.
CRA stiller krav i hele produktets livscyklus: fra designfasen til det tidspunkt, hvor produktet trækkes tilbage fra markedet. For mange producenter er det den største omstilling, et produkt er ikke "done" i lovens øjne, bare fordi det er sendt ud ad døren.
For at gøre kravene nemmere at overskue, kan vi strukturere dem i fem overordnede kategorier:
Det mest fundamentale krav er, at produkter skal designes og udvikles med cybersikkerhed som et integreret hensyn fra starten.
Det betyder konkret:
Princippet hedder security by design, og det er et opgør med den hidtidige praksis, hvor sikkerhed typisk blev behandlet som en feature, der kunne tilføjes senere.
Producenter skal gennemføre en cybersikkerhedsrisikovurdering af deres produkt og holde den opdateret gennem hele produktets levetid. Risikovurderingen er fundamentet for alt det øvrige: klassificering, conformity assessment og dokumentation.
Samtidig skal der udarbejdes teknisk dokumentation, der viser, hvordan produktet opfylder lovens væsentlige krav. Denne dokumentation skal opbevares i hele supportperioden, dog mindst 10 år efter at produktet er bragt på markedet.
CRA pålægger producenter en løbende forpligtelse til aktivt at overvåge, identificere og håndtere sårbarheder i deres produkter.
Det inkluderer at have en politik for koordineret sårbarhedsvideregivelse, at teste produktet regelmæssigt, at distribuere sikkerhedsopdateringer hurtigt og at videreformidle information om sårbarheder til relevante myndigheder og brugere.
Fra den 11. september 2026 gælder der skarpe rapporteringsfrister. Hvis en producent opdager en aktivt udnyttet sårbarhed i sit produkt, skal det indberettes til den nationale CSIRT inden 24 timer.
CSIRT (Computer Security Incident Response Team) er det nationale kontaktpunkt, der herefter deler informationen med ENISA og myndighederne i de øvrige berørte lande via ENISAs fælles indberetningsplatform. En mere detaljeret rapport følger inden 72 timer.
Er der tale om en hændelse med væsentlig indvirkning på sikkerheden, skal en endelig rapport afleveres senest én måned efter den første 72-timers notifikation. Den endelige sårbarhedsrapport skal derimod være indsendt efter kun 14 dage, regnet fra det tidspunkt, hvor en rettelse er tilgængelig.
Fristerne er stramme og kræver, at virksomheden har processer på plads, inden en hændelse sker. Det er ikke noget, man improviserer sig ud af, når ulykken er ude.
Et af de mest undervurderede krav i CRA er supportperioden. Producenter er forpligtet til at fastlægge og kommunikere en konkret supportperiode for hvert produkt. Denne periode skal endvidere som udgangspunkt være mindst fem år.
I løbet af den erklærede periode skal producenten levere sikkerhedsopdateringer. Slutdatoen for support skal være synlig for køber ved anskaffelsen (mindst måned og år), og når supportperioden udløber, skal brugerne adviseres herom.
Vær opmærksom på, at fem år er et minimum. Hvis du sælger et produkt med en realistisk levetid på ti år, er det den, og altså ikke fem år, der er udgangspunktet for supportperioden.
For software, der opdateres løbende og frigiver nye versioner, er der en vis fleksibilitet. Du kan i visse tilfælde nøjes med at patche den seneste version, forudsat at brugere kan opgradere gratis og uden at skulle afholde ekstraomkostninger som ny hardware eller fundamentale infrastrukturændringer.
Ikke alle produkter er underlagt de samme krav. CRA opererer, udover de grundlæggende krav, med tre niveauer. Og det er hverken branche, virksomhedsstørrelse eller salgsvolumen, der afgør, hvor produktet hører hjemme.
Det er i stedet dit produkts kernefunktionalitet.
Standardprodukter udgør langt størstedelen af alle produkter med digitale elementer. Til denne kategori hører produkter, hvis kernefunktionalitet ikke falder inden for de særligt definerede klasser. Standardprodukter er underlagt lovens grundlæggende krav og kan som udgangspunkt gennemføre intern kontrol (self-assessment) som conformity assessment-procedure.
Vigtige produkter – klasse I er produkter med funktioner, der kan udgøre en forhøjet sikkerhedsrisiko. Det inkluderer bl.a. password managers, produkter med VPN-funktionalitet, netværksstyringssoftware, SIEM-systemer og industristyringssystemer. For klasse I-produkter kan intern kontrol stadig benyttes, men kun hvis producenten fuldt ud anvender relevante harmoniserede standarder. Gør man det ikke, kræves tredjepartsvalidering.
Vigtige produkter – klasse II omfatter produkter med særligt kritiske funktioner: hypervisors og container runtime-systemer, der understøtter virtualiseret afvikling af operativsystemer, firewalls, systemer til indtrængningsdetektion og -forebyggelse (IDS/IPS) samt tamper-resistente mikroprocessorer og mikrocontrollere. Her er tredjepartscertificering obligatorisk.
Kritiske produkter er en snæver kategori forbeholdt infrastrukturkomponenter som hardware-sikkerhedsmoduler (HSM), smart-card-chips og smart meter gateways (intelligente målere). For disse gælder de strengeste krav.
EU-vejledningen indeholder et eksempel, som egentlig illustrerer logikken i niveaudelingen ganske godt:
I praksis betyder det, at en platform med fem moduler godt kan have fem forskellige conformity assessment-krav, og at du ikke kan klassificere dig ud af det ved at kalde det ét samlet produkt.
CRA indfases over tre år. Ikke fordi EU tøver, men fordi producenter, importører og myndigheder alle skal nå at forberede sig. Her er de fire afgørende milepæle, du bør være opmærksom på:
Skal du overholde flere standarder og forordninger? Så læs med her: CRA vs. AI Act vs. GDPR vs. DORA vs. ISO 27001 – få overblik over overlap og forskelle
EU mener CRA alvorligt, og ligesom med GDPR og AI Act er der mærkbare sanktioner, hvis man ikke overholder kravene.
Den alvorligste overtrædelseskategori, defineret som manglende overholdelse af de væsentlige sikkerhedskrav, kan udløse bøder på op til 15 mio. Euro eller 2,5 % af virksomhedens globale årsomsætning, alt efter hvad der er størst.
Ved brud på øvrige forpligtelser, herunder mangelfuld dokumentation eller mærkning, er grænsen 10 mio. Euro eller 2 % af global omsætning. Afgivelse af ukorrekte oplysninger til myndigheder kan koste op til 5 mio. Euro eller 1 % af global omsætning, alt efter hvad der er størst.
Ud over bøder kan markedsovervågningsmyndigheder kræve, at et produkt trækkes tilbage fra markedet, eller forbyde det at blive solgt, så længe det ikke er i overensstemmelse med kravene.
Det er en konsekvens, der kan ramme forretningen langt hårdere end selve bøden.
En vigtig pointe: håndhævelsen sker nationalt. Hver EU-medlemsstat har sin egen markedsovervågningsmyndighed med beføjelse til at handle over for produkter, der sælges på det pågældende marked – også uafhængigt af hinanden.
Sælger du i flere EU-lande, kan du i princippet stå over for sanktioner i flere jurisdiktioner for det samme produkt. Det kan med andre ord blive vanvittigt dyrt ikke at overholde reglerne.
CRA kan virke uoverskueligt, men den praktiske tilgang er mere håndterbar end lovteksten antyder. Det handler om at anlægge en systematisk tilgang og stille de rigtige spørgsmål.
Kortlæg din eksponering.
Det første skridt er at identificere, hvilke af dine produkter der er i scope, og om nogen af dem tilhører de vigtigere kategorier. Her er produktinventar og en simpel klassificeringsøvelse baseret på kernefunktionalitet et godt udgangspunkt.
Vurder dine gaps.
Målt mod CRA's væsentlige krav: Har dine produkter en dokumenteret risikovurdering? Er der processer for vulnerability handling? Er supportperioden fastlagt og kommunikeret? Mange virksomheder opdager her, at de allerede har dele af fundamentet på plads, men at der er huller i dokumentationen og processerne.
Den rette GRC-platform kan samle dokumenter, planer, procesbeskrivelser og risikovurderinger ét sted: Se mere om Connected Compliance her
Prioritér artikel 14.
Indberetningsforpligtelserne gælder fra september 2026. De kræver, at der er et internt setup klar til at håndtere og eskalere sikkerhedshændelser inden for 24 timer. Det er en operationel forandring, der ikke skabes fra den ene dag til den anden.
Integrér CRA i din bredere GRC-ramme.
Behandl ikke CRA som et engangsprojekt. Forpligtelserne er løbende – risikovurderinger skal opdateres, dokumentation skal vedligeholdes, sårbarheder skal håndteres aktivt. Det kræver processer og ansvarlige ejere, ikke blot en engangs-compliance-indsats.
Er du i tvivl om, hvilke af jeres produkter der er omfattet, eller hvor de vigtigste huller findes? NorthGRCs konsulenter kan hjælpe jer med at kortlægge jeres CRA-eksponering, vurdere jeres nuværende parathed og omsætte kravene til en konkret plan.
Tal med en af vores konsulenter