Hvis du først tænker sikkerhed, når produktet næsten er klar til markedet, kommer du typisk til at betale for det to gange: først i hastige rettelser, og senere i driftsproblemer, support og tabt tillid.
I denne artikel får du et praktisk overblik over, hvorfor CRA bør ind i designfasen—ikke som et compliance-bilag til sidst, men som en måde at reducere risiko, forudsige omkostninger og bygge mere robuste digitale produkter. Du får konkrete greb, eksempler på klassiske faldgruber og en trinvis tilgang, der kan bruges i både software-, IoT- og indlejrede projekter.
Hvad er CRA, og hvorfor betyder det noget allerede i designfasen?
CRA (Cyber Resilience Act) er EU-regulering, der stiller krav til cybersikkerhed for produkter med digitale elementer på tværs af deres livscyklus—fra design og udvikling til sårbarhedshåndtering og opdateringer. Det afgørende er ikke kun, at der “er sikkerhed”, men at den kan dokumenteres, vedligeholdes og håndteres systematisk.
Når CRA tænkes ind tidligt, bliver sikkerhed en del af produktarkitekturen og udviklingsprocessen fremfor et sent “hardening”-projekt. Det er forskellen på at bygge et hus med bærende vægge rigtigt fra starten og at prøve at forstærke fundamentet, når taget allerede er lagt.
Mini-konklusion: Hvis sikkerhed og compliance først kommer på til sidst, bliver de både dyrere og sværere at bevise.
Den dyre sandhed: Sikkerhed som efterarbejde rammer budget, tid og kvalitet
I praksis ser jeg ofte, at teams undervurderer, hvor “dybt” sikkerhedsændringer går. En sent opdaget sårbarhed er sjældent bare en lille kodeændring; den kan tvinge ændringer i arkitektur, dataflow, autentifikation, logning og deployments.
Hvorfor bliver det dyrere senere?
Jo senere i livscyklussen du opdager et problem, jo flere afhængigheder har du opbygget: integrationer, kunder, dokumentation, testcases og driftssetup. Det gør rettelser mere risikable og dyrere at validere.
Et konkret eksempel: Hvis en IoT-enhed er designet uden mulighed for sikre, signerede firmware-opdateringer, kan “fixet” ende med at være en hardware-revision, fordi du mangler plads til en sikker bootloader, eller fordi enheden ikke kan håndtere kryptografiske operationer effektivt. Det er ikke ualmindeligt, at en sådan ændring flytter både BOM-pris, certificering og time-to-market.
Skjulte omkostninger: support, incident-håndtering og drift
Efterarbejde rammer også driften. Mangler du logging, sporbarhed og tydelige sikkerhedsgrænser i designet, bliver fejl og angreb sværere at finde og afgrænse. Det betyder længere nedetid, højere supporttryk og flere “brandudsluknings-sprints”.
Mini-konklusion: Tidlig indsats giver forudsigelige omkostninger; sen indsats giver uforudsigelige kriser.
Hvad CRA i praksis “spørger efter”: Sikkerhedsegenskaber du skal kunne vise
CRA handler ikke kun om at undgå kendte fejl—men om at kunne vise, at du arbejder struktureret med cybersikkerhed gennem hele produktets levetid. Det påvirker både designbeslutninger og måden, du dokumenterer dem på.
Typisk skal du kunne demonstrere, at produktet er designet til at modstå relevante trusler, at sårbarheder håndteres, og at der er en plan for opdateringer og incident-respons.
- Trusselsmodellering og risikovurdering for centrale dataflows og angrebsflader
- Sikker standardkonfiguration (ingen “default admin/admin”, ingen åbne services uden behov)
- Adgangskontrol og identitet (mindste privilegium, stærk autentifikation hvor relevant)
- Sikker opdateringsmekanisme (signering, rollback/anti-rollback, integritetskontrol)
- Sårbarhedshåndtering (proces, prioritering, patch-vinduer og kommunikation)
- Logning og sporbarhed der gør det muligt at opdage og undersøge hændelser
Mini-konklusion: CRA bliver markant lettere, når kravene oversættes til konkrete design- og procesartefakter fra dag ét.
Designfasen: Her afgøres 80% af sikkerheden (og 90% af besværet)
Designfasen er der, hvor du vælger arkitektur, komponenter, protokoller og grænser. Det er også der, du kan bygge “sikkerhed med” i stedet for at “tilføje sikkerhed på”. Når først du har låst dig fast på en arkitektur, er mange sikkerhedsforbedringer enten dyre eller kompromisfyldte.
Trusselsmodellering som designværktøj, ikke compliance-ritual
Trusselsmodellering bliver ofte misforstået som et dokument, der skal udfyldes. Men det er i virkeligheden en design-workshop: Hvad kan angribes, hvad er konsekvensen, og hvor sætter vi kontroller ind?
Et enkelt, effektivt setup kan være en 60–90 minutters session pr. feature-område med: dataflow-diagram, primære aktiver (credentials, persondata, nøgler), samt top-5 trusler og afværgetiltag. Når det gøres tidligt, ender det typisk i bedre API-design, færre åbne porte og mere robuste autentifikationsmønstre.
“Sikkerhed” er ofte et arkitekturvalg
Overvej forskellen mellem at gemme tokens i klartekst i en lokal konfigfil versus at bruge en hardware-backed keystore. Begge kan “fungere”, men kun den sidste giver reelt modstand mod udtræk, når enheden kompromitteres. I indlejrede produkter kan en sikker boot-kæde være afgørende—det er svært at eftermontere, hvis den ikke var tænkt ind i valg af chipset og memory-layout.
Mini-konklusion: Designfasen er det billigste tidspunkt at fjerne angrebsflader og bygge robuste sikkerhedsgrænser.
Sådan integrerer du CRA i din udviklingsproces uden at bremse leverancer
CRA-arbejde bliver ofte opfattet som “mere proces”. I virkeligheden handler det om at gøre det, dygtige teams allerede gør, mere konsekvent og dokumenterbart. Jeg anbefaler at koble det direkte til dine eksisterende agile ceremonier og CI/CD.
- Definition of Done: Tilføj sikkerhedskriterier (fx ingen hardcodede secrets, inputvalidering, sikker fejl-håndtering).
- Security user stories: Formulér sikkerhed som konkrete krav (fx “som bruger skal jeg kunne rotere nøgler uden downtime”).
- Automatisér scanning: SAST/DAST, dependency scanning og container scanning i pipeline.
- SBOM som standard-output: Generér SBOM ved build og versionér den sammen med release.
- Release-gates: Stop builds ved kritiske CVE’er eller manglende signering af artifacts.
- Patch- og disclosure-flow: Etabler ansvar, SLA’er og kommunikationsskabeloner.
Midt i det hele er det værd at have et princip som rettesnor: secure by design handler om at gøre de sikre valg til standardvalg, så teamet ikke konstant skal “huske” sikkerhed i sidste øjeblik.
Mini-konklusion: Når sikkerhed bliver en del af “sådan bygger vi software”, falder den ekstra belastning markant.
Hvad koster det? En pragmatisk måde at tænke ROI på
Spørgsmålet “hvad koster CRA?” dukker altid op. Det ærlige svar er: det afhænger af udgangspunktet. Men du kan gøre det målbart ved at se på, hvilke investeringer der skaber varig effekt.
Typisk er de bedste “bang for the buck”-tiltag dem, der automatiserer kvalitet og forebygger fejl i stor skala: CI-scanning, dependency governance, signerede builds, opdateringsmekanismer og en klar sårbarhedsproces.
En enkel cost-model du kan bruge internt
Jeg har haft gavn af at estimere omkostninger i tre lag:
- Engangsomkostninger: arkitekturændringer, etablering af pipeline-gates, opdateringsinfrastruktur.
- Løbende omkostninger: triage af findings, patching, advisory-håndtering, rotation af nøgler/certifikater.
- Undgåede omkostninger: færre incidents, mindre support, færre haste-hotfixes, mindre churn.
En nyttig sammenligning: Hvis du bruger 2–5% ekstra udviklingstid per sprint på forebyggende sikkerhed og automatisering, kan du ofte reducere de uplanlagte “brand-sprints” betydeligt. Det er ikke et løfte, men et mønster: teams med stærk pipeline-automatisering bruger mindre tid på akutte nødrettelser og mere tid på planlagt værdiskabelse.
Mini-konklusion: CRA-indsats betaler sig bedst, når den reducerer gentagne drifts- og patchomkostninger, ikke når den kun producerer dokumenter.
Typiske fejl, der gør CRA til et dyrt mareridt (og hvordan du undgår dem)
De mest almindelige faldgruber handler sjældent om “manglende vilje”, men om timing og ejerskab. Her er de fejl, jeg ser igen og igen—og hvad der konkret virker som modtræk.
Fejl 1: Man starter med dokumentation i stedet for designbeslutninger
Hvis du skriver politikker og rapporter uden at ændre build-kæde, opdateringsmekanisme eller adgangskontrol, får du papircompliance og reelle sårbarheder. Start med de tekniske kontrolpunkter, og dokumentér derefter.
Fejl 2: “Vi patcher senere” uden en opdateringsstrategi
At love patches er ikke det samme som at kunne levere dem sikkert. Sørg for signerede opdateringer, versionering, rollback-strategi og klar ansvarsfordeling. Hvis produktet har kunder med begrænset connectivity, skal “offline/low-connectivity update” være en del af designet.
Fejl 3: Afhængigheder uden governance
Hvis du ikke har styr på tredjepartskomponenter, ender du med at reagere på CVE’er ad hoc. Etabler en politik for versionsstyring, godkendte biblioteker og en proces for “exception handling”. SBOM er kun nyttig, hvis den holdes ajour og bruges i triage.
Fejl 4: Sikkerhed bliver én persons ansvar
En “security champion” kan hjælpe, men hvis teamet ikke har fælles standarder og værktøjer, bliver det en flaskehals. Gør kravene synlige i backlog, DoD og pipeline, så de håndhæves automatisk og deles i teamet.
Mini-konklusion: De dyreste fejl handler om manglende opdateringsevne, ukontrollerede afhængigheder og sikkerhed uden ejerskab.
Best practices: En konkret tjekliste til designfasen
Hvis du vil i gang hurtigt, er her en tjekliste, der fungerer som “minimum viable security” i designfasen. Den kan tilpasses både SaaS, mobile apps og produkter med hardware.
- Definér aktiver og trust boundaries: Hvilke data er kritiske, og hvor krydser de grænser?
- Vælg autentifikation og autorisation tidligt: Hvordan håndteres roller, privilegier og service-identiteter?
- Plan for nøgle- og certifikathåndtering: Generering, rotation, opbevaring, udløb og kompromittering.
- Design opdateringer som en kernefeature: Signering, distribution, telemetri, fail-safe og anti-rollback.
- Logning med formål: Hvilke events skal kunne spores ved fejl/angreb, og hvor længe gemmes de?
- Minimér angrebsfladen: Slå unødige services fra, luk porte, og begræns debug-interfaces i produktion.
- Testbar sikkerhed: Hvilke sikkerhedskrav kan verificeres automatisk i CI?
Det vigtige er ikke at “tjekke alt af” på dag ét, men at sikre, at de største risici bliver håndteret som designvalg og ikke som nødrettelser.
Mini-konklusion: En kort, disciplineret design-tjekliste kan fjerne de mest kostbare sikkerhedsgældsposter, før de opstår.
Sådan kommer du i gang i morgen: En 30-dages plan med lav friktion
Hvis du står med et eksisterende produkt eller et projekt, der allerede er i gang, er det fristende at vente til “næste version”. Det er sjældent nødvendigt. Du kan lave målrettede forbedringer uden at stoppe udviklingen.
- Uge 1: Kortlæg produktets vigtigste dataflows og lav en simpel trusselsmodel for top-3 features.
- Uge 2: Få dependency scanning og SBOM-generering ind i CI, og aftal severity-tærskler.
- Uge 3: Definér en sårbarhedsproces (triage, patch-SLA, disclosure-kanal) og afprøv den på én “tør-øvelse”.
- Uge 4: Implementér eller forbedr signerede releases/opdateringer og tilføj logning for kritiske sikkerhedshændelser.
Efter 30 dage har du typisk både bedre overblik, bedre automatisering og et tydeligere compliance-fundament—uden at skulle “pause produktet”.
Den vigtigste pointe: CRA bliver langt mindre dramatisk, når du gør det til en del af design og leveranceflow, fremfor en stor afsluttende kontroløvelse.
