Cybersikkerhed i produkter – Fra teknisk detalje til leveringskrav

Artiklen er skrevet af Jeppe Pilgaard Bjerre fra FORCE Technology og Jesper Løffler Nielsen fra Focus Advokater. Sammen giver de et teknisk og juridisk blik på, hvad Cyber Resilience Act betyder for virksomheder, der udvikler, importerer eller sælger produkter med digitale elementer.

CRA – En del af EU’s voksende lovpakke for produkter

For dem, der er vant til at arbejde med produktregulering, vil store dele af CRA være kendt stof.

EU’s produktregulering har overordnet et todelt formål, nemlig at sikre den frie bevægelighed for varer på det indre marked og samtidig et højt beskyttelsesniveau for bl.a. sundhed, sikkerhed, forbrugere og miljø. For at opnå det er reglerne opbygget i flere lag, der supplerer hinanden.

Udgangspunktet er, at produkter, der markedsføres i EU, skal overholde horisontale produktsikkerhedsregler og, hvor det er relevant, sektorspecifik lovgivning for bestemte produktkategorier, såsom elektrisk udstyr, radioudstyr, maskiner, batterier, byggevarer eller andre regulerede varer.

Derudover findes der et fælles sæt tilbagevendende krav på tværs af mange EU-produktordninger, især dem, der er opbygget omkring den nye lovgivningsramme (New Legislative Framework), som du kan læse meget mere om i Europa-Kommissionens Blue Guide. Blue Guide er et ikke-bindende vejledningsdokument fra 2000, senest revideret i 2022, som forklarer, hvordan EU’s produktregler skal anvendes ensartet på tværs af sektorer.

De tilbagevendende krav omfatter typisk produktklassificering, fastlæggelse af den økonomiske aktørs rolle, overensstemmelsesvurderinger, teknisk dokumentation, overensstemmelseserklæring, CE-mærkning, og hvor det er relevant, mærkning, sporbarhed, kontrol efter markedsføring og samarbejde med markedsovervågningsmyndighederne.

Alle elementerne genfindes også i CRA, dog med et særligt ”digitalt tvist”, som uddybes senere i artiklen. Ligesom det gælder for alle andre produktkrav, så er overholdelse af CRA, og dokumentation herfor, en forudsætning for, at omfattede produkter lovligt kan sælges i EU. Og modsat de fleste andre produktkrav, så er CRA herudover underlagt betydelige sanktionsbestemmelser, herunder bøder på op til 15 mio. EUR eller 2,5 % af den årlige, globale omsætning.

Hvornår er et produkt omfattet af CRA?

Ifølge Kommissionens FAQ beror vurderingen på tre kumulative betingelser, som alle skal være opfyldt, før et produkt er omfattet af CRA:

1. produktet skal udgøre et ”produkt med digitale elementer”
2. det skal gøres tilgængeligt på markedet
3. dets tilsigtede formål eller rimeligt forudsigelige anvendelse skal omfatte en dataforbindelse til en enhed eller et netværk

Et ”produkt med digitale elementer” er et bredt begreb, der omfatter både software og hardware med digitale funktioner samt visse fjernbehandlingsløsninger, der er nødvendige for produktets funktion. Det kan f.eks. være en app eller software, der er indbygget i et fysisk produkt, et operativsystem eller selve det fysiske produkt. Begrebet omfatter derfor alt fra mikrochips og sensorer til almindelig forbrugerteknik og internetforbundne produkter. Almindelige websites, selvstændige SaaS-løsninger og andre cloud-tjenester falder normalt uden for CRA, medmindre de udgør en fjernbehandlingsløsning for et produkt med digitale elementer. De kan dog være omfattet, hvis de er nødvendige for, at et produkt med digitale elementer kan fungere, og dermed udgøre en del af produktets fjerndatabehandling. 

Kommissionen har uddybet emnet i flere vejledninger, først i en såkaldt FAQ, og senere i juli 2026 i en mere dybdegående vejledning. Hvor FAQ’en giver et kortfattet og overskueligt overblik, kan man i vejledningen finde endnu mere uddybning, særligt af gråzone-scenarier såsom kildekode, open source, komplekse systemer (f.eks. maskiner/produktionslinjer/anlæg), reservedele mv.

I FAQ’en gives konkrete eksempler på produkter, der falder uden for CRA, netop fordi de mangler enhver forbindelsesmulighed: en opvaskemaskine med indbygget firmware, men uden forbindelse til andre enheder; en basal lommeregner; et elektronisk legetøj, der kun afspiller forudindspillede lyd- og lyseffekter; en elektrisk tandbørste med trådløs opladningsstation, men uden evne til at forbinde til andre enheder eller netværk. Modsat vil produkter med programmerbar styring, fjernovervågning eller netværksforbundne sensorer typisk være omfattet, uanset om forbindelsen sker via kabel, Wi-Fi, Bluetooth eller en indirekte forbindelse gennem et andet system.

FAQ’en understreger også, at selv produkter, der kun er indirekte forbundet, f.eks. fordi de indgår som en del af et større system, som i sig selv kan tilkobles en enhed eller et netværk, kan udgøre et angrebspunkt og er derfor omfattet på lige fod med produkter, der forbindes direkte. Et eksempel kunne være en offline tekstbehandler, der ikke selv opretter forbindelse til andre enheder eller netværk, men som kører på et operativsystem (f.eks. macOS eller Windows), der gør det. Her anses tekstbehandleren for indirekte forbundet i kraft af operativsystemet.

Herudover undtager CRA en række produkter fra sit anvendelsesområde. Det gælder produkter, som en producent udelukkende fremstiller til eget brug og som ikke bliver tilgængelige på markedet som separate produkter. Det gælder også produkter, der udelukkende er udviklet eller modificeret til nationale sikkerheds- eller forsvarsmål.

Endelig vil tjenesteydelser normalt falde uden for CRA’s krav, herunder ”Software-as-a-Service”, medmindre der er tale om ”remote data processing solutions”, som er nærmere uddybet i vejledningens afsnit 8.

Som det i stigende grad er tilfældet for EU’s regulering på det digitale område, så suppleres forordningsteksten af en lang række andre retskilder, herunder: EU-Kommissionens FAQ (pt. i version 1.4), EU-Kommissionens vejledning (juli 2026) og ENISA “SME Cyber Resilience Maturity Assessment Model” (mappet op mod CRA-krav).

Fabrikantens kerneopgaver – Risikovurdering, due diligence og ”security by design”

Kernen i CRA er, at fabrikanten ifølge artikel 13(2) og 13(3) selv skal gennemføre en dokumenteret cybersikkerhedsrisikovurdering af produktet, både af produktets egenskaber og af de processer, fabrikanten indfører til håndtering af sårbarheder. Kommissionen præciserer i pkt. 7.1 i sin vejledning, at risikovurderingen adskiller sig fra en mere traditionel risikovurdering fra et organisatorisk perspektiv.

“In organisational risk management, risks are commonly evaluated against acceptance criteria derived from the organisation’s internal objectives or risk appetite. By contrast, under the CRA, residual cybersecurity risk should be assessed in light of the requirement that the product with digital elements placed on the market ensures an appropriate level of cybersecurity based on the risks, taking into account its intended purpose and reasonably foreseeable use.”

Det indebærer bl.a. en pligt til at adressere de minimumskrav, som er oplistet i CRA bilag I. Minimumskravene er opsummeret nedenfor:

Bilag I, del I: Krav til selve produktet

• Overordnet sikkerhedsniveau: Produktet skal designes, udvikles og produceres, så det sikrer et passende cybersikkerhedsniveau baseret på risici. Kravene er formålsorienterede og teknologineutrale.
• Ingen kendte udnyttelige sårbarheder: Produktet skal på baggrund af risikovurderingen gøres tilgængeligt uden kendte, udnyttelige sårbarheder. Der er ikke krav om fravær af enhver sårbarhed.
• Sikker standardkonfiguration: Produktet skal leveres med en sikker standardkonfiguration (secure by default), herunder mulighed for at nulstille produktet til dets oprindelige tilstand, medmindre andet er aftalt for et skræddersyet produkt.
• Håndtering af sårbarheder gennem opdateringer: Sårbarheder skal kunne afhjælpes gennem sikkerhedsopdateringer, herunder automatiske opdateringer inden for en passende tidsramme, med mulighed for fravalg og udskydelse.
• Adgangskontrol, fortrolighed, integritet mv.: Yderligere tekniske krav om bl.a. beskyttelse af data, adgangsstyring og modstandsdygtighed mod denial-of-service, fastsat i bilag I, del I, punkt 2.
• Dokumentation af fravigelser: Fabrikanten skal i den tekniske dokumentation redegøre for, hvordan produktet opfylder de væsentlige krav, og begrunde det, hvis et krav vurderes irrelevant for det konkrete produkt.

Bilag I, del II: Krav til fabrikantens processer for sårbarhedshåndtering

• Løbende identifikation og afhjælpning: Sårbarheder, der opstår i supportperioden, skal adresseres og afhjælpes uden unødigt ophold ud fra en risikobaseret vurdering. Der er ikke krav om en patch i alle tilfælde.
• Adskillelse af sikkerheds- og funktionsopdateringer: Nye sikkerhedsopdateringer skal, hvor det er teknisk muligt, leveres adskilt fra funktionsopdateringer.
• Håndtering af sårbarheder i integrerede komponenter: Forpligtelsen omfatter produktet i sin helhed, herunder alle integrerede komponenter, også open source-komponenter.
• Sikker distribution af opdateringer: Fabrikanten skal etablere mekanismer til sikker distribution af opdateringer, så sårbarheder rettes eller afbødes rettidigt.
• Gratis sikkerhedsopdateringer med vejledning: Sikkerhedsopdateringer skal, når de er tilgængelige, udsendes uden unødigt ophold og som udgangspunkt gratis, ledsaget af relevant vejledning til brugerne.
• Koordineret sårbarhedshåndtering og rapportering: Fabrikanten skal have en politik for koordineret afsløring af sårbarheder (coordinated vulnerability disclosure) og mekanismer til at dele oplysninger om potentielle sårbarheder.
• Tilbagetrækning som sidste udvej: Kan en sårbarhed, der udgør en væsentlig risiko, ikke afhjælpes tilstrækkeligt, skal fabrikanten om nødvendigt trække produktet tilbage fra markedet eller kalde det tilbage.

Et punkt, der ofte misforstås, er, at CRA ikke kræver, at et produkt er fri for alle sårbarheder. Kravet er, at produktet ved markedsføringen ikke må indeholde kendte, udnyttelige sårbarheder, altså sårbarheder, der reelt kan udnyttes under praktiske driftsforhold.

Due diligence ved integration af komponenter fra tredjeparter, herunder open source-komponenter, er et andet centralt område, jf. CRA-artikel 13(5). Kommissionens vejledning nævner bl.a. følgende eksempler på due diligence-foranstaltninger afhængigt af komponentens risikoniveau:

• at tjekke, om komponenten allerede er CE-mærket
• at undersøge dens historik for sikkerhedsopdateringer
• at slå op i den europæiske sårbarhedsdatabase
• at gennemføre supplerende sikkerhedstests, og hvor det er relevant
• at gennemgå komponentens software bill of materials (SBOM), hvor det er relevant

Fabrikanten skal ikke nødvendigvis udskifte enhver komponent, der ikke er CE-mærket, men skal kunne redegøre for, hvorfor den valgte due diligence er tilstrækkelig i lyset af risikoen. Due diligence-forpligtelsen er nærmere uddybet i vejledningens afsnit 7.3.

Endelig skal fabrikanten fastsætte en supportperiode for produktet, som skal afspejle den forventede brugstid. Perioden skal som udgangspunkt være mindst fem år, medmindre produktets forventede levetid er kortere. For produkter, der ofte er i drift i ti, femten eller tyve år (typisk industrielt udstyr, netværksudstyr og visse hardwarekomponenter) vil vurderingen sjældent svare til minimumskravet.

Kommissionens FAQ illustrerer princippet om differentiering efter brugstid med følgende eksempel: En fabrikant bringer 10.000 identiske enheder af samme produktmodel i omsætning i januar 2028 med en supportperiode på fem år, altså til januar 2033. Samme fabrikant bringer den 1. januar 2030 yderligere 5.000 enheder af samme model i omsætning. De senere markedsførte enheder får deres egen supportperiode beregnet fra det tidspunkt, hvor de gøres tilgængelige på markedet. Tilsvarende vil et forbrugerprodukt som en smart home-hub med en forventet brugstid på fem til otte år typisk kunne nøjes med minimumskravet, mens netværksudstyr eller industrielle styresystemer, der ofte er i drift 15-20 år, kræver en tilsvarende længere periode. Det kunne f.eks. være, fordi de skal indgå i et byggeri. Fastlæggelsen skal dokumenteres og har direkte betydning for, hvad der kan loves i tilbud, kontrakter og brugsanvisninger.

Overensstemmelsesvurdering, standarder og CE-mærkning

Når fabrikanten har gennemført risikovurderingen og implementeret de nødvendige tekniske og organisatoriske foranstaltninger, skal overensstemmelsen med CRA dokumenteres og bekræftes gennem en formel overensstemmelsesvurderingsprocedure, jf. CRA-artikel 32, som fabrikanten skal have gennemført, inden produktet lanceres på markedet, jf. CRA-artikel 13, stk. 12. CRA opererer med tre procedurer af stigende kompleksitet: modul A (intern kontrol), modul B+C (EU-typeafprøvning) og modul H (fuld kvalitetssikring).

Modul A indebærer, at fabrikanten selv verificerer og på eget ansvar erklærer overensstemmelse, uden inddragelse af et bemyndiget organ. Muligheden står som udgangspunkt åben for alle produkter, der ikke har kernefunktionaliteten som et “vigtigt” eller “kritisk” produkt efter CRA-bilag III og IV. For vigtige produkter i klasse I kan modul A dog kun anvendes, hvis fabrikanten har anvendt en harmoniseret standard i overensstemmelse med artikel 32, stk. 2, eller hvis produktet er gratis open source-software, og den tekniske dokumentation gøres offentligt tilgængelig, jf. artikel 32, stk. 5.

For ”vigtige” og ”kritiske” produkter gælder særlige krav, f.eks. krav om tredjepartsvurderinger, særlige certificeringer mv. Der er tale om nogle få typer af produkter, hvorfor kravene ikke behandles nærmere her.

Uanset hvilken procedure der anvendes, er der ingen foreskreven testmetode. CRA stiller ikke krav om en bestemt evalueringsmetode, men det er almindelig praksis at anvende en relevant harmoniseret standard eller teknisk specifikation, og fabrikanten bærer under alle omstændigheder det fulde ansvar for overensstemmelsesvurderingen, uanset om testene udføres i eget eller eksternt laboratorium.

Når overensstemmelsen er dokumenteret, skal to formelle dokumenter på plads. Fabrikanten skal udarbejde en EU-overensstemmelseserklæring efter CRA-artikel 28, baseret på modellen i CRA-bilag V (eller en forenklet erklæring efter bilag VI), og anbringe CE-mærkning på produktet efter CRA-artikel 30. Er produktet omfattet af flere EU-retsakter, der hver kræver en overensstemmelseserklæring, jf. artikel 28, stk. 3, kan fabrikanten nøjes med én samlet erklæring, der angiver alle relevante EU-retsakter, eventuelt som et samlet dossier af de enkelte erklæringer, for at lette den administrative byrde.

Standarderne, der skal gøre det lettere at dokumentere overensstemmelse, er stadig undervejs. Produkter, der er i overensstemmelse med standarder offentliggjort i Den Europæiske Unions Tidende, formodes at være i overensstemmelse med de væsentlige cybersikkerhedskrav i CRA bilag I, jf. CRA-artikel 27, stk. 1. Kommissionen har bedt de europæiske standardiseringsorganisationer om at udarbejde 15 horisontale standarder, herunder en om sikkert design og udvikling og en om håndtering af sårbarheder, og man kan følge fremskridtet med standarderne via et CRA Standardization Dashboard, som løbende opdateres af BSI i Tyskland.

Ansvar i resten af forsyningskæden

CRA gælder ikke kun for fabrikanter. Regelsættet opererer med den samme rollefordeling, som kendes fra de fleste andre EU-produktregler, herunder fabrikant, bemyndiget repræsentant, importør, distributør og nu også open source-softwareforvalter. Hver rolle har sit eget sæt forpligtelser, og en virksomhed kan sagtens have flere roller på samme tid, alt efter hvad den konkret gør med et givent produkt.

Importører skal kontrollere, at fabrikanten har gennemført de rette overensstemmelsesvurderinger, at den tekniske dokumentation er udarbejdet, og at produktet er forsynet med CE-mærkning og EU-overensstemmelseserklæring, før produktet må bringes i omsætning. Bliver en importør bekendt med, at et produkt udgør en væsentlig cybersikkerhedsrisiko, skal både fabrikanten og markedsovervågningsmyndighederne underrettes. Distributører har en tilsvarende, om end mindre vidtgående kontrolforpligtelse, og skal handle med fornøden omhu i forhold til CRA’s krav.

Et punkt, der ofte overses i praksis, er reglen om, at en importør eller distributør, der sælger et produkt under eget navn eller varemærke, eller foretager en væsentlig ændring af et produkt, der allerede er markedsført, selv bliver anset for fabrikant efter CRA. Det gælder for enhver virksomhed, der i vidt omfang benytter white label-løsninger eller integrerer tredjepartskomponenter under eget produktnavn: rollen som “bare” distributør eller importør kan hurtigt blive til det langt tungere fabrikantansvar, hvis grænsen for en væsentlig ændring overskrides. Endelig introducerer CRA en helt ny aktørtype: open source-softwareforvalteren, altså den juridiske person, der understøtter udviklingen af specifikke produkter med gratis open source-software. Forvalteren skal indføre og dokumentere en cybersikkerhedspolitik og samarbejde med markedsovervågningsmyndighederne, men er til gengæld undtaget fra bøder efter CRA. Rene bidragydere til open source uden kommerciel tilknytning falder som udgangspunkt uden for CRA, mens virksomheder, der kommercielt distribuerer eller integrerer open source-komponenter i deres produkter, kan blive omfattet på linje med andre erhvervsdrivende. Open Regulatory Compliance Working Group følger løbende netop den del af regelsættet tæt.

Rapportering – Fra 24 timer til den endelige rapport

En af de mest håndgribelige, og mest tidskritiske, forpligtelser er rapporteringspligten i CRA-artikel 14, der gælder fra den 11. september 2026, altså før hovedparten af de øvrige forpligtelser træder i kraft. Bliver en fabrikant opmærksom på en aktivt udnyttet sårbarhed eller en alvorlig hændelse, skal der gives en tidlig varsling senest 24 timer efter kendskab og en mere uddybende underretning senest 72 timer efter.

Herefter adskiller forløbet sig for de to kategorier. For en aktivt udnyttet sårbarhed skal den endelige rapport indsendes senest 14 dage efter, at en afhjælpende foranstaltning foreligger, mens den endelige rapport for en alvorlig hændelse skal indsendes senest én måned efter 72-timersunderretningen. Det er uafhængigt af, om der på det tidspunkt foreligger en afhjælpende foranstaltning.

En ”alvorlig hændelse” omfatter i den forbindelse to hovedtilfælde: 1) enten at produktets evne til at beskytte tilgængeligheden, autenticiteten, integriteten eller fortroligheden af følsomme data er kompromitteret, eller 2) at der i produktet er indført skadelig kode, som kan eksekveres. 

Det er vigtigt at holde de to kategorier adskilt. En sårbarhed er kun rapporteringspligtig, hvis der foreligger pålidelig dokumentation for, at en ondsindet aktør faktisk har udnyttet den. En zero-day-sårbarhed, som en etisk hacker afdækker og indrapporterer uden tegn på misbrug, udløser ikke i sig selv rapporteringspligt.

Tidspunktet for ”kendskab” er heller ikke det øjeblik, hvor en ekstern person først retter kontakt. Fristen løber fra det tidspunkt, hvor fabrikanten efter en indledende vurdering har en rimelig grad af sikkerhed for, at der reelt er tale om en aktivt udnyttet sårbarhed eller en alvorlig hændelse.

En producent kan blive opmærksom på en aktivt udnyttet sårbarhed eller en alvorlig hændelse på flere måder. Det kan f.eks. ske via henvendelser fra kunder eller partnere, trusselsefterretningsrapporter fra sikkerhedsforskere, myndighedsovervågningssystemer, etiske hackere, eller via egen intern overvågning eller scanning.

Et eksempel kunne være, at en fabrikants egen sikkerhedsafdeling konstaterer, at en kundes enhed har kommunikeret med en kendt command-and-control-server som følge af en sårbarhed i produktet. Rapporteringen sker til den relevante CSIRT og til ENISA via den fælles indberetningsplatform (SRP), og forpligtelsen gælder også for produkter, der allerede er markedsført, når blot de er omfattet af CRA’s anvendelsesområde. For uddybning af de informationer, der skal indberettes, kan der i det hele henvises til ENISA’s Reporting FAQ samt Glossary.

Det stiller allerede nu krav om, at fabrikanter kan spore, hvilke programmer og programversioner der er leveret til hvilke produkter og kunder, en sporbarhed, der historisk har været langt bedre udbygget for fysiske komponenter end for software og firmware.

Samspil med andre regelsæt

Et produkt med digitale elementer er sjældent kun omfattet af CRA. Det vil ofte samtidig være reguleret af én eller flere andre EU-retsakter, og det er langt fra givet, at overholdelse af den ene automatisk medfører overholdelse af den anden. For produkter, der samtidig er reguleret af anden EU-produktlovgivning, er det værd at holde sig for øje, at kravene om cybersikkerhed kan findes flere steder på samme tid. 

For maskiner gælder maskinforordningen (EU) 2023/1230 fra den 20. januar 2027, og den stiller i sit bilag III krav om beskyttelse mod forvanskning og om sikre og pålidelige styresystemer. Hvor en maskine også er et produkt med digitale elementer, skal begge regelsæts cybersikkerhedskrav opfyldes, og synergien mellem dem skal dokumenteres konkret af fabrikanten på baggrund af en risikovurdering, typisk ved brug af harmoniserede standarder, hvis de findes. Der skal som udgangspunkt gennemføres separate overensstemmelsesvurderingsprocedurer efter begge regelsæt, uanset om kravene delvist overlapper indholdsmæssigt. Læs mere om specifikke krav til cybersikkerhed i maskiner, og hvordan de spiller sammen med CRA, i artiklen Cybersikkerhed i maskiner.

For radioudstyr gælder i dag de cybersikkerhedskrav, der følger af den delegerede forordning (EU) 2022/30 til radioudstyrsdirektivet, og som er understøttet af standardserien EN 18031. Der er et betydeligt sammenfald mellem de produktkategorier og cybersikkerhedsmål, som reguleres af den delegerede forordning (EU) 2022/30 og CRA. Indtil den 10. december 2027 er de relevante cybersikkerhedskrav til radioudstyr dog reguleret gennem radioudstyrsdirektivets artikel 3(3)(d) til (f), mens kravene fra den 11. december 2027 erstattes af CRA.

For AI-systemer indeholder CRA en formodningsregel, som sparer fabrikanten for dobbeltarbejde. Er et produkt med digitale elementer klassificeret som et højrisiko-AI-system efter AI-forordningen (AI Act), kan produktet anses for at opfylde AI Act’s cybersikkerhedskrav i artikel 15, forudsat at (i) produktet opfylder de væsentlige cybersikkerhedskrav i CRA-bilag I, del I, (ii) fabrikantens processer opfylder de væsentlige krav i CRA-bilag I, del II, og (iii) det krævede cybersikkerhedsniveau dokumenteres gennem en EU-overensstemmelseserklæring udstedt efter CRA. Her trækker de to regelsæt altså i samme retning, men det forudsætter, at fabrikanten aktivt dokumenterer sammenhængen.

Endelig er det værd at holde CRA op mod NIS2-direktivet, som adresserer et andet, men nærliggende spørgsmål. Hvor CRA stiller produktkrav til fabrikanter, importører og distributører af produkter med digitale elementer, retter NIS2 sig mod driftssikkerheden hos de virksomheder (væsentlige og vigtige enheder), der anvender sådanne produkter i deres egen drift, herunder krav om ledelsesforankring, forsyningskædesikkerhed og hændelsesrapportering.

En virksomhed kan derfor være underlagt NIS2 som bruger af digitale produkter, samtidig med at den er underlagt CRA som fabrikant af sådanne produkter. De to regelsæt vil i praksis ofte spille sammen, fordi en NIS2-omfattet virksomheds indkøbsprocesser i stigende grad vil skulle kunne dokumentere, at leverandørernes produkter lever op til CRA.

Fra krav til praksis

Kravene i CRA er bevidst formuleret teknologineutralt og målrettet et bestemt resultat snarere end en bestemt metode. Det giver fleksibilitet, men betyder også, at den enkelte fabrikant selv skal omsætte kravene til konkrete tekniske valg. CRA foreskriver ikke nogen bestemt risikovurderingsmetode, og selv når en fabrikant vælger at anvende en harmoniseret standard, forbliver det fabrikanten selv, der bærer det fulde ansvar for at identificere produktets risici og vurdere, hvilke af de væsentlige krav der er relevante for netop det produkt. Vurderingen skal dokumenteres i den tekniske dokumentation, også i de tilfælde hvor fabrikanten har vurderet, at et krav ikke er relevant.

Kombinationen af et åbent og resultatorienteret regelsæt og et dokumentationskrav, der skal kunne forsvares over for markedsovervågningsmyndighederne, betyder, at compliancearbejdet ikke kan løftes af tekniske kompetencer alene. Der er behov for juridisk indsigt til at fortolke omfanget af de forskellige krav, vurdere samspillet med anden EU-produktlovgivning og sikre, at overensstemmelseserklæringer og teknisk dokumentation lever op til CRA’s formkrav. Samtidig kræver selve cybersikkerhedsrisikovurderingen og den tekniske implementering teknisk ekspertise. Samspillet mellem juraen og den tekniske vurdering er i sig selv en disciplin, som virksomhederne skal have opbygget.

Løfter man sig op i helikopteren, er her et bud på en simplificeret tjekliste:

• Kortlæg jeres produktportefølje, og vurdér for hvert produkt, om det udgør et “produkt med digitale elementer” med en direkte eller indirekte dataforbindelse.
• Afklar jeres rolle for hvert produkt (fabrikant, importør, distributør eller open source-softwareforvalter) og vær opmærksom på, om white label-salg eller væsentlige ændringer flytter jer over i fabrikantrollen.
• Gennemfør og dokumentér en cybersikkerhedsrisikovurdering for hvert relevant produkt, og hold den løbende opdateret gennem supportperioden.
• Fastlæg og dokumentér en supportperiode for hvert produkt, tilpasset dets forventede brugstid.
• Indfør en proces for due diligence ved integration af tredjepartskomponenter, herunder open source.
• Etablér en intern proces, der kan overholde rapporteringsfristerne på 24 timer, 72 timer og den endelige rapport, fra den 11. september 2026.
• Vælg den relevante overensstemmelsesvurderingsprocedure (modul A, B+C eller H), og forbered teknisk dokumentation, EU-overensstemmelseserklæring og CE-mærkning.
• Kortlæg samspillet med anden regulering, der gælder for jeres produkter (maskinforordningen, radioudstyrsdirektivet, AI-forordningen, NIS2 mv.).
• Sørg for, at jura og teknik arbejder sammen om både risikovurdering, dokumentation og kontraktgrundlag.

Efterhånden som vi nærmer os december 2027, vil det for mange producenter og importører være nødvendigt at grave endnu dybere:

Ud over at benytte Kommissionens FAQ og vejledning, som vi har henvist til gentagne gange ovenfor, kan vi tillige anbefale, at man drager nytte af ENISA’s SME Cyber Resilience Maturity Assessment Model. Der er tale om en Excel-template, hvor man kan score sin egen modenhed op mod CRA’s krav.

Tysklands BSI (Bundesamt für Sicherheit in der Informationstechnik) har udgivet den tekniske retningslinje TR-03183 i flere dele, som konkretiserer CRA’s krav til risikovurdering, software bill of materials (SBOM) og håndtering af sårbarhedsrapporter og -meddelelser. Retningslinjen er ikke bindende og erstattes, når de europæiske harmoniserede standarder foreligger, men giver allerede nu et praktisk og testbart grundlag for fabrikanter, der ikke har modne cybersikkerhedsprocesser.