VEJLEDNING: CRA krav til danske virksomheder med mange misforståelser
CRA krav til danske virksomheder
Der er opstået en misforståelse om ISO-certificeringer og EN IEC 62443, fordi mange omtaler standarderne som om de allerede er lovpligtige CRA-certificeringer. Det er ikke korrekt. EU’s Cyber Resilience Act bliver en af de mest indgribende produktregler for danske virksomheder, der udvikler, importerer, distribuerer eller sælger software og hardware med digitale elementer. Reglerne flytter cybersikkerhed fra frivillig it-governance til et produktretligt krav, hvor sikkerhed skal dokumenteres før markedsføring og opretholdes gennem produktets levetid. For danske virksomheder betyder det, at software, IoT-enheder, industrielle controllere, firmware, apps, netværksudstyr og digitale komponenter skal vurderes langt tidligere i produktudviklingen. Det skriver AORS.DK, Europa-Parlamentet, Rådet for Den Europæiske Union, EUR-Lex og Europa-Kommissionen.
Hvad er Cyber Resilience Act
Cyber Resilience Act, forkortet CRA, er Europa-Parlamentets og Rådets forordning (EU) 2024/2847 af 23. oktober 2024 om horisontale cybersikkerhedskrav til produkter med digitale elementer.
Forordningen gælder direkte i alle EU-lande, herunder Danmark. Det betyder, at danske virksomheder ikke skal vente på en almindelig dansk implementeringslov for at forstå hovedpligterne. Der kan dog komme nationale regler om myndighedsforankring, markedsovervågning og sanktioner, men de materielle produktkrav følger af EU-forordningen.
Brug for advokat, revisor eller international rådgivning?
Kontakt vores danske specialister direkte på et af vores kontorer:
Advokat og Revisor Samvirket – Professionel rådgivning siden 1991
CRA retter sig mod produkter med digitale elementer. Det omfatter både hardware og software, når produktet har en direkte eller indirekte datalogisk forbindelse til en enhed eller et netværk. Det kan være alt fra routere, kameraer, IoT-produkter, apps og operativsystemer til firmware, industrielle automationssystemer, embedded software, softwarekomponenter og visse fjernbehandlingsløsninger, når de er nødvendige for produktets funktion.
Reglerne skal sikre, at digitale produkter på EU-markedet har færre sårbarheder, at producenter tager ansvar for sikkerheden gennem produktets levetid, og at brugere får bedre information om sikkerhedsopdateringer, supportperiode og kendte risici.
CRA er derfor ikke blot en it-regel. Den er en markedsadgangsregel. Hvis et produkt med digitale elementer ikke opfylder kravene, kan virksomheden få problemer med lovligt at bringe produktet i omsætning i EU.
Hvornår træder CRA i kraft
CRA er allerede trådt i kraft, men reglerne indfases i flere trin. Det giver virksomheder en overgangsperiode, men ikke en sovepude. For produkter, der udvikles nu og forventes solgt i 2027 eller senere, bør CRA behandles som et aktivt krav allerede i udviklingsfasen.
| Dato | Betydning | Praktisk konsekvens for danske virksomheder |
|---|---|---|
| 10. december 2024 | CRA trådte i kraft | Virksomheder bør allerede nu kortlægge produkter, roller, ansvar og compliance-gap |
| 11. juni 2026 | Regler om notificerede overensstemmelsesvurderingsorganer finder anvendelse | Tredjepartsorganer kan få betydning for visse produkter og overensstemmelsesvurderinger |
| 11. september 2026 | Rapporteringspligter efter artikel 14 finder anvendelse | Producenter skal kunne rapportere aktivt udnyttede sårbarheder og alvorlige hændelser |
| 2026 | Europæiske standardiseringsarbejder fortsætter | Virksomheder bør følge harmoniserede standarder, men må ikke forveksle dem med lovkrav om bestemte certificeringer |
| 11. december 2027 | CRA finder fuldt anvendelse | Produkter med digitale elementer skal som udgangspunkt opfylde kravene for lovligt at kunne markedsføres i EU |
Hvem bliver ramt af CRA?
CRA rammer ikke kun klassiske it-virksomheder. Den rammer hele forsyningskæden for digitale produkter. Producenter får de mest omfattende forpligtelser. En producent er ikke kun den virksomhed, der fysisk fremstiller et produkt. En virksomhed kan også være producent, hvis den udvikler, får udviklet, fremstiller, får fremstillet eller markedsfører et produkt under eget navn eller varemærke.
Importører får en kontrolpligt, når produkter fra tredjelande bringes ind på EU-markedet. Importøren skal blandt andet sikre, at produktet opfylder CRA’s krav, at producenten har gennemført relevant overensstemmelsesvurdering, og at produktet er korrekt mærket og dokumenteret. Distributører får også selvstændige pligter. De skal udvise fornøden omhu og må ikke bringe produkter videre på markedet, hvis de ved eller burde vide, at produktet ikke opfylder kravene.
For danske virksomheder betyder det, at mange virksomheder kan blive omfattet, selv om de ikke opfatter sig selv som softwareproducenter. En virksomhed, der sælger et fysisk produkt med embedded software, kan blive omfattet. En virksomhed, der importerer netværksudstyr, kan blive omfattet. En virksomhed, der får udviklet en digital løsning under eget brand, kan blive omfattet.
Produkter der typisk skal vurderes
| Produkttype | Eksempler | Typisk CRA-relevans |
|---|---|---|
| Software | Apps, operativsystemer, desktopprogrammer, softwarekomponenter | Omfattet, hvis softwaren markedsføres som produkt med digitalt element |
| Hardware | Routere, kameraer, sensorer, controllere, gateways | Omfattet, når produktet kan forbindes direkte eller indirekte til netværk eller enheder |
| IoT | Smart home, smart building, wearables, måleudstyr | Høj relevans, fordi produkterne ofte har fjernadgang, cloudintegration og lang levetid |
| Industri og OT | PLC’er, SCADA-komponenter, industrielle controllere, edge-enheder | Kan være omfattet, hvis produktet er et produkt med digitale elementer |
| Komponenter | Firmware, biblioteker, moduler, sikkerhedskomponenter | Kan være omfattet, hvis komponenten bringes separat på markedet |
| Cloudnære funktioner | Fjernbehandling, remote data processing, backendfunktioner | Kan være omfattet, hvis funktionen er nødvendig for produktets funktion |
De centrale krav i CRA
CRA bygger på et princip om sikkerhed gennem hele produktets livscyklus. Det er ikke nok at lave en penetrationstest kort før lancering. Sikkerheden skal tænkes ind i design, udvikling, produktion, dokumentation, markedsføring, drift, opdatering og udfasning.
Danske virksomheder bør især fokusere på følgende krav:
| Kravområde | Hvad betyder det i praksis |
|---|---|
| Secure by design | Produktet skal udvikles med et passende cybersikkerhedsniveau fra begyndelsen |
| Secure by default | Standardindstillinger må ikke skabe unødvendige sikkerhedsrisici |
| Risikovurdering | Producenten skal vurdere cybersikkerhedsrisici ud fra produktets tilsigtede og rimeligt forudsigelige brug |
| Sårbarhedshåndtering | Der skal være processer for modtagelse, vurdering, afhjælpning og offentliggørelse af sårbarheder |
| Sikkerhedsopdateringer | Produktet skal kunne opdateres, og brugere skal informeres om opdateringer og supportperiode |
| Teknisk dokumentation | Virksomheden skal kunne dokumentere design, risici, sikkerhedskrav, test, vurderinger og overensstemmelse |
| CE-mærkning | Produkter, der er omfattet, skal kunne CE-mærkes efter relevant overensstemmelsesvurdering |
| Rapportering | Aktivt udnyttede sårbarheder og alvorlige hændelser skal rapporteres efter artikel 14 |
| Forsyningskæde | Producenten skal have styr på komponenter, afhængigheder og leverandører |
| Brugerinformation | Brugere skal have klar information om sikker brug, opdateringer og forventet supportperiode |
Rapportering fra 11. september 2026
Fra 11. september 2026 gælder CRA’s rapporteringspligter efter artikel 14. Producenter skal herefter kunne rapportere aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker produktets sikkerhed.
Det kræver, at virksomheden ikke alene har en teknisk beredskabsplan, men også en juridisk og organisatorisk hændelsesproces. Det skal være klart, hvem der vurderer hændelsen, hvem der beslutter rapportering, hvem der kommunikerer til myndigheder og brugere, og hvordan virksomheden dokumenterer sine vurderinger.
For danske virksomheder vil dette i praksis kræve et samspil mellem it-sikkerhed, udvikling, ledelse, juridisk funktion, kundeservice og kommunikation. Hvis virksomheden har kunder i kritiske sektorer, bør rapporteringsprocessen også afstemmes med NIS2, kontraktkrav og eventuelle databeskyttelsesretlige anmeldelsespligter efter GDPR.
Ingen generelt krav om ISO-certificering eller IEC 62443-certificering
Der er i markedet opstået en væsentlig misforståelse om CRA. Mange skriver eller antyder, at virksomheder skal være ISO/IEC 27001-certificerede eller IEC 62443-certificerede for at opfylde Cyber Resilience Act. Det er ikke korrekt.
Det beror på en sammenblanding af tre forskellige niveauer:
| Niveau | Hvad det er | Juridisk betydning |
|---|---|---|
| CRA | Bindende EU-forordning | Fastlægger de retlige krav til produkter med digitale elementer |
| Harmoniserede europæiske standarder | Tekniske standarder, som kan understøtte dokumentation | Kan give formodning for overensstemmelse, hvis de er relevante og offentliggjort korrekt |
| ISO/IEC 27001 og EN IEC 62443 | Ledelses- og tekniske standarder | Kan være nyttige dokumentationsværktøjer, men er ikke i sig selv generelle CRA-certificeringskrav |
CRA kræver ikke som generel regel, at en dansk virksomhed skal have ISO/IEC 27001-certificering. CRA kræver heller ikke som generel regel, at en dansk virksomhed skal have IEC 62443-certificering.
Det afgørende er derfor ikke, om virksomheden kan fremvise et bestemt certifikat. Det afgørende er, om det konkrete produkt med digitale elementer opfylder forordningens væsentlige cybersikkerhedskrav, og om virksomheden kan dokumentere dette gennem risikovurdering, teknisk dokumentation, sårbarhedshåndtering, overensstemmelsesvurdering, CE-mærkning og relevante processer.
Hvorfor mange misforstår IEC 62443 og CRA
Mange rådgivere, standardiseringsmiljøer og cybersikkerhedsleverandører omtaler i øjeblikket IEC 62443 som om standarden allerede er et egentligt krav under Cyber Resilience Act. Det beror efter vores vurdering på en misforståelse.
Misforståelsen skyldes blandt andet, at IEC 62443 er en vigtig teknisk standardserie for industrielle automations- og kontrolsystemer, og at europæiske standardiseringsorganer arbejder med harmoniserede standarder, der skal understøtte CRA. Det gør imidlertid ikke IEC 62443 til et generelt lovkrav efter CRA.
Den samme misforståelse kan opstå, når ISO/IEC 27001 omtales som om en informationssikkerhedscertificering i sig selv opfylder CRA. Det gør den ikke! ISO/IEC 27001 dokumenterer et ledelsessystem for informationssikkerhed. CRA kræver derimod en produktspecifik vurdering af produkter med digitale elementer.
Den tidligere version af denne artikel kom også til at formulere standardernes rolle for bredt. Det viser netop, hvor let denne fejl kan opstå, hvis man starter med standarder og certificeringer i stedet for at starte med selve forordningen.
Den korrekte juridiske sondring er:
| Spørgsmål | Korrekt svar |
|---|---|
| Kræver CRA IEC 62443-certificering | Nej, ikke som et generelt krav |
| Kræver CRA ISO/IEC 27001-certificering | Nej, ikke som et generelt krav |
| Kan IEC 62443 være relevant for industrielle produkter | Ja, men som teknisk dokumentationsværktøj, ikke som generelt lovkrav |
| Kan ISO/IEC 27001 være relevant | Ja, men som ledelsessystem og dokumentationsstøtte, ikke som produktgodkendelse. Det er forskellige emner men behandles som 1 når pressen og fakaktører omtaler CRA. |
| Hvad er afgørende under CRA | At det konkrete produkt med digitale elementer opfylder forordningens væsentlige cybersikkerhedskrav |
ISO/IEC 27001 kan understøtte men ikke erstatte CRA
ISO/IEC 27001 kan være relevant, fordi standarden etablerer, implementerer, vedligeholder og forbedrer et ledelsessystem for informationssikkerhed. Den hjælper virksomheden med at dokumentere risikostyring, roller, ansvar, kontroller, leverandørstyring, hændelsesprocesser og løbende forbedringer.
I CRA-sammenhæng kan ISO/IEC 27001 især bruges til at dokumentere:
| ISO/IEC 27001 område | Relevans for CRA |
|---|---|
| Risikostyring | Understøtter dokumenteret vurdering af informationssikkerhedsrisici |
| Ledelsesansvar | Viser at cybersikkerhed er forankret organisatorisk |
| Leverandørstyring | Understøtter kontrol med softwarekomponenter og underleverandører |
| Hændelseshåndtering | Understøtter rapporteringsprocesser og intern eskalering |
| Adgangskontrol | Understøtter sikring af udviklingsmiljøer og produktionssystemer |
| Dokumentstyring | Understøtter krav om teknisk dokumentation og sporbarhed |
| Løbende forbedring | Understøtter patching, audit, review og produktforbedringer |
Men ISO/IEC 27001 svarer ikke i sig selv på, om et bestemt produkt med digitale elementer opfylder CRA’s væsentlige krav. En virksomhed kan derfor godt være ISO/IEC 27001-certificeret og stadig mangle CRA-dokumentation for et konkret produkt.
EN IEC 62443 kan være relevant men ikke som generelt CRA-krav
EN IEC 62443 kan være relevant for virksomheder, der arbejder med OT, industrielle automations- og kontrolsystemer, embedded hardware, industrielle controllere, gateways, SCADA, PLC’er, forsyning, energi, produktion, smart building, smart city eller datacenterstyring.
Standarden har med cybersikkerhed at gøre, fordi moderne industrielle systemer ikke længere er isolerede maskiner. De er forbundet med netværk, cloud, fjernservice, API’er, softwareopdateringer, leverandøradgang og dataudveksling.
Et cyberangreb kan derfor ramme:
| Cyberrisiko | Eksempel i industri og OT |
|---|---|
| Uautoriseret adgang | En angriber får adgang til en controller eller gateway |
| Manipulation | En PLC får ændret styringslogik |
| Nedbrud | Et SCADA-system bliver utilgængeligt |
| Dataintegritet | Måledata ændres, så systemet træffer forkerte beslutninger |
| Fjernadgang | Leverandøradgang misbruges |
| Malware | Ransomware spreder sig fra IT til OT |
| Sårbare komponenter | Firmware eller open source-komponenter indeholder kendte sårbarheder |
| Manglende patching | Udstyr står i drift i mange år uden sikkerhedsopdateringer |
Det gør EN IEC 62443 relevant for visse industrielle produkter. Men det ændrer ikke ved, at CRA ikke opstiller et generelt krav om IEC 62443-certificering.
Den rigtige formulering er derfor:
| Forkert formulering | Korrekt formulering |
|---|---|
| Virksomheder skal IEC 62443-certificeres for at opfylde CRA | CRA indeholder ikke et generelt krav om IEC 62443-certificering |
| ISO/IEC 27001 opfylder CRA | ISO/IEC 27001 kan understøtte governance, men erstatter ikke CRA’s produktkrav |
| EN IEC 62443 er CRA-standarden | EN IEC 62443 kan være relevant for visse industrielle produkter, men CRA skal vurderes ud fra forordningen |
| Standarder er lovkravet | Forordningen er lovkravet, standarder kan være dokumentationsværktøjer |
Harmoniserede standarder under CRA
Europa-Kommissionen har vedtaget standardiseringsanmodning M/606, som omfatter 41 standarder til støtte for CRA. Standarderne skal udvikles af de europæiske standardiseringsorganisationer CEN, CENELEC og ETSI.
Når harmoniserede standarder offentliggøres og anvendes korrekt, kan de give en formodning for overensstemmelse med CRA’s væsentlige krav. Det er vigtigt, fordi mange virksomheder ellers vil stå med et vanskeligt bevisproblem: Hvordan dokumenterer man, at et digitalt produkt har et tilstrækkeligt cybersikkerhedsniveau?
Det skal dog understreges, at en harmoniseret standard ikke er det samme som et generelt krav om en bestemt certificering. En harmoniseret standard kan være en måde at dokumentere overensstemmelse på, hvis den er relevant for det konkrete produkt. Men den juridiske vurdering skal begynde med forordning (EU) 2024/2847 og ikke med salgsargumenter for standarder, certificeringer eller konsulentydelser.
| Standardtype | Funktion |
|---|---|
| Horisontale standarder | Fælles rammer for eksempelvis risikovurdering, sårbarhedshåndtering, dokumentation og sikker udvikling |
| Vertikale standarder | Produktspecifikke standarder for bestemte produktkategorier |
| Støttedokumenter | Terminologi, trusselsmodeller, risikometoder og praktiske complianceværktøjer |
| Certificeringer | Kan være nyttige beviser, men er ikke automatisk lovkrav under CRA |
Praktisk tidsplan for danske virksomheder
| Periode | Fokus | Handling |
|---|---|---|
| 2026 første halvår | Kortlægning | Identificer alle produkter med digitale elementer, roller i forsyningskæden og produktkategorier |
| 2026 andet halvår | Rapportering og beredskab | Etabler proces for artikel 14-rapportering, hændelsesvurdering og sårbarhedshåndtering |
| 2026 til 2027 | Standarder og dokumentation | Følg harmoniserede standarder, men forveksl ikke standarder med generelle certificeringskrav |
| 2027 første halvår | Produktgap | Gennemfør gap-analyse mod CRA’s væsentlige krav og relevante bilag |
| 2027 andet halvår | Overensstemmelse | Gennemfør overensstemmelsesvurdering, CE-forberedelse og ledelsesgodkendelse |
| 11. december 2027 | Fuld anvendelse | Produkter skal som udgangspunkt kunne dokumenteres som CRA-konforme ved markedsføring |
| Efter 2027 | Livscyklus | Vedligehold sårbarhedsproces, supportperiode, opdateringer, hændelsesrapportering og produktdokumentation |
Praktisk compliance-model
En dansk virksomhed bør starte med en juridisk og teknisk klassifikation af sine produkter.
Første spørgsmål er, om produktet er et produkt med digitale elementer. Andet spørgsmål er, hvilken rolle virksomheden har. Tredje spørgsmål er, hvilken risikokategori produktet falder i. Fjerde spørgsmål er, hvilken overensstemmelsesvurdering der kræves. Femte spørgsmål er, hvilke standarder der eventuelt kan anvendes som dokumentationsgrundlag.
| Spørgsmål | Hvorfor det er vigtigt |
|---|---|
| Er produktet omfattet af CRA | Afgør om forordningen finder anvendelse |
| Er virksomheden producent, importør eller distributør | Afgør hvilke pligter virksomheden har |
| Er produktet almindeligt, vigtigt eller kritisk | Afgør graden af vurdering og mulig tredjepartskontrol |
| Findes der harmoniserede standarder | Kan give formodning for overensstemmelse, hvis de er relevante |
| Er virksomheden ISO/IEC 27001-certificeret | Kan styrke governance og dokumentation, men er ikke nok i sig selv |
| Er produktet relevant for EN IEC 62443 | Kan være relevant for OT og industrielle produkter, men er ikke et generelt krav |
| Er der SBOM og komponentstyring | Understøtter sporbarhed og sårbarhedshåndtering |
| Er der rapporteringsberedskab | Nødvendigt fra 11. september 2026 |
SBOM og komponentstyring
Et centralt CRA-tema er kontrol med komponenter og afhængigheder. Moderne software består ofte af open source-komponenter, tredjepartsbiblioteker, firmwarepakker og cloudintegrationer. Hvis virksomheden ikke ved, hvilke komponenter produktet indeholder, kan den heller ikke effektivt vurdere sårbarheder. Derfor bør danske virksomheder etablere en Software Bill of Materials, ofte kaldet SBOM. En SBOM er en struktureret oversigt over softwarekomponenter, versioner, afhængigheder og licenser. Den gør det muligt hurtigt at identificere, om et produkt er påvirket af en ny sårbarhed.
SBOM er et dokumentationsbegreb og et teknisk værktøj. Det betyder en Software Bill of Materials, altså en softwarekomponentfortegnelse. Den viser, hvilke softwarekomponenter, biblioteker, afhængigheder, versioner og typisk leverandør eller oprindelse der indgår i et digitalt produkt. Det er IKKE en USA standard (som der ikke findes i kommende EU direktiver)
I CRA bliver SBOM relevant, fordi EU-forordningen kræver, at producenten skal identificere og dokumentere produktets komponenter, herunder ved at udarbejde en software bill of materials i et almindeligt anvendt og maskinlæsbart format, som mindst dækker topniveauafhængigheder. Det står i bilag I, del II, punkt 1 i forordning (EU) 2024/2847.
SBOM bør ikke blot være et teknisk bilag. Den bør være en del af virksomhedens compliance-dokumentation, risikostyring og leverandørkontrol.
Leverandørkontrakter skal opdateres
CRA får også kontraktretlig betydning. Mange danske virksomheder køber softwareudvikling, komponenter, cloudfunktioner eller firmware fra underleverandører. Hvis disse leverancer indgår i et produkt, som virksomheden markedsfører under eget navn, kan virksomheden ikke uden videre placere ansvaret hos leverandøren.
Virksomheden bør derfor opdatere leverandørkontrakter med krav om:
| Kontraktområde | Krav der bør overvejes |
|---|---|
| Sårbarhedsoplysninger | Leverandøren skal oplyse om kendte og nye sårbarheder |
| SBOM | Leverandøren skal levere og opdatere komponentoversigter |
| Sikker udvikling | Leverandøren skal dokumentere sikre udviklingsprocesser |
| Patchfrister | Leverandøren skal kunne levere rettelser inden for aftalte frister |
| Auditret | Virksomheden skal kunne kontrollere dokumentation |
| Underleverandører | Leverandøren skal kontrollere egne underleverandører |
| Rapportering | Leverandøren skal straks eskalere hændelser, der kan påvirke CRA-pligter |
Forholdet til NIS2 og GDPR
CRA skal ikke forveksles med NIS2 eller GDPR.
NIS2 handler primært om cybersikkerhed hos væsentlige og vigtige enheder i bestemte sektorer. GDPR handler om beskyttelse af personoplysninger. CRA handler om cybersikkerhed i produkter med digitale elementer, der bringes på markedet.
Der kan dog være overlap. En sikkerhedshændelse i et digitalt produkt kan samtidig være relevant efter CRA, NIS2, GDPR, kontrakter og sektorregulering. Derfor bør virksomheder ikke opbygge separate siloer. En moden compliance-model bør samle juridisk vurdering, teknisk hændelseshåndtering, myndighedsrapportering og kundekommunikation i én koordineret proces.
Risici ved manglende efterlevelse
Manglende CRA-compliance kan få alvorlige konsekvenser. Efter forordningen skal medlemsstaterne fastsætte regler om sanktioner, og overtrædelser kan medføre betydelige administrative bøder.
Derudover kan markedsovervågningsmyndighederne gribe ind over for produkter, der ikke opfylder kravene. Det kan få betydning for salg, distribution, tilbagekaldelse, kontrakter, udbud og forsikringsforhold.
Den kommercielle risiko kan være mindst lige så alvorlig som bøderisikoen. Hvis et produkt ikke kan dokumenteres, kan det blive vanskeligt at sælge til offentlige kunder, kritiske sektorer, større industrikunder og internationale koncerner. CRA kan derfor hurtigt blive et adgangskrav i udbud, leverandørvurderinger og kontraktforhandlinger.
Bestyrelsens og ledelsens ansvar
CRA bør ikke behandles som et rent teknisk projekt. Det er et ledelses- og bestyrelsesanliggende, fordi reglerne påvirker produktstrategi, markedsadgang, kontrakter, forsyningskæde, forsikring, risikostyring og økonomi.
Ledelsen bør sikre, at der udpeges en ansvarlig ejer for CRA-programmet, og at der etableres rapportering til direktion og eventuelt bestyrelse. Virksomheden bør også sikre, at produktudvikling, legal, compliance, informationssikkerhed, salg og indkøb arbejder efter samme tidsplan.
Det er samtidig vigtigt, at ledelsen ikke køber en certificering i den tro, at certifikatet i sig selv løser CRA. Certificeringer kan være værdifulde, men de skal kobles til produktets konkrete krav efter forordningen.
Anbefalet handlingsplan
| Prioritet | Handling | Formål |
|---|---|---|
| 1 | Kortlæg alle produkter med digitale elementer | Fastlæg omfanget af CRA-eksponeringen |
| 2 | Fastlæg virksomhedens rolle for hvert produkt | Afklar om virksomheden er producent, importør eller distributør |
| 3 | Klassificér produkter efter risikokategori | Afklar behov for selvevaluering eller tredjepartsvurdering |
| 4 | Lav gap-analyse mod CRA’s væsentlige krav | Identificér mangler i sikkerhed, dokumentation og processer |
| 5 | Etabler sårbarhedsproces og rapporteringsberedskab | Bliv klar til artikel 14 fra 11. september 2026 |
| 6 | Indfør SBOM og komponentstyring | Skab sporbarhed og hurtig sårbarhedsvurdering |
| 7 | Vurder ISO/IEC 27001 og EN IEC 62443 nøgternt | Brug standarder som dokumentationsstøtte, ikke som erstatning for CRA |
| 8 | Opdater leverandørkontrakter | Sikr rettigheder til dokumentation, patches og hændelsesdata |
| 9 | Følg harmoniserede CRA-standarder | Opnå bedst muligt grundlag for formodning om overensstemmelse |
| 10 | Forbered CE-mærkning og teknisk dossier | Sikr markedsadgang fra 11. december 2027 |
Sådan bør danske virksomheder prioritere nu
Danske virksomheder bør bruge 2026 til at få overblik og etablere processer. Det vigtigste er ikke at starte med en stor certificeringsøvelse, men at finde ud af, hvilke produkter der er omfattet, hvilke roller virksomheden har, og hvor dokumentationen mangler.
ISO/IEC 27001 kan være et stærkt fundament for governance og informationssikkerhed. EN IEC 62443 kan være relevant for industrielle produkter og OT-miljøer. Harmoniserede CRA-standarder kan blive vigtige for formodning om overensstemmelse. Men ingen af disse standarder ændrer ved, at CRA kræver en produktspecifik vurdering.
Den virksomhed, der først får styr på produktkortlægning, SBOM, sårbarhedsproces, rapportering, kontrakter og teknisk dokumentation, vil stå stærkere over for kunder, myndigheder, investorer og forsikringsselskaber.
CRA bør derfor behandles som et strategisk markedsadgangsprojekt, ikke kun som et it-sikkerhedsprojekt.
Den vigtigste juridiske pointe er enkel: CRA kræver ikke som generel regel ISO/IEC 27001-certificering eller IEC 62443-certificering. CRA kræver, at produktet med digitale elementer opfylder forordningens væsentlige cybersikkerhedskrav, og at virksomheden kan dokumentere det.
Kilde: Europa-Parlamentets og Rådets forordning (EU) 2024/2847, Europa-Kommissionen, Advokat og Revisor Samvirket, AORS.DK
Fotokredit: stock.adobe.com
Personer/Firmaer/Emner/#: #CRA, #CyberResilienceAct, #EU, #Cybersikkerhed, #DanskeVirksomheder, #Compliance, #ISO27001, #IEC62443, #ENIEC62443, #SBOM, #CE-mærkning, #Software, #Hardware, #IoT, #OT, #NIS2, #GDPR, #Produktansvar
Copyrights: Ⓒ 2026 Copyright by https://AORS.DK – kan deles ved aktivt link til denne artikel.
