Cybertrusler rammer ikke kun “IT-afdelingen” længere. De rammer produkter, der står i din kundes hjem, i kritisk infrastruktur, på hospitaler og i industrien, og de rammer hele værdikæder. Derfor er CRA blevet et centralt emne for producenter, importører, distributører og softwareleverandører, som arbejder med digitale produkter i EU.
I denne guide får du et praktisk overblik over CRA: hvem der er omfattet, hvilke produkter og hvilket scope der gælder, samt hvad secure by design betyder i praksis. Du får også konkrete takeaways, typiske faldgruber og en handlingsnær måde at komme i gang på, uden at drukne i jura.
Hvad er CRA, og hvorfor betyder det noget?
CRA står for Cyber Resilience Act og er en EU-forordning, der stiller krav til cybersikkerhed for produkter med digitale elementer gennem hele deres livscyklus. Kort sagt: Den skal løfte bundniveauet for sikkerhed i både hardware og software, så sårbarheder bliver færre, opdages hurtigere og håndteres mere ansvarligt.
Det betyder noget, fordi mange sikkerhedsproblemer i dag skyldes kendte fejl: svage standardindstillinger, manglende opdateringer, uklar ansvarskæde og utilstrækkelig dokumentation. CRA flytter forventningen fra “sikkerhed som tilvalg” til “sikkerhed som standard”.
Mini-konklusion: CRA gør cybersikkerhed til et produktkrav på linje med kvalitet og sikkerhed, og det påvirker både teknik, processer og kontrakter.
Hvem er omfattet: roller, ansvar og værdikæde
CRA rammer ikke kun “producenten” i klassisk forstand. Den taler ind i hele forsyningskæden, hvor flere aktører kan få pligter afhængigt af, hvem der udvikler, markedsfører, importerer eller ændrer et produkt.
Producenter og softwareudgivere
Hvis du udvikler eller får udviklet et produkt med digitale elementer og bringer det på EU-markedet under dit navn, får du typisk producentrollen. Det gælder også for softwareudgivere, når softwaren er et produkt i sig selv eller en del af et produkt. Du skal kunne dokumentere, at sikkerhedskrav er indarbejdet, at du har styr på sårbarheder, og at opdateringer leveres på en kontrolleret måde.
Importører, distributører og “rebranders”
Importører og distributører får pligter til at sikre, at produktet faktisk lever op til kravene, før det sælges videre. Hvis du rebrander eller laver væsentlige ændringer, kan du i praksis blive betragtet som producent med tilhørende ansvar. Derfor er leverandørstyring og klare kontrakter afgørende, også for virksomheder der “bare” videresælger.
Mini-konklusion: Tænk CRA som et ansvarskort: Hvem kan bevise sikkerhed, hvem kan opdatere, og hvem tager imod rapporter om sårbarheder?
Hvilke produkter er omfattet, og hvad ligger udenfor?
CRA dækker produkter med digitale elementer, altså hardware og software, der kan behandle data eller kommunikere. Det spænder bredt: IoT-enheder, netværksudstyr, operativsystemer, apps, styringssoftware, gateways, sensorer og meget mere. Den praktiske tommelfingerregel er, at hvis produktet kan forbindes, kan det også blive angrebsflade.
Der findes undtagelser og overlap til andre regelsæt. Eksempelvis kan bestemte produkter være reguleret af sektorspecifik lovgivning, som kan have egne cybersikkerhedskrav. I praksis skal du afklare, om CRA er primær ramme, eller om du ligger i et område med særregler og dobbelt compliance.
- Forbundne forbrugerprodukter: kameraer, routere, smart home-hubs
- Virksomhedsprodukter: firewalls, switches, identitets- og adgangskomponenter
- Indlejret software: firmware i udstyr og maskiner
- Standalone software: klienter, værktøjer og applikationer med sikkerhedsrelevans
- Komponenter og biblioteker, når de markedsføres som produkter
- Cloud-tilknyttede funktioner, hvis de er nødvendige for produktets sikkerhed
Mini-konklusion: Scope handler ikke om branche, men om digitale funktioner og risiko: alt, der kan opdateres, angribes eller misbruges, skal vurderes.
Scope i praksis: livscyklus, sårbarheder og opdateringer
CRA handler ikke kun om at “bygge sikkert”. Den handler også om at vedligeholde sikkerhed i hele produktets forventede levetid. Det skubber mange organisationer fra projekt-tankegang til produkt-tankegang, hvor sikkerhed er et løbende ansvar.
Sårbarhedshåndtering og rapportering
Du skal kunne modtage, triagere og udbedre sårbarheder. Det betyder en konkret proces for vulnerability management, hvor du kan dokumentere tidslinjer, prioritering, kommunikation og opdateringer. En offentlig kontaktkanal, klare retningslinjer for responsible disclosure og intern eskalation er typiske byggesten.
Patch-politik og supportperiode
En af de mest oversete dele er at definere, hvor længe du leverer sikkerhedsopdateringer. CRA presser på for, at dette ikke er vagt eller markedsføringsstyret, men forankret i en realistisk supportpolitik: Hvilke komponenter afhænger du af, hvor ofte kan du release, og hvordan leverer du patches uden at bryde kompatibilitet?
Midt i den juridiske og tekniske afklaring kan det være nyttigt at læse selve rammesætningen i Cyber Resilience Act for at spejle dine antagelser mod de faktiske forpligtelser og definitioner.
Mini-konklusion: Hvis du ikke kan patche og kommunikere sikkert, er det svært at være compliant, uanset hvor godt du kodede i første omgang.
Hvad betyder “secure by design” i praksis?
Secure by design betyder, at sikkerhed tænkes ind fra start: i krav, arkitektur, udvikling, test og drift. Det er ikke én feature, men et sæt designvalg, som reducerer risiko og gør fejl mindre sandsynlige og mindre skadelige.
Praktisk oversat til hverdagen handler det om at minimere angrebsfladen, bruge sikre standardindstillinger, og sikre at fejl kan opdages og begrænses. Det handler også om at undgå “skjult kompleksitet” som hardcodede credentials, uigennemsigtige afhængigheder og utestede opdateringsmekanismer.
- Start med en trusselsmodel for de vigtigste user journeys og integrationspunkter
- Vælg sikre standarder: kryptering, nøglerotation og stærk autentificering
- Design for mindst mulig privilegium og segmentér komponenter
- Byg en sikker update-kanal med signering og rollback-strategi
- Indfør automatiseret scanning af afhængigheder og container-images
- Gør logning og audit sporbar, men dataminimeret og privatlivsbevidst
Mini-konklusion: Secure by design er en metode: færre antagelser, mere verificering, og en arkitektur der tåler, at noget går galt.
Dokumentation og “compliance-artefakter” du faktisk kan bruge
Mange bliver nervøse ved tanken om dokumentation. Men den gode nyhed er, at dokumentation kan være en direkte støtte til kvalitet og drift, hvis du holder den tæt på udviklingsarbejdet. Det centrale er at kunne vise, hvad du har gjort, hvorfor du gjorde det, og hvordan du følger op.
Det vigtigste at få på plads
- SBOM (software bill of materials) eller tilsvarende overblik over komponenter
- Risikovurdering og trusselsmodel, opdateret ved væsentlige ændringer
- Sikkerhedskrav i backlog: autentificering, kryptering, logging, hardening
- Test- og reviewspor: code review, SAST/DAST, penetrationstest efter behov
- Patch-noter og kommunikationsskabeloner til kunder og partnere
- Vulnerability disclosure policy og intern incident playbook
Hold artefakterne “levende”: versionér dem, knyt dem til releases, og gør det let at auditere. En SBOM uden proces for opdatering er en pæn fil, men ikke styring.
Mini-konklusion: God CRA-dokumentation er ikke papirarbejde; det er sporbarhed, der gør fejl billigere at rette og lettere at forklare.
Typiske faldgruber – og hvordan du undgår dem
De fleste CRA-problemer opstår ikke, fordi nogen er ligeglade, men fordi ansvar og forventninger bliver uklare. Her er de mest almindelige fejl, der går igen på tværs af teams og leverandørkæder.
Faldgruber i produkt og proces
En klassiker er at tro, at en enkelt penetrationstest “gør produktet sikkert”. En anden er at undervurdere afhængigheder: open source-biblioteker, tredjeparts-SDK’er og build pipelines. Derudover ser man ofte manglende ejerforhold til opdateringer: Hvem beslutter, hvornår der patches, og hvem kommunikerer til kunder?
Sådan reducerer du risikoen hurtigt
- Udpeg en produktansvarlig for sikkerhed pr. produktlinje, ikke pr. projekt
- Indfør release gates: ingen release uden opdateret SBOM og kritiske fixes håndteret
- Lav leverandørkrav: sikkerhedskrav, SLA for sårbarheder og ret til audit
- Træn support og salg i sikkerhedskommunikation, så budskaber er konsistente
- Brug “secure defaults” og fjern usikre funktioner, også hvis de er historiske
Mini-konklusion: Det hurtigste løft kommer ofte fra klare ejere, faste gates og bedre leverandørstyring, ikke fra flere værktøjer.
Hvad koster CRA, og hvordan planlægger du indsatsen?
Spørgsmålet “hvad koster det?” afhænger af modenhed og produktportefølje. For nogle er det primært proces og dokumentation; for andre kræver det redesign af update-mekanisme, autentificering eller rettighedsmodel. Omkostningen består typisk af tid fra udvikling, sikkerhed, kvalitet, produktledelse og juridisk/indkøb.
En pragmatisk måde at planlægge på er at lave en gap-analyse pr. produkt: Hvilke krav opfylder vi allerede, hvor er risikoen størst, og hvad er den billigste ændring med størst effekt? Ofte kan du få stor effekt ved at standardisere på tværs: én disclosure-proces, én SBOM-praksis, én patch-politik, og en fælles skabelon for risikovurdering.
Som tommelfingerregel: Hvis du allerede arbejder med CI/CD, automatiseret scanning og en disciplineret releaseproces, bliver CRA mere en struktureret “pakning” af det, du gør. Hvis opdateringer er ad hoc, bliver det en større investering at skabe driftssikkerhed.
Mini-konklusion: CRA koster mindst, når du genbruger platforme og processer på tværs af produkter og gør sikkerhed til en del af normal udvikling.
Bedste praksis: en kort tjekliste til at komme i gang
Hvis du vil omsætte krav til handling uden at miste overblikket, så start med det, der skaber kontrol: inventar, ejerskab og en stabil opdateringsmotor. Det gør resten lettere, også når du skal dokumentere og kommunikere.
- Lav en produktliste med ejere, supportperiode og opdateringskanaler
- Identificér kritiske angrebsflader: login, netværk, update, API’er, fysisk adgang
- Indfør SBOM og afhængighedsstyring som en del af build og release
- Definér en sårbarhedsproces med tidsmål, triage og kundekommunikation
- Gennemgå standardindstillinger: fjern default passwords og luk unødige porte
- Planlæg sikkerhedstests risikobaseret og gentag ved større ændringer
Mini-konklusion: Du behøver ikke gøre alt på én gang, men du skal kunne vise retning, ejerskab og en fungerende cyklus for forbedringer.
