Gælder Cyber Resilience Act også for dig som selvstændig?

Annonce – sponsoreret indhold.

Ja, Cyber Resilience Act som selvstændig kan sagtens gælde for dig. Loven (CRA) regulerer produkter, ikke virksomhedsformer. Hvis du som enkeltmandsvirksomhed udvikler og sælger en app, en smart gadget eller en IoT-enhed med netværksforbindelse, kan du i lovens øjne være producent med de forpligtelser, det medfører. Hvis dit projekt derimod er en ren hobby uden salg eller anden kommerciel aktivitet, er du som udgangspunkt uden for. Grænsen mellem de to situationer er mere flydende, end mange tror.

Cyber resilience act som selvstændig: det er produktet, der tæller, ikke CVR-nummeret

CRA er EU-forordning 2024/2847 og stiller cybersikkerhedskrav til produkter med digitale elementer. Det dækker hardware og software, der er, eller kan blive, forbundet til en enhed eller et netværk. Kravene gælder produktet, udviklingsprocessen og den dokumentation, der følger med. Loven handler altså om, hvordan produktet er bygget, og hvordan du håndterer sikkerhedshuller, efter at det er solgt.

Forordningen er trådt i kraft, men kravene indfases gradvist. Pligten til at rapportere aktivt udnyttede sårbarheder og alvorlige sikkerhedshændelser gælder fra 11. september 2026. De øvrige hovedkrav gælder fra 11. december 2027. Det lyder som lang tid, men produktbeslutninger, du træffer nu, kan afgøre, om en enhed, du sælger i 2028, overhovedet må få CE-mærke.

Virksomhedsstørrelse er ikke afgørende, fordi loven er bygget som produktlovgivning, ligesom reglerne om elektronik og legetøj. Hvis et produkt bringes på det europæiske marked som led i en erhvervsmæssig aktivitet, er der en producent med ansvar, og det kan være dig alene. Der findes lempelser for mikro- og små virksomheder, blandt andet i forbindelse med rapportering og dokumentation, men de fritager ikke for de grundlæggende sikkerhedskrav.

Mange undervurderer, hvor tidligt det betaler sig at starte. Sikkerhed er langt billigere at tænke ind i en arkitektur, mens den stadig er på tegnebrættet, end at bygge ind bagefter. Derfor er det fornuftigt at begynde sin forberedelse til CRA allerede nu. En kort afklaring af, om dit produkt overhovedet er omfattet, og hvilke krav der i så fald gælder, kan spare dig for dyre omveje senere.

Hvilke tegn viser, at dit produkt kan være omfattet?

Du behøver ikke læse hele forordningen for at få en første fornemmelse. Stil dig selv disse spørgsmål:

• Har produktet en dataforbindelse? Wi-Fi, Bluetooth, mobilnetværk, USB eller en app, der taler med en enhed, tæller alle med.
• Indeholder det software eller firmware? Også hvis du selv har sat det sammen af færdige moduler og open source-biblioteker.
• Sælger du det, eller tjener du på det på anden vis? Salg til forbrugere eller virksomheder er det tydeligste tegn på erhvervsmæssig aktivitet. Et abonnement eller betalt support kan også pege i den retning.
• Udsender du softwareopdateringer? Hvis du retter fejl eller tilføjer funktioner efter salget, har du allerede en opdateringsproces. CRA stiller krav til, hvordan den fungerer.
• Bliver produktet brugt i EU? Loven følger markedet, ikke din adresse. Sælger du fra Danmark til kunder i EU, er du omfattet, og det samme gælder, hvis du sidder uden for EU og sælger til europæiske kunder.
• Kan en sikkerhedsfejl ramme andre? En smart dørlås, et babyalarmsystem og en wearable er eksempler, hvor et hul kan have konkrete konsekvenser for brugeren.

Svarer du ja til de første tre, bør du tage spørgsmålet alvorligt og få det afklaret.

Hvornår er du som regel uden for loven?

Der er flere undtagelser, men de er snævrere, end de lyder:

• Rene hobbyprojekter, som du hverken sælger eller tjener penge på, er ikke omfattet. Så snart du tager betaling, sælger hardware eller lader projektet indgå i din forretning, ændrer billedet sig.
• Ikke-kommerciel open source er som udgangspunkt undtaget. Lægger du derimod din kode på GitHub og samtidig sælger en enhed eller tjeneste bygget på den, er produktet kommercielt.
• Rene webtjenester (SaaS) er som udgangspunkt reguleret andetsteds, blandt andet af NIS2. Men en app eller en enhed, der er afhængig af en fjernstyret databehandlingsløsning, kan blive vurderet samlet som ét produkt.
• Produkter under anden særlovgivning, fx medicinsk udstyr og køretøjer, følger deres egne regelsæt.

Er du i tvivl, så tag ikke din egen vurdering for gode varer. Forordningens definitioner har mange nuancer, og EU-Kommissionen og ENISA offentliggør løbende vejledning. Til en konkret vurdering af dit produkt er individuel rådgivning det sikreste.

Hvad kræver CRA af dig som producent?

Kravene afhænger af produktets kategori. De fleste produkter hører til standardkategorien, hvor producenten selv kan foretage overensstemmelsesvurderingen. Produkter, der er vigtige eller kritiske for cybersikkerheden, fx visse sikkerhedsprodukter, har strengere krav og ofte tredjepartsvurdering. Dit produkt skal altså placeres i den rigtige kategori, før du kender din arbejdsbyrde.

Overordnet forventes det, at du som producent:

1. Bygger sikkerhed ind fra start (secure by design), fx ingen standardadgangskoder og en rimelig beskyttelse af data.
2. Håndterer sårbarheder løbende, så du kan modtage rapporter, rette fejl og informere brugerne.
3. Leverer sikkerhedsopdateringer i en supportperiode. Som udgangspunkt skal den være mindst fem år, medmindre produktet forventes brugt i kortere tid.
4. Udarbejder teknisk dokumentation og brugerinformation, så produktet kan vurderes og bruges sikkert.
5. Rapporterer aktivt udnyttede sårbarheder og alvorlige hændelser til de relevante myndigheder.
6. Fører en oversigt over softwarekomponenter (SBOM), så du ved, hvad dit produkt indeholder.

Brugen af tredjepartskomponenter fritager dig ikke. Hvis du bygger på et open source-bibliotek, skal du udvise rettidig omhu og vide, hvad du indbygger i dit produkt. Mangler du overblikket over dine afhængigheder, er det ofte det første, der skal rettes op på.

Hvordan kommer du i gang uden at drukne i bureaukrati?

Som lille aktør har du hverken en compliance-afdeling eller tid til at læse lovtekst i ugevis. Du kan dog komme langt med få, konkrete skridt.

1. Kortlæg dit produkt

Skriv på én side, hvad produktet er, hvilke dele der er software, hvilke forbindelser det har, og hvem der bruger det. Tilføj, hvor produktet sælges, og hvem der har ansvar for hvad, hvis du har underleverandører, produktionspartnere eller importører. Dette dokument er grundlaget for alt det andet.

2. Lav en liste over softwarekomponenter

Notér de biblioteker, frameworks, firmwaredele og tjenester, du bruger, med versionsnumre. Mange pakkehåndteringsværktøjer kan generere en sådan liste automatisk, og den bliver senere kernen i din SBOM.

3. Beskriv din opdateringsproces

Hvordan opdager du, at et bibliotek har en kendt sårbarhed? Hvordan når en rettelse ud til kunderne? Og hvem kan en forsker kontakte, hvis vedkommende finder en fejl? Et fast kontaktpunkt for sikkerhedsmeldinger og en kort procedure for, hvad du gør, når en rapport lander i din indbakke, er et godt udgangspunkt.

4. Saml dokumentationen løbende

Gem beslutninger om sikkerhed, risikovurderinger og tests, mens du arbejder. Det er meget nemmere end at rekonstruere dem bagefter. En simpel mappe med dato og begrundelse for centrale valg er bedre end ingenting.

5. Få en uvildig vurdering

Når grundmaterialet er samlet, kan en specialist hurtigt pege på huller og prioritere indsatsen. Nesp.ONE tilbyder blandt andet en uforpligtende samtale og en foranalyse (GAP-analyse), hvor produkt, softwarekomponenter, udviklingsproces og dokumentation gennemgås, og du ender med en konkret handlingsplan. For en enkeltmandsvirksomhed er det en investering, så overvej den op imod, hvor meget af din omsætning der hviler på produktet.

Hvad betyder det for dig som iværksætter?

Der er en personlig dimension i det her. Så længe et projekt er en hobby, er det dig selv, du svarer til. Når det bliver til en forretning, har du pludselig ansvar over for kunder, som stoler på, at produktet er sikkert. Det kan føles som en bremse, men det er også tegn på, at du er gået fra at lege til at drive virksomhed.

Den mest almindelige fejl er at vente. Man tænker, at loven først gælder om et par år, og at man tager det, når kunderne spørger. Men designvalg som opdateringsmekanisme, dataopbevaring og valg af komponenter er svære at ændre, når produktet først er på markedet. Og store kunder og distributører begynder allerede at spørge ind til sikkerhed og dokumentation, før kravene formelt træder i kraft.

Realistisk set behøver du ikke gøre alt på én gang. Start med at afklare, om dit produkt er omfattet. Er svaret ja, så kortlæg, dokumentér og beskriv din opdateringsproces, og få derefter en specialist til at gennemgå materialet. Er svaret nej, har du i det mindste fået styr på dit produkts sikkerhed, og det kommer dig til gode uanset hvad. Og kan du ikke afgøre det selv, er det klogt at få en professionel til at se på sagen, før du lancerer næste version.