EU er i gang med at gøre noget ret typisk EU-agtigt: at tage et kæmpe, rodet problem (usikre digitale produkter) og forsøge at gøre det en smule mindre rodet med regler. Det lyder kedeligt, men CRA (Cyber Resilience Act) er faktisk ret vigtigt, hvis du arbejder med software, IoT, digitale produkter, eller bare har et produkt med “smart” i navnet.
Kort sagt: CRA handler om, at produkter med digitale elementer skal være mere sikre fra starten og ikke først blive “sikre”, når nogen bliver hacket og skriver en sur mail.
I denne guide får du CRA forklaret i menneskesprog:
- hvad CRA er og hvem det rammer
- hvad “secure-by-design” betyder i praksis
- hvilke dokumentationskrav du skal forvente
- hvordan du kan forberede dig uden at gå i panik
Hvad er CRA, helt enkelt?
CRA (Cyber Resilience Act) er EU-regler, der stiller krav til cybersikkerhed for produkter med digitale elementer. Altså alt det, der enten er software, kører software, eller på nogen måde kan forbindes til noget (internettet, et netværk, en app, en cloud-tjeneste osv.).
Målet er at hæve bundniveauet for sikkerhed i produkter, så:
- der er færre “default passwords” og nemme sårbarheder
- producenter tager ansvar for sikkerhed gennem hele produktets levetid
- kunder (B2B og forbrugere) får mere gennemsigtighed og bedre sikkerhed
Det er ikke kun “big tech”, der bliver ramt. Det er også helt almindelige virksomheder, der udvikler apps, plugins, devices, styresystemer, platforme, firmware, smarte dimser, eller indlejret software.
Hvilke produkter kan være omfattet?
Hvis dit produkt har digitale elementer og sælges i EU, så bør du i det mindste læse overskrifterne.
Typiske eksempler:
- IoT-enheder (kameraer, alarmer, sensorer, smarte låse)
- netværksudstyr og “smart” hardware
- softwareprodukter og apps
- komponenter som biblioteker og moduler (afhængigt af hvordan de leveres)
- produkter med firmware/indlejret software
- industrielle systemer og løsninger med connectivity
Det afgørende er ofte: Kan det påvirkes via digital adgang? Hvis ja, så er det relevant at kigge på.
Hvem får ansvaret?
CRA er ret ligeglad med, om du “bare” er producent, importør eller distributør. Den vil have, at nogen tager ansvar.
I praksis handler det især om:
- Producenter: skal bygge sikkerhed ind og dokumentere det
- Importører: skal sikre, at produkter ind i EU opfylder krav
- Distributører: skal ikke sælge noget, der tydeligt ikke lever op til kravene
Hvis du bygger produkter, er du i skudlinjen. Hvis du videresælger, kan du også blive trukket ind i det, især hvis du sætter dit navn på eller ændrer produktet.
Secure-by-design: Hvad betyder det i praksis?
“Secure-by-design” lyder som noget, man sætter på et PowerPoint-slide og glemmer igen. Men CRA presser i retning af, at secure-by-design bliver en konkret disciplin.
Det betyder groft sagt:
- Du skal tænke sikkerhed ind fra starten (krav, design, udvikling)
- Du skal minimere angrebsfladen
- Du skal have styr på sårbarheder, opdateringer og respons
- Du skal kunne bevise, at du gør det
Secure-by-design i praksis ligner ofte det her:
1) Baseline sikkerhedskrav i dit produkt
- Ingen “standard admin/admin”
- Stærk adgangskontrol og rettighedsstyring
- Kryptering hvor relevant (data i transit og evt. i hvile)
- Logging af vigtige sikkerhedshændelser
- Sikre standardindstillinger (secure-by-default)
2) Sikker udviklingsproces (SSDLC)
- Threat modeling (tænk “hvordan kan det misbruges?”)
- Code review og sikkerhedstests
- Dependency management (styr på open source komponenter)
- CI/CD med scanning (SAST/DAST, secrets scanning)
- Release gates (hvad skal være opfyldt før release?)
3) Patch- og opdateringsdisciplin
- Hvordan udgiver du sikkerhedsopdateringer?
- Hvor hurtigt kan du reagere på en kritisk sårbarhed?
- Har du en plan for supportperiode (produktets “security lifetime”)?
Secure-by-design er altså ikke én ting. Det er en række valg, processer og kontroller, der samlet gør produktet sværere at kompromittere.
Secure-by-default: Den oversete del
CRA skubber også på “secure-by-default”, som i praksis betyder:
- sikkerhed er standarden, ikke en tilvalgsknap
- brugeren skal ikke være sikkerhedsekspert for at være sikker
Eksempel: Hvis dit produkt kan sættes op på en usikker måde, så vil nogen gøre det. Det er ikke fordi mennesker er dumme. Det er fordi de har travlt og vil have det til at virke.
Dokumentationskrav: Det, der ender med at tage tid
Her kommer den del, som får mange teams til at sukke: dokumentation.
CRA handler ikke kun om at være sikker. Det handler også om at kunne demonstrere det. Du skal kunne forklare:
- hvilke sikkerhedstiltag du har bygget ind
- hvilke risici du har vurderet
- hvordan du håndterer sårbarheder og opdateringer
- hvilke kontroller og tests du har kørt
Typiske dokumentationselementer (praktisk oversat)
Du kan forvente behov for noget i retning af:
- Teknisk dokumentation af sikkerhedsdesign og arkitektur
- Risikovurdering (hvilke trusler er relevante, og hvordan mitigere du dem?)
- Sikkerhedskrav og hvordan de er opfyldt
- SBOM (Software Bill of Materials) eller tilsvarende oversigt over komponenter (ofte relevant i praksis)
- Sårbarhedshåndtering: proces for modtagelse, triage, patch og disclosure
- Opdaterings- og supportpolitik: hvor længe leverer du sikkerhedsopdateringer?
- Test- og valideringsdokumentation: scanning, pentest, QA-sikkerhedstjek
- Brugerinformation: sikker opsætning, anbefalinger, og hvad brugeren skal gøre
Dokumentation behøver ikke være 200 sider. Men den skal være struktureret, sporbar og opdateret.
Produktkrav: Hvad skal du typisk have styr på?
CRA’s ånd er ret klar: færre sårbarheder, bedre patching, mere ansvar. Hvis vi omsætter det til en praktisk “produkt-tjekliste”, ligner det her:
Tjekliste: CRA-ready produkt (i store træk)
Sikkerhedsfundament
- Ingen hårdkodede credentials eller svage standard-login
- Adgangskontrol og roller er gennemtænkt
- Kryptering anvendes korrekt og konsekvent
- Inputvalidering og beskyttelse mod de klassiske angreb (OWASP-typer)
- Logging og overvågning af sikkerhedsrelevante events
Udvikling og drift
- Secure coding guidelines bruges aktivt
- Automatiske scanninger i pipeline (SAST/secrets/dependencies)
- Patch-proces med SLA-lignende mål for kritiske issues
- Incident response plan (hvem gør hvad, hvornår?)
Dokumentation og transparens
- Risikoanalyse + designbeslutninger kan forklares
- Komponentoverblik (hvad består produktet af?)
- Support- og opdateringspolitik er tydelig
- Brugerinformation om sikker opsætning findes og er forståelig
Hvis du allerede arbejder seriøst med sikker udvikling, er det ikke en revolution. Det er mere en “nu skal det også kunne tåle en kontrol”-ting.
CRA vs. NIS2: Hvad er forskellen?
Mange blander CRA sammen med NIS2, fordi de begge handler om cybersikkerhed i EU. Men de rammer forskellige ting:
- NIS2: handler primært om organisationers cybersikkerhed, governance, risikostyring og krav til drift og leverandører (hvem der skal gøre hvad som virksomhed).
- CRA: handler primært om produktsikkerhed for digitale produkter, der sælges på markedet.
Der er overlap i praktiske discipliner (risikovurdering, incident response, dokumentation), men CRA er meget mere produkt- og producentorienteret.
Hvis du gerne vil se, hvordan compliance kan gribes praktisk an i en virksomhedskontekst, kan du læse NIS2 compliance i praksis.
Hvad betyder CRA for mindre teams og startups?
Den kedelige sandhed: CRA kan føles tung, især hvis du er et lille team, der bare prøver at shippe features og overleve.
Den mindre kedelige sandhed: hvis du gør det rigtigt, kan CRA faktisk blive en konkurrencefordel.
Sådan kan du gøre det overkommeligt
- Start med en baseline: få styr på credentials, patching og logging
- Automatisér alt det kedelige: dependency scanning, secrets scanning, CI checks
- Dokumentér løbende: små noter undervejs slår “skriv alt om 6 måneder”
- Vælg et simpelt framework: en fast skabelon til risiko og sikkerhedskrav
Målet er ikke at skabe et papir-monster. Målet er at kunne vise, at du har styr på sikkerheden på en moden og repeterbar måde.
Praktisk plan: Sådan forbereder du dig trin for trin
Hvis du vil være effektiv (og ikke bruge tre uger på at “læse dig varm”), så gør det sådan her:
Trin 1: Kortlæg produktet
- Hvad er produktet, og hvilke dele er digitale?
- Hvor er de største angrebsflader? (API’er, login, netværk, firmware, integrationspunkter)
Trin 2: Threat model light
Du behøver ikke en 80-siders analyse. Start med:
- Hvad kan gå galt?
- Hvad er konsekvensen?
- Hvordan forhindrer vi det?
Trin 3: Lav en “CRA baseline” backlog
Lav konkrete tasks:
- fjern default credentials
- implementér sikker reset-flow
- harden configs
- opdater logging
- tilføj scanning i pipeline
- definer patch-proces
Trin 4: Dokumentér i samme sprint
Hver gang du laver et sikkerhedstiltag, tilføj:
- hvad gjorde vi?
- hvorfor?
- hvor kan det ses/testes?
Trin 5: Sårbarhedshåndtering og disclosure
- hvor rapporterer folk sårbarheder?
- hvem svarer?
- hvad er jeres standard responstid?
- hvordan frigiver I fixes?
Det her er ofte den del, virksomheder mangler mest.
Typiske faldgruber (så du kan undgå dem)
“Vi har en sikkerhedspolitik, så vi er nok fine”
Nej. CRA handler om produkt og praksis, ikke kun en PDF.
“Vi patcher, når vi får tid”
CRA presser i retning af mere forpligtende opdateringsdisciplin. “Når vi får tid” er en strategi, lige indtil det bliver dyrt.
“Dokumentation kan vi lave til sidst”
Du kan, men så bliver det dyrt, upræcist og fyldt med gætterier. Dokumentér i små bidder løbende.
“Det her gælder kun enterprise”
Nej. Små produkter kan være lige så usikre (ofte mere), og de kan stadig rammes.
FAQ om CRA
Hvad er CRA?
CRA (Cyber Resilience Act) er EU-regler, der stiller cybersikkerhedskrav til produkter med digitale elementer, så de bliver mere sikre fra start og gennem hele levetiden.
Hvad betyder secure-by-design?
At sikkerhed tænkes ind fra design og udvikling, ikke som en eftertanke. Det inkluderer bl.a. risikovurdering, sikker udviklingsproces, test, og patching.
Hvad er secure-by-default?
At produktet som standard er sat op sikkert, så brugeren ikke skal foretage “avancerede” valg for at undgå usikre konfigurationer.
Hvilken dokumentation skal man typisk have?
Teknisk sikkerhedsdokumentation, risikovurdering, proces for sårbarhedshåndtering, opdateringspolitik og ofte et overblik over softwarekomponenter (fx SBOM-lignende).
Er CRA det samme som NIS2?
Nej. NIS2 handler primært om organisatorisk cybersikkerhed og governance. CRA handler primært om produktsikkerhed for digitale produkter på markedet.
Konklusion
CRA er EU’s måde at sige: “Hvis du sælger digitale produkter, så skal du tage sikkerhed seriøst, og du skal kunne bevise det.”
Det vigtigste du kan tage med:
- få secure-by-design ind i udviklingen (ikke kun i præsentationen)
- byg secure-by-default ind, så standardopsætningen er sikker
- få styr på patching og sårbarhedshåndtering
- dokumentér løbende, så compliance ikke bliver et mareridt
Det er ikke glamourøst, men det er sådan, man undgår at blive næste case study i “hvordan det gik galt”, fordi nogen shipped et produkt med “admin/admin” og håb i hjertet.
