Hvis du stadig tænker sikkerhed som noget, man “leverer” én gang ved release, så kommer CRA til at gøre ondt — ikke fordi kravene er urealistiske, men fordi de flytter ansvaret fra projekt til drift.
I denne artikel får du et praktisk overblik over, hvordan EU’s Cyber Resilience Act ændrer spillereglerne: fra engangslevering til løbende ansvar for sårbarheder, opdateringer og dokumentation. Du får konkrete greb til at organisere arbejdet, eksempler på hvad dokumentation typisk består af, og de mest almindelige faldgruber (så du kan undgå dem).
Du kan læse artiklen som en tjekliste til at vurdere jeres nuværende setup: Hvad skal I kunne som producent, importør eller distributør? Hvilke processer skal være på plads? Og hvad koster det reelt i tid og penge at gå fra “best effort” til systematisk sikkerhedsansvar?
Hvad CRA er — og hvorfor den ændrer fokus
Cyber Resilience Act (CRA) er en EU-forordning, der stiller krav til cybersikkerhed for produkter med digitale elementer (hardware, software og kombinationer), som sælges i EU. Kort sagt: du skal kunne dokumentere et passende sikkerhedsniveau, håndtere sårbarheder løbende og levere sikkerhedsopdateringer — ikke kun ved lancering, men gennem produktets forventede levetid.
Det afgørende skift er, at sikkerhed ikke længere primært vurderes som en “tilstand” ved markedsføringstidspunktet, men som en kapabilitet: Kan organisationen opdage, prioritere og afhjælpe problemer hurtigt og konsekvent? Mange teams har allerede dele af det (CI/CD, monitoring, issue tracking), men CRA binder det sammen og kræver sporbarhed.
Mini-konklusion: CRA gør sikkerhed til en løbende leverance: processer, evidens og opdateringer bliver lige så vigtige som features.
Fra “ship it” til livscyklus: det løbende ansvar i praksis
I mange produktorganisationer stopper sikkerhedsindsatsen reelt ved release: en pen-test, en checkliste, måske en tredje parts review. Under CRA bliver “done” udskiftet med “driftbart”: du skal kunne vise, at du har en kontinuerlig sårbarhedshåndtering og at opdateringer faktisk kan nå ud til kunderne.
Sårbarhedshåndtering er ikke et projekt — det er en driftsevne
Det betyder bl.a., at du skal have et fungerende flow for: modtagelse af rapporter (f.eks. fra kunder eller forskere), triage, reproduktion, risikovurdering, udrulning af fix og kommunikation. Hvis du i dag håndterer sager “ad hoc” i Slack, er du sårbar: du kan hverken bevise responstider eller vise konsistens.
Opdateringer: distribution, kompatibilitet og “hvad hvis kunden ikke opdaterer?”
Opdateringer lyder simpelt, men i praksis er der klassiske knaster: legacy-enheder, offline-miljøer, kunders change windows og afhængigheder til tredjepartskomponenter. CRA presser dig til at tænke det igennem på forhånd: Hvordan leverer du patches sikkert? Hvordan validerer du, at opdateringen ikke bryder kritiske funktioner? Og hvordan håndterer du kunder, der ikke kan eller vil opdatere?
Mini-konklusion: Hvis I ikke kan patch’e hurtigt og kontrolleret, bliver compliance et organisatorisk problem — ikke et juridisk.
Dokumentation: fra “nice to have” til bevismateriale
Dokumentation er ofte det, der bliver nedprioriteret, når roadmap’et strammer. Under CRA bliver dokumentation en del af produktet: den skal være opdateret, genfindelig og koblet til jeres udviklings- og sikkerhedsprocesser.
Hvad dokumentation typisk består af
Du behøver ikke opfinde alt fra bunden, men du skal kunne samle evidens på en måde, der giver mening for både interne og eksterne parter. I praksis ser jeg ofte, at følgende artefakter går igen i audits og modenhedschecks:
- En opdateret oversigt over produktets komponenter og afhængigheder (ofte via SBOM).
- Threat modeling eller risikovurdering, der matcher produktets faktiske brugsscenarier.
- Secure development-processer (code review, CI-sikkerhedstjek, release gates).
- Sårbarhedshåndteringsproces inkl. roller, eskalation og kommunikationsskabeloner.
- Patch- og release-notes med sikkerhedsrelevante ændringer.
- Test- og valideringsspor (hvad der er testet, hvornår, og med hvilke resultater).
Sporbarhed: “kan vi vise det?”
Det er ikke nok at sige, at I gør tingene. I skal kunne vise: hvornår blev en sårbarhed opdaget, hvornår blev den triageret, hvornår blev fix’et releaset, og hvordan blev kunder informeret. Det kræver disciplin i værktøjer (issue trackers, release pipelines, artifact repositories) og en fælles taksonomi for sikkerhedssager.
Mini-konklusion: God dokumentation er ikke papirarbejde; det er jeres bevis for kontrol og gentagelighed.
Roller og ansvar: hvem “ejer” sikkerheden efter release?
CRA skubber ansvaret ud i organisationen. Det kan ikke bæres af én sikkerhedsperson alene, og det kan ikke løses som en enkelt compliance-øvelse. Det kræver klare ejerskaber på tværs af produkt, udvikling, drift og support.
En praktisk måde at komme i gang på er at lave en simpel RACI for sikkerhedsopgaver (Responsible, Accountable, Consulted, Informed). I mange virksomheder er det især disse områder, der skaber friktion, hvis de ikke afklares tidligt:
- Hvem godkender en sikkerhedsrelease, hvis den kolliderer med planlagte features?
- Hvem ejer SBOM og tredjepartslicenser, når komponenter opdateres?
- Hvem kommunikerer med kunder ved kritiske sårbarheder?
- Hvem beslutter “end-of-support” og hvad der loves i forhold til patching?
- Hvem måler og rapporterer responstider og backlog på sikkerhedsgæld?
Min erfaring er, at mange teams allerede gør 80% af det rigtige, men de har ikke en fælles “driftskontrakt” for sikkerhed: hvornår noget er kritisk, hvordan det prioriteres, og hvad der udløser en hotfix.
Sådan omsætter du krav til handling: et pragmatisk roadmap
Hvis du vil undgå at CRA bliver en brandøvelse, så byg et roadmap i tre niveauer: stabiliser basis, skab gentagelighed, og løft modenheden. Det kan gøres uden at stoppe udviklingen — men kun hvis du prioriterer det som produktarbejde.
Her er et konkret forløb, der ofte virker i praksis, når jeg hjælper teams med at gå fra “vi burde” til “vi kan”:
- Fase 1 (2–6 uger): Kortlæg produkter, dataflows, afhængigheder og opdateringskanaler. Etabler én kanal til sårbarhedsrapportering og én proces for triage.
- Fase 2 (1–3 måneder): Automatisér basale sikkerhedstjek i CI (SAST/dependency scanning), standardisér release-notes og indfør faste SLA’er for sårbarheder.
- Fase 3 (kvartalsvis): Threat modeling som en fast del af større ændringer, bedre testdækning for sikkerhedsfixes, og løbende måling af “time to remediate”.
Det vigtige er, at hver fase producerer noget, der kan bruges som dokumentation og som gør jer hurtigere næste gang. Compliance bliver en sideeffekt af god praksis.
Mini-konklusion: Tænk CRA som en modenhedsrejse: små, målbare skridt slår store engangsprojekter.
Hvad koster CRA typisk? (Tid, ressourcer og skjulte udgifter)
Spørgsmålet “hvad koster det?” kan ikke besvares med ét tal, men du kan estimere ud fra tre drivere: produktkompleksitet, releasefrekvens og hvor meget der er outsourcet/afhængigt af tredjepart. Et team med hyppige releases og god CI/CD kan ofte tilpasse sig hurtigere end et team med lange releasecyklusser og mange manuelle processer.
Som tommelfingerregel ser jeg ofte, at virksomheder undervurderer to ting: 1) tiden til at få dokumentation og sporbarhed på plads, og 2) løbende vedligehold af dependency chains (især når upstream-projekter ændrer API’er eller udfaser support). I praksis er omkostningen sjældent kun “sikkerhedsværktøjer”; den ligger i arbejdstid, procesændringer og prioriteringskonflikter.
Hvis du leder efter en mere samlet indgang til forløbet, kan du tage udgangspunkt i CRA compliance og bruge det som ramme til at vurdere gap’et mellem jeres nuværende praksis og det, I skal kunne bevise.
Mini-konklusion: Budgettér ikke kun til scanning og audits — budgettér til vedvarende patching, komponentopdateringer og intern koordinering.
Typiske fejl og faldgruber (og hvordan du undgår dem)
De mest almindelige problemer opstår ikke, fordi teams ignorerer sikkerhed, men fordi de gør den svær at gentage. Her er faldgruber, jeg ser igen og igen — og den praktiske modgift:
- Faldgrube: “Vi laver en SBOM én gang.” Undgå: Generér den automatisk pr. build/release og versionér den sammen med artefakter.
- Faldgrube: Sårbarheder håndteres i e-mails og chat. Undgå: Én central sagstype i issue tracker med faste felter (CVSS/impact, scope, deadlines).
- Faldgrube: Patch-processen kræver helteindsats. Undgå: Standardiser hotfix-flow og rollback, og test det som en del af driften.
- Faldgrube: Uklare supportvinduer (“vi understøtter det så længe det giver mening”). Undgå: Definér produktlevetid, end-of-support og kommunikation i kontrakter og dokumentation.
- Faldgrube: Tredjepartskomponenter opdateres for sent. Undgå: Etabler faste dependency review-cyklusser og “evergreen”-principper for kritiske biblioteker.
En hurtig sanity check: Hvis en kritisk sårbarhed rammer en central komponent i dag, kan I så med ro i maven svare på “hvem gør hvad de næste 48 timer?” Hvis ikke, er det dér, du får mest værdi af at starte.
Bedste praksis: sådan gør du sikkerhed og dokumentation til en rutine
Målet er ikke flere møder eller mere papir. Målet er, at sikkerhed og dokumentation sker som en naturlig del af udvikling og drift. I praksis handler det om at gøre den sikre vej til den letteste vej.
Indbyg sikkerhed i release-rytmen
Fast cadence slår spontane indsatser. Planlæg fx en månedlig “security maintenance release”, hvor du samler dependency updates, små hardening-tiltag og lav/medium findings. Når en kritisk sag rammer, har du allerede en motor, der kan køre hurtigere.
Mål det, der betyder noget
Du behøver ikke 20 KPI’er. Men du bør som minimum kunne følge udviklingen i:
- Time to triage (fra modtaget rapport til første vurdering)
- Time to remediate (fra bekræftet sårbarhed til fix i release)
- Andel af komponenter uden kendte kritiske sårbarheder
- Patch-adoption hos kunder (hvor mange kører seneste sikkerhedsrelease)
Mini-konklusion: Når du kan måle og gentage, kan du også dokumentere — og så bliver CRA-kravene langt mere håndterbare.
Hvad du kan gøre i morgen: en kort tjekliste til at komme i gang
Hvis du vil skabe momentum uden at drukne i detaljer, så start med de handlinger, der både reducerer risiko og øger sporbarhed:
- Beslut ét sted, hvor alle sårbarheder registreres og prioriteres.
- Definér 3 severity-niveauer og en simpel SLA for hvert niveau.
- Få styr på jeres opdateringskanal: hvordan leverer I patches, og hvordan validerer I dem?
- Automatisér dependency scanning og gem resultater pr. release.
- Versionér release-notes og sikkerhedsrelevante ændringer konsekvent.
- Aftal, hvem der ejer kundekommunikation ved sikkerhedshændelser.
Det lyder banalt, men netop disse punkter er ofte forskellen på “vi håber, det går” og “vi har styr på det”. Og når de sidder, bliver de næste skridt (threat modeling, forbedret test, bedre rapportering) langt lettere at gennemføre.
Mini-konklusion: Start der, hvor du kan skabe gentagelighed: sårbarhedsflow, patching og dokumentation pr. release. Det er kernen i skiftet fra engangslevering til løbende ansvar.