Hvis du stadig tænker sikkerhed som en “feature”, du kan tilføje lige før release, kommer CRA til at gøre ondt.
Den nye europæiske regulering flytter nemlig sikkerhed fra at være en anbefaling til at være et dokumenterbart krav gennem hele produktets livscyklus – også efter at produktet er solgt og installeret hos kunderne. I denne artikel får du et praktisk overblik over, hvordan CRA påvirker virksomheder med software og digitale produkter, hvilke krav der typisk rammer hårdest, og hvordan du kan gribe arbejdet an uden at drukne i compliance.
Du får konkrete takeaways, typiske faldgruber, og en hands-on tilgang til at bygge en proces, der både reducerer risiko og gør audit/tilsyn langt nemmere.
Hvad er CRA – og hvorfor betyder det noget for software og digitale produkter?
CRA (Cyber Resilience Act) er EU-regler, der stiller krav til cybersikkerhed for produkter med digitale elementer: software, firmware og tilsluttede enheder – inklusive mange rene softwareprodukter. Kort sagt: Producenter skal designe, udvikle og vedligeholde produkter med et dokumenteret sikkerhedsniveau, håndtere sårbarheder, og reagere på hændelser på en kontrolleret måde.
Hvorfor det betyder noget: CRA ændrer spillereglerne fra “best effort” til “påviselig praksis”. Det påvirker alt fra roadmap og arkitektur til kontrakter, releaseproces og support. Hvis du leverer en app, et SaaS-produkt, en desktop-klient, et bibliotek eller et integreret system til virksomheder, kan du ende med at skulle bevise, at du styrer sårbarheder og leverer sikkerhedsopdateringer i en periode.
Mini-konklusion: CRA handler ikke kun om at undgå bøder – det handler om at kunne levere og drive digitale produkter på en måde, der tåler et realistisk trusselsbillede.
Hvem bliver ramt – og hvilke typer produkter falder typisk ind under CRA?
Et af de mest praktiske spørgsmål, jeg møder i teams, er: “Gælder det os, når vi ikke sælger hardware?” I mange tilfælde er svaret: måske, og det kræver en konkret vurdering af produktet, dets funktion og distribution.
Typiske softwarecases der ofte bliver relevante
- Software, der distribueres til kunder (on-prem, desktop, mobil-apps, edge-komponenter).
- SaaS med klientkomponenter, agenter eller connectors hos kunden.
- Komponenter der indgår i andre produkter (SDK’er, biblioteker, containere, images).
- Industri- og IoT-nære løsninger: gateways, styringssoftware, OT-integration.
- Produkter med fjernadministration, opdateringsmekanismer eller privilegeret adgang.
Roller og ansvar: producent, importør, distributør
CRA skubber ansvar “opstrøms”: Den, der bringer produktet på markedet under eget navn, får typisk producentforpligtelser – også selvom dele er udviklet af en underleverandør. Samtidig kan importører og distributører få pligter ift. at sikre, at produktet overhovedet må markedsføres, og at dokumentation er på plads.
Mini-konklusion: Selv hvis du “bare” leverer software, kan du blive mødt af krav til både produktets sikkerhed og din organisationens måde at håndtere sårbarheder på.
Fra engangstest til livscyklus: sikkerhed som kontinuerligt krav
Den største mentale omstilling er, at sikkerhed ikke slutter ved release. CRA skærper forventningen om, at du kan håndtere sårbarheder gennem hele produktets liv – fra design til udfasning. Det betyder, at “vi laver en pentest én gang om året” sjældent er nok som eneste kontrol.
Hvad “livscyklus” betyder i praksis
Livscyklus betyder bl.a. at du har styr på: planlægning (threat modeling), implementering (secure coding), build/release (supply chain), drift (monitorering og respons), og vedligehold (patching, advisories, end-of-life). Hvis du har et produkt med 2–4 releases om måneden, skal sikkerhedskravene kunne følge med uden at stoppe flowet.
Opdateringer og patching bliver en del af produktløftet
Når kunder køber et digitalt produkt, forventer de i stigende grad sikkerhedsopdateringer. CRA gør det til en disciplin, du skal kunne dokumentere: hvordan du prioriterer sårbarheder, hvor hurtigt du reagerer, og hvordan du får patches ud uden at bryde kompatibilitet.
Mini-konklusion: Hvis din organisation ikke har en stabil patch- og releaseproces, bliver CRA hurtigt en organisatorisk udfordring – ikke en teknisk detalje.
De krav der typisk ændrer din hverdag: dokumentation, sårbarheder og “secure by design”
CRA bliver ofte oversat til tre meget konkrete arbejdspakker: sikker udvikling, sårbarhedshåndtering og dokumentation. Det er her, mange softwarevirksomheder opdager “skjulte” huller: man gør en del rigtigt, men kan ikke bevise det – eller gør det kun sporadisk.
Et godt sted at orientere sig yderligere er Cyber Resilience Act, men det vigtige er at omsætte krav til driftbare rutiner.
Secure by design: mere end en slogan-øvelse
Secure by design handler om at forebygge klasser af fejl: stærk adgangskontrol, sikker standardkonfiguration, mindst mulige rettigheder, inputvalidering, kryptering hvor relevant, og forsvar mod misbrugsscenarier. I praksis kræver det ofte, at man træffer arkitekturvalg tidligt: Hvordan segmenterer vi? Hvilke secrets-håndteringsprincipper bruger vi? Hvordan undgår vi, at logning lækker følsomme data?
Sårbarhedshåndtering: din reaktionstid bliver en KPI
Det er ikke urealistisk, at kunder og partnere begynder at spørge: “Hvor hurtigt patcher I kritiske CVE’er?” Hvis du arbejder med open source og containere, vil du se nye findings ugentligt. Uden triage og en fast proces risikerer du enten patch-fatigue eller – værre – at ignorerer noget kritisk.
Mini-konklusion: CRA presser dig mod en modenhed, hvor sikkerhed bliver målbar: ikke “vi prøver”, men “vi gør X inden for Y dage og kan dokumentere det”.
Hvad koster CRA-arbejdet – og hvad er den typiske fejl i budgettet?
Spørgsmålet “hvad koster det?” kan ikke besvares med ét tal, men der er mønstre. Mange undervurderer især tidsforbruget på proces og dokumentation, fordi det ikke føles som “produktion”. I praksis ser jeg typisk, at den første rigtige compliance-iteration kræver en kombination af engangsindsats og løbende drift.
Hvis du skal have et pejlemærke, kan du tænke i tre omkostningskategorier:
- Etablering: politikker, roller, baseline-krav, værktøjer, threat modeling-skabeloner, release gates.
- Afhjælpning: lukning af kendte huller (auth, logging, dependencies), refactoring, hardening, testdækning.
- Drift: løbende scanning, sårbarhedstriage, patching, incident response-øvelser, leverandøropfølgning.
Den typiske budgetfejl er at købe et værktøj og tro, at man har “løst CRA”. Værktøjer hjælper, men uden ejerskab, prioritering og tydelige beslutningsregler bliver output bare støj i backloggen.
Mini-konklusion: De fleste får mest ROI ved at investere i procesdisciplin og klare standarder før de skalerer toolstacken.
Konkrete best practices: sådan gør du sikkerhed til en del af udviklingsflowet
Målet er ikke at gøre udvikling langsommere, men at gøre kvalitet og sikkerhed forudsigelig. Her er en praktisk tjekliste, der typisk kan implementeres trinvist uden at “stoppe verden”.
- Definér en sikkerhedsbaseline pr. produkt (fx auth, logging, kryptering, hardening, data retention).
- Indfør trusselsmodellering ved nye features med høj risiko (betaling, admin, integrationer).
- Automatisér SAST/DAST og dependency scanning i CI – men med triage-regler.
- Byg en SBOM-praksis (software bill of materials) og en klar proces for open source-opdateringer.
- Lav release gates for “stop ship” findings (fx kritiske CVE’er uden workaround).
- Træn teams i secure coding og review-mønstre (ikke kun en årlig e-learning).
En enkel triage-model der virker i hverdagen
Hold det simpelt: klassificér findings efter udnyttelighed og eksponering – ikke kun CVSS. En kritisk sårbarhed i en internet-eksponeret komponent er noget andet end en medium i en intern admin-funktion bag SSO. Aftal på forhånd, hvornår noget skal patches “nu”, “næste sprint”, eller “når vi alligevel rører området”.
Gør det nemt at gøre det rigtige
Den mest effektive sikkerhed er den, der er designet ind i udviklerens standardvej: templates, secure defaults, interne libraries, standardiserede auth-flows og en “golden path” for logging/monitorering. Det reducerer både fejl og diskussioner.
Mini-konklusion: CRA-compliance bliver realistisk, når sikkerhed bliver til gentagelige rutiner i CI/CD og i teamets Definition of Done.
Dokumentation og bevis: det du ikke kan vise, findes ikke (for tilsynet)
Mange softwareteams laver masser af gode ting, men mangler sporbarhed: hvem besluttede hvad, hvornår blev det gjort, og hvordan ved vi, at det stadig gælder? CRA lægger vægt på, at du kan fremvise dokumentation for processer og resultater.
Praktisk dokumentation, der typisk giver mest effekt:
- Sikkerhedskrav pr. produkt og en oversigt over afvigelser (med begrundelse og plan).
- Release-notes der inkluderer sikkerhedsrelevante ændringer og dependency-opdateringer.
- Sårbarhedspolitik (rapportering, triage, patching, kommunikation).
- SBOM eller tilsvarende komponentoversigt og vedligeholdelsesrutine.
- Incident response playbook og logning/monitoreringsprincipper.
Det handler ikke om at skrive en roman. Det handler om at kunne besvare “hvad gjorde I, og hvordan ved I det?” på 10 minutter – ikke 10 dage.
Mini-konklusion: God dokumentation er ikke papirarbejde for papirarbejdets skyld; det er din genvej til hurtigere audits og færre kundespørgsmål.
Typiske faldgruber – og hvordan du undgår dem
Her er de fejl, jeg oftest ser, når virksomheder forsøger at “gøre sig klar” til CRA og ender med at skabe mere friktion end fremdrift.
Faldgrube 1: “Vi scanner alt” uden prioritering
Hvis alt er rødt, er intet rødt. Start med et defineret scope, triage-regler, og en proces for false positives. Ellers mister teams tillid til værktøjerne og ignorerer signalerne.
Faldgrube 2: Sikkerhed som en central flaskehals
Et lille security-team kan ikke være gatekeeper for alle releases. Løsningen er “shift left” med enablement: guidelines, templates, og klare stopkriterier – samt at sikkerhedsansvar forankres i produktteams.
Faldgrube 3: Leverandør- og open source-risiko bliver glemt
De fleste produkter er et patchwork af dependencies. Uden en praksis for versionsstyring, SBOM og opdateringer bliver du reaktiv. Sørg for, at “hvem ejer dependency X?” kan besvares, og at opdateringer er en planlagt aktivitet, ikke en nødbremse.
Mini-konklusion: CRA straffer ikke ambitioner – den straffer ustruktureret sikkerhedsarbejde uden ejerskab og prioritering.
Handlingsplan: sådan kommer du i gang de næste 30–90 dage
Hvis du skal omsætte CRA til noget, der virker i praksis, så tænk i faser. Målet er at skabe en minimumsplatform for compliance og så forbedre løbende.
- Kortlæg produkter og ansvar: Hvad leverer I, hvordan distribueres det, hvem er “producent” internt?
- Lav et gap-check: Hvad har I allerede (CI, scanning, patching), og hvad mangler I (triage, dokumentation, SBOM)?
- Fastlæg policies: sårbarhedsrapportering, patch- SLA’er, release gates, end-of-life.
- Implementér 2–3 automatiseringer: dependency scanning + CI gate for kritiske issues + grundlæggende artefaktsporbarhed.
- Træn og standardisér: secure coding patterns, review-checkliste, “golden path” for auth/logging.
- Test processen: kør en tabletop-øvelse på en kritisk CVE eller en simuleret incident og se, hvor den knækker.
Det afgørende er at vælge få, men effektive greb: en triageproces, en patchrytme og dokumentation, der kan holdes ajour. Når det sidder, kan du skalere med mere avancerede kontroller.
Mini-konklusion: På 90 dage kan du gå fra ad hoc til kontrolleret sikkerhedsdrift – hvis du prioriterer proces, ejerskab og gentagelighed frem for “flest mulige værktøjer”.