Smarte systemløsninger til danske virksomheder — siden 1999. Admind ERP, webshop, hosting og IT-service samlet ét sted.
Smarte systemløsninger til danske virksomheder — siden 1999. Admind ERP, webshop, hosting og IT-service samlet ét sted.
Siden 11. september 2026 har fabrikanter af produkter med digitale elementer skullet indberette aktivt udnyttede sårbarheder inden for 24 timer. Den 11. december 2027 må produktet slet ikke sælges i EU uden dokumenteret cybersikkerhed. Her er, hvad kravene betyder for en dansk virksomhed, der laver, mærker eller videresælger software og forbundne produkter.
Cyber Resilience Act er forordning (EU) 2024/2847. Den stiller cybersikkerhedskrav til alle “produkter med digitale elementer”, der bringes i omsætning i EU — både hardware og ren software. Rapporteringspligten har været gældende siden 11. september 2026, og de fulde krav gælder fra 11. december 2027.
Cyber Resilience Act (CRA) blev vedtaget den 23. oktober 2024, offentliggjort i EU-Tidende den 20. november 2024 og trådte i kraft den 10. december 2024. Det er en forordning, ikke et direktiv. Den skal altså ikke omskrives til dansk lov først — den gælder direkte, og den gælder ens i alle 27 medlemsstater.
Den mest almindelige misforståelse om CRA er, at den handler om hardware. Den gør den ikke. Forordningens artikel 3, nr. 1, definerer et produkt med digitale elementer som et software- eller hardwareprodukt, der kan forbindes direkte eller indirekte til en anden enhed eller et netværk. Ren software er omfattet. En app er omfattet. Et WordPress-plugin, som I sælger eller licenserer, er omfattet. Et abonnement på en integration, der sender ordrer fra webshoppen ind i økonomisystemet, er omfattet — og artikel 3, nr. 2, trækker også den fjerndatabehandling med ind, som produktet ikke kan fungere uden.
Den anden misforståelse er tidsplanen. Mange har noteret sig december 2027 og lagt emnet væk til næste år. Men som DKCERT skrev den 21. september 2026: “Den 11. september 2026 trådte således de første operationelle krav i kraft.” Den frist er altså ikke på vej. Den er passeret, mens de fleste danske virksomheder havde blikket rettet mod NIS2 og AI-forordningen.
CRA gælder ikke, hvor andre EU-regler allerede stiller tilsvarende krav. Medicinsk udstyr, luftfart og biler er de klassiske undtagelser, og produkter udviklet udelukkende til national sikkerhed eller forsvar falder også uden for. Fri og åben kildekode er en særlig kategori: at lægge kode i et offentligt repository er efter artikel 3, nr. 4, normalt ikke at “bringe i omsætning”, og derfor udløser det ikke fabrikantpligterne. Det ændrer sig i det øjeblik koden bliver en del af et kommercielt produkt, I sælger.
Hvis I har arbejdet med NIS2 som underleverandør, vil meget af tænkningen være genkendelig. Forskellen er vigtig: NIS2 stiller krav til virksomheden og dens drift. CRA stiller krav til produktet og følger det hele vejen gennem livscyklussen — fra design over levering til den dag supporten udløber.
CRA trådte i kraft 10. december 2024. Reglerne om bemyndigede organer har gældt siden 11. juni 2026, rapporteringspligten i artikel 14 siden 11. september 2026, og hele forordningen gælder fra 11. december 2027. Datoerne står i artikel 71.
Artikel 71 deler ikrafttræden op i fire trin. Det er værd at læse dem i rækkefølge, for de tre første er allerede sket, og det er kun den sidste, der stadig kan planlægges efter.
| Dato | Hvad træder i kraft | Hvem mærker det |
|---|---|---|
| 10. december 2024 | Forordningen træder i kraft (artikel 71, stk. 1): 20 dage efter offentliggørelsen i EU-Tidende. | Ingen pligter endnu — men uret begynder at gå. |
| 11. juni 2026 | Kapitel IV, artikel 35-51: reglerne om bemyndigede organer og notifikation af dem. | Primært test- og certificeringsorganer, ikke almindelige virksomheder. |
| 11. september 2026 | Artikel 14: indberetning af aktivt udnyttede sårbarheder og alvorlige hændelser. | Alle fabrikanter. Også dem, der endnu ikke har CE-mærket noget. |
| 11. december 2027 | Resten af forordningen: de væsentlige krav i bilag I, overensstemmelsesvurdering, CE-mærkning, teknisk dokumentation, supportperiode. | Alle, der bringer produkter i omsætning i EU. |
Der er altså omkring 14 måneder til den store frist. Det lyder rigeligt, indtil man regner baglæns: teknisk dokumentation, risikovurdering, en overensstemmelsesvurdering, der for nogle produkter kræver et tredjepartsorgan, og en supportpolitik, der binder virksomheden i mindst fem år frem. Den slags skal ligge klar før produktet må sælges — ikke bagefter.
Artikel 26 forpligter Kommissionen til at udsende vejledning, og den kom den 27. juli 2026 som C(2026) 5252. Den er ikke bindende, men den er den bedste kilde til, hvordan reglerne skal forstås i praksis: 67 konkrete eksempler, brugsscenarier og flowdiagrammer, med særlig opmærksomhed på mikrovirksomheder og små og mellemstore virksomheder. Den behandler blandt andet fjerndatabehandling, åben kildekode, hvad der udgør en “væsentlig ændring” efter artikel 3, nr. 30, og hvordan supportperioden skal fastsættes.
Siden 11. september 2026 skal en fabrikant indberette en aktivt udnyttet sårbarhed eller en alvorlig hændelse til koordinator-CSIRT’en og ENISA samtidig. Tidlig varsling inden 24 timer, fuld underretning inden 72 timer, endelig rapport senest 14 dage efter en rettelse findes — eller en måned ved hændelser.
Artikel 14 er den del af CRA, der allerede er skarp. Den udløses af to ting: en aktivt udnyttet sårbarhed i produktet (artikel 14, stk. 1), og en alvorlig hændelse, der påvirker produktets sikkerhed (artikel 14, stk. 3). Begge skal indberettes samtidig til den koordinator-CSIRT, der hører til den medlemsstat, hvor fabrikanten har sit hovedforretningssted i EU, og til ENISA.
Det sker gennem én kanal. Europa-Kommissionen formulerer det sådan på sin side om CRA-rapportering: fabrikanten indberetter én gang via CRA Single Reporting Platform, som ENISA er pålagt at oprette efter artikel 16. Det er altså ikke en pligt til at ringe rundt til seks myndigheder — men det er en pligt til at have et sted i organisationen, hvor telefonen tages inden for et døgn.
| Trin | Frist | Hvad skal med |
|---|---|---|
| Tidlig varsling art. 14, stk. 2, litra a / stk. 4, litra a | Uden unødigt ophold, og under alle omstændigheder inden 24 timer efter at fabrikanten blev bekendt med forholdet | Ved hændelser: mindst om hændelsen mistænkes at skyldes ulovlige eller ondsindede handlinger. Hvor relevant: i hvilke medlemsstater produktet er gjort tilgængeligt. |
| Underretning art. 14, stk. 2, litra b / stk. 4, litra b | Inden 72 timer efter at fabrikanten blev bekendt med forholdet | Generelle oplysninger om produktet, karakteren af sårbarheden eller hændelsen, en første vurdering, de afhjælpende foranstaltninger, der er truffet, og hvad brugerne selv kan gøre. Hvor relevant: hvor følsomme oplysningerne vurderes at være. |
| Endelig rapport, sårbarhed art. 14, stk. 2, litra c | Senest 14 dage efter at en korrigerende eller afbødende foranstaltning er tilgængelig | Beskrivelse af sårbarheden, herunder alvor og konsekvens, oplysninger om en eventuel ondsindet aktør, hvor de findes, og detaljer om sikkerhedsopdateringen. |
| Endelig rapport, hændelse art. 14, stk. 4, litra c | Inden en måned efter underretningen på 72 timer | Detaljeret beskrivelse af hændelsen, den sandsynlige trusselstype eller grundårsag, og de afbødende foranstaltninger, der er gennemført og er i gang. |
Artikel 64, stk. 10, indeholder en lempelse, som er værd at kende, hvis I er en lille virksomhed: mikrovirksomheder og små virksomheder kan ikke pålægges bøde for at overskride netop fristerne i artikel 14, stk. 2, litra a, og stk. 4, litra a — altså de to 24-timers varslinger. Forvaltere af åben kildekode er helt undtaget fra bøder.
Læs det præcist: undtagelsen gælder bøden for den første frist. Pligten til at indberette består, 72-timers-underretningen og den endelige rapport er ikke undtaget, og markedsovervågningsmyndighedens øvrige redskaber — påbud, krav om afhjælpning, i sidste ende tilbagetrækning fra markedet — røres ikke. Undtagelsen er en stressventil for den første hektiske dag, ikke en fritagelse.
Efter artikel 21 anses en importør eller distributør som fabrikant i to tilfælde: hvis produktet sælges under eget navn eller varemærke, eller hvis det ændres væsentligt efter at være bragt i omsætning. Så gælder fabrikantpligterne i artikel 13 og 14 — herunder 24-timers-indberetningen.
Det er her, CRA bliver konkret for virksomheder, der aldrig har set sig selv som producenter. Artikel 21 har titlen “Tilfælde, hvor fabrikanters forpligtelser gælder for importører og distributører”, og den åbner med, at en importør eller distributør anses for at være en fabrikant i forordningens forstand. De to udløsere er:
Oversat til hverdagen i et dansk IT-hus eller en dansk webshop betyder det tre ting. For det første: videresælger I en router, en NAS eller et stykke smart home-udstyr i originalemballage fra en leverandør inden for EU, er I distributør og skal kontrollere, at produktet er CE-mærket og følges af den krævede dokumentation. For det andet: køber I samme produkt direkte fra en producent uden for EU, er I importør, og pligterne bliver væsentligt tungere. For det tredje: sætter I jeres eget mærke på det, eller flasher I ny firmware, før kunden får det, er I fabrikant — med alt hvad det indebærer, også døgnvagten i artikel 14.
Det samme mønster kender vi fra produktsikkerhedsreglerne. Da GPSR gjorde webshoppen ansvarlig for fabrikantoplysninger på produktsiden, var det netop ansvarskæden, der overraskede. CRA gør det samme — blot for cybersikkerheden, og med en indberetningspligt oveni.
Hvis I er fabrikant efter artikel 21, men ikke har skrevet en linje af koden, skal nogen levere jer det materiale, I skal kunne fremvise: risikovurdering, teknisk dokumentation, en SBOM over komponenterne, og en forpligtelse til at levere sikkerhedsopdateringer i hele supportperioden. Det skal stå i kontrakten med den egentlige producent, og det skal stå der nu — ikke i efteråret 2027, hvor forhandlingspositionen er væk. Samme øvelse som i en databehandleraftale med IT-leverandøren, bare med sikkerhedskrav i stedet for databeskyttelse.
De fleste produkter kan fabrikanten selv erklære overensstemmelse for. Vigtige produkter i bilag III klasse I og II og kritiske produkter i bilag IV kræver strengere procedurer, typisk et bemyndiget organ eller en EU-cybersikkerhedscertificering. Kategorierne er beskrevet teknisk i gennemførelsesforordning (EU) 2025/2392.
Artikel 7 og 8 opdeler produkterne, og artikel 32 fastsætter, hvilken vej til overensstemmelsesvurdering der så skal bruges. Den 28. november 2025 vedtog Kommissionen gennemførelsesforordning (EU) 2025/2392 om den tekniske beskrivelse af kategorierne — den er offentliggjort i EU-Tidende den 1. december 2025 og er det dokument, man skal slå op i, når man er i tvivl om, hvilken kasse et produkt falder i.
| Kategori | Eksempler fra 2025/2392 | Vej til overensstemmelse |
|---|---|---|
| Almindelige produkter | Alt, der ikke står i bilag III eller IV: de fleste apps, integrationer, branchesoftware, almindeligt forbundet udstyr. | Fabrikantens egen vurdering og EU-overensstemmelseserklæring. |
| Vigtige, klasse I bilag III | 18 kategorier, blandt andet identitetsstyring, browsere (selvstændige og indbyggede), passwordmanagere, antivirus, VPN, operativsystemer, routere og smart home-produkter. | Egen vurdering, hvis harmoniserede standarder er anvendt fuldt ud — ellers inddrages et bemyndiget organ. |
| Vigtige, klasse II bilag III | Hypervisorer og container-runtimes, firewalls samt systemer til indtrængningsdetektion og -forebyggelse, og manipulationssikre mikroprocessorer og mikrocontrollere. | Tredjepartsvurdering hos et bemyndiget organ. |
| Kritiske produkter bilag IV | Hardware security boxes, smart meter gateways, og smartcards eller tilsvarende enheder, herunder sikre elementer. | EU-cybersikkerhedscertificering, hvor en ordning findes. |
To regler i 2025/2392 er værd at holde fast i. Klassificeringen følger produktets væsentlige funktionalitet — altså hvad produktet i al væsentlighed er til for. Og det, at et produkt indeholder en komponent, som i sig selv hører under en kategori, gør ikke hele produktet vigtigt eller kritisk. En brancheløsning bliver ikke klasse II, fordi den har en firewall-komponent i sig. Men de væsentlige krav i bilag I skal stadig opfyldes for hele produktet.
For åben kildekode er der en lempelse i artikel 32, stk. 5: vigtige produkter, der er fri og åben software, kan følge lettere procedurer. Det er et af de punkter, Kommissionens vejledning fra juli 2026 bruger plads på.
Fabrikanten skal fastsætte en supportperiode, der afspejler, hvor længe produktet forventes at blive brugt — som udgangspunkt mindst fem år. Sikkerhedsopdateringer skal være tilgængelige i mindst ti år efter udstedelsen eller resten af supportperioden, og brugerne skal kende slutdatoen.
Supportperioden står i artikel 13, stk. 8, og den er en af de bestemmelser, der har størst praktisk konsekvens, fordi den binder virksomheden økonomisk mange år frem. Perioden skal afspejle produktets forventede brugstid. Advokatfirmaet Horten opsummerede det den 23. september 2026 som, at producenten skal understøtte sårbarhedshåndtering i mindst fem år, og at en sikkerhedsopdatering skal være tilgængelig i den længste af supportperioden eller ti år efter udgivelsen.
To tilstødende regler gør det håndterbart i praksis. Artikel 13, stk. 10, tillader under visse betingelser, at sårbarheder kun afhjælpes i den seneste version — I behøver altså ikke patche fem årgange parallelt. Og artikel 13, stk. 19, kræver, at I oplyser brugerne om, hvornår supporten slutter, og varsler dem, når datoen nærmer sig. Det er den samme øvelse, mange virksomheder lige har været igennem, da Windows 10 mistede sin support — blot er det nu jer, der skal udmelde datoen til jeres egne kunder.
Artikel 64 har tre bødeniveauer: op til 15 mio. euro eller 2,5 % af den globale årsomsætning for brud på bilag I og artikel 13 og 14, op til 10 mio. euro eller 2 % for en række andre pligter, og op til 5 mio. euro eller 1 % for urigtige oplysninger til myndigheder. Det højeste af beløb og procent gælder.
Bødestrukturen i artikel 64 ligger tæt på den, man kender fra GDPR: et fast maksimum og en procentsats af den samlede globale årsomsætning i det forudgående regnskabsår, hvor det højeste af de to anvendes, og hvor procentsatsen kun bruges, hvis overtræderen er en virksomhed.
| Niveau | Maksimum | Gælder for |
|---|---|---|
| Artikel 64, stk. 2 | 15 mio. EUR eller 2,5 % af global årsomsætning | De væsentlige cybersikkerhedskrav i bilag I samt fabrikantens pligter i artikel 13 og indberetningspligten i artikel 14. |
| Artikel 64, stk. 3 | 10 mio. EUR eller 2 % | En række øvrige forpligtelser, blandt andet artikel 18-23 (herunder importører og distributører), 28, 30, 31, 32, 33, 39, 41, 47, 49 og 53. |
| Artikel 64, stk. 4 | 5 mio. EUR eller 1 % | At give urigtige, ufuldstændige eller vildledende oplysninger til bemyndigede organer eller markedsovervågningsmyndigheder som svar på en anmodning. |
| Artikel 64, stk. 10 | Ingen bøde | Mikrovirksomheder og små virksomheder for fristerne i artikel 14, stk. 2, litra a, og stk. 4, litra a. Forvaltere af åben kildekode er helt undtaget. |
Tænketanken Europa opgjorde i sin analyse af CRA den 30. april 2026 niveauet som op til 15 mio. euro eller 2,5 % af den globale årsomsætning afhængigt af overtrædelsens karakter — altså i overensstemmelse med forordningens ordlyd.
Her skal vi være ærlige: det er ikke oplyst i de kilder, vi har kunnet finde. CRA pålægger medlemsstaterne at udpege markedsovervågningsmyndigheder, men regeringens grund- og nærhedsnotat til Folketingets Europaudvalg af 18. november 2022 anførte, at det “endnu ikke [er] besluttet, hvordan forslaget skal implementeres, og hvordan myndighedsopgaverne skal fordeles”. Vi har ikke fundet en offentliggjort dansk udpegning siden.
Det ændrer ikke jeres pligt. Indberetningen går under alle omstændigheder gennem EU’s fælles indberetningsplatform til koordinator-CSIRT’en i den medlemsstat, hvor virksomheden har sit hovedforretningssted — og til ENISA samtidig. DKCERT henviser på samme måde til de nationale CSIRT-enheder og ENISA via Single Reporting Platform. Så den praktiske forberedelse er den samme, uanset hvilken dansk styrelse der ender med tilsynet.
“Den 11. september 2026 trådte således de første operationelle krav i kraft.”Eskil Sørensen, DKCERT, 21. september 2026
Start med at kortlægge, hvilke af jeres produkter der er omfattet, og i hvilken rolle: fabrikant, importør eller distributør. Derefter etableres indberetningsberedskabet, som allerede er påkrævet, og først bagefter bygges dokumentationen og overensstemmelsesvurderingen.
Rækkefølgen betyder meget. De fleste begynder med dokumentationen, fordi den er den synlige del — men det er indberetningsberedskabet, der er i restance lige nu.
Trin 4 er det, der haster, og det er også det, der oftest afslører et hul i dokumentationen: man kan ikke vurdere, om en ny sårbarhed er “aktivt udnyttet” i jeres produkt, hvis ingen ved, hvilke komponenter produktet består af. Derfor hænger SBOM’en og døgnvagten sammen. Og er I i forvejen ved at dokumentere sikkerhed til et forsikringsselskab, er der meget at genbruge: kravene i cyberforsikringens sikkerhedskrav overlapper i vid udstrækning med bilag I, del 2.
Vores guide til leverandørtjek giver jer de spørgsmål, I skal stille jeres IT-leverandører om sikkerhed, dokumentation og opdateringer. Det er det samme materiale, I skal have på plads til CRA. Udfyld med din mail, så sender vi den med det samme.
Vi sender guiden og højst et par relevante opfølgninger. Ingen videregivelse til tredjepart.
Vi er et dansk IT-hus med over 25 års erfaring i at bygge og drive løsninger for små og mellemstore virksomheder: økonomisystemer, webshops, ordrestyring, hosting og sikkerhed. Vi kigger med på produktlisten, afgrænser, hvad CRA faktisk rammer hos jer, og laver en plan frem mod december 2027 — i den rækkefølge, der giver mening.
“Vi sparer det, der svarer til en hel arbejdsdag om ugen på administration.”
Westwind, Admind-kunde i over 10 årJa. Artikel 3, nr. 1, omfatter software- og hardwareprodukter, der kan forbindes direkte eller indirekte til en anden enhed eller et netværk, og artikel 3, nr. 2, trækker den fjerndatabehandling med ind, som produktet ikke kan fungere uden. En leveringsform som abonnement ændrer ikke, at der bringes et produkt i omsætning i EU.
Nej, ikke fra kravene. Der er to lempelser: artikel 64, stk. 10, betyder, at mikrovirksomheder og små virksomheder ikke kan få bøde for at overskride de to 24-timers-frister i artikel 14, og Kommissionens vejledning fra juli 2026 er skrevet med særligt henblik på små virksomheder. Selve pligterne — de væsentlige krav, dokumentationen og indberetningen — gælder uanset størrelse.
Så er I distributør og skal kontrollere, at produktet er CE-mærket og ledsaget af den krævede dokumentation, før det gøres tilgængeligt. Køber I direkte fra en producent uden for EU, er I importør med tungere pligter. Sætter I jeres eget navn eller varemærke på, anses I efter artikel 21 for fabrikant.
Artikel 3, nr. 30, definerer den ud fra, om ændringen påvirker produktets cybersikkerhedsrisiko — ikke ud fra omfanget af koden. En opdatering, der lukker et hul, er normalt ikke en væsentlig ændring. En ny funktion, der åbner en netværksflade, kan være det. Kommissionens vejledning C(2026) 5252 har eksempler på begge.
Den skal afspejle, hvor længe produktet forventes at blive brugt, og som udgangspunkt mindst fem år. Sikkerhedsopdateringer skal være tilgængelige i mindst ti år efter udstedelsen eller i resten af supportperioden, hvis den er længere. Efter artikel 13, stk. 19, skal brugerne kende slutdatoen og varsles, når den nærmer sig.
Indberetningen sker én gang via EU’s fælles indberetningsplatform til koordinator-CSIRT’en i den medlemsstat, hvor virksomheden har sit hovedforretningssted i EU, og samtidig til ENISA. Hvilken dansk styrelse der fører markedsovervågningen, har vi ikke kunnet finde en offentliggjort udpegning af; regeringens notat fra 2022 anførte, at fordelingen af myndighedsopgaverne ikke var besluttet.
At lægge kode i et offentligt repository er efter artikel 3, nr. 4, normalt ikke at bringe produktet i omsætning, og udløser derfor ikke fabrikantpligterne. Forvaltere af åben kildekode er desuden undtaget fra bøder efter artikel 64, stk. 10, og artikel 32, stk. 5, giver lettere procedurer for vigtige produkter, der er fri og åben software. Indgår komponenten i et kommercielt produkt, I sælger, er det jeres ansvar.
NIS2 stiller krav til virksomhedens egen drift og styring af sikkerhed. CRA stiller krav til produktet og følger det gennem livscyklussen. I praksis mødes de i leverandørkæden: en NIS2-omfattet kunde vil bede om CRA-dokumentation, CE-mærkning og en supportperiode, længe før myndighederne banker på.
En time sammen med os giver jer produktlisten, rollefordelingen og en prioriteret plan. Og en afklaring af, om indberetningsberedskabet, der allerede er krav, er på plads.