Hvis din CE-mærkning i 2026 kan falde på en manglende SBOM, en uklar opdateringsforpligtelse eller en sårbarhed, der ikke blev rapporteret i tide, er cybersikkerhed ikke længere et “security issue” — det er et markedsadgangs- og produktansvarsproblem.
Artiklen her er skrevet til producenter og leverandører af hardware- og softwareprodukter med digitale elementer: IoT-enheder, industrielle styresystemer, gateways, sensorer, tilsluttede komponenter og den software, der følger med. Du får et praktisk overblik over, hvad CRA betyder i hverdagen i 2026, hvor markedsovervågning og håndhævelse er blevet mere aktiv, og hvor manglende efterlevelse i praksis kan blokere for CE-mærkning og EU-salg.
Vi går fra designfasens risikovurdering og secure-by-design til koordineret sårbarhedsafdækning (CVD), teknisk dokumentation, opdateringsforpligtelser og forsyningskædens “svage led” — med konkrete faldgruber og handlepunkter, du kan bruge direkte i compliance-arbejdet som produktansvarlig, CISO eller juridisk rådgiver.
Hvad er Cyber Resilience Act — og hvorfor rammer den produktteams så hårdt?
Cyber Resilience Act (CRA) er EU-regulering, der stiller bindende cybersikkerhedskrav til produkter med digitale elementer gennem hele deres livscyklus: fra design og udvikling til drift, sårbarhedshåndtering og sikkerhedsopdateringer. Det afgørende skifte er, at cybersikkerhed ikke kun vurderes som “best effort” eller kontraktvilkår — det bliver et compliance-krav knyttet til, om produktet overhovedet må bringes på EU-markedet.
For producenter betyder det, at sikkerhed skal kunne dokumenteres på samme måde som elektrisk sikkerhed eller EMC: med strukturerede processer, sporbarhed og teknisk dokumentation, der kan modstå tilsyn. For leverandører og integratorer betyder det, at “vi bruger bare en tredjepartskomponent” ikke længere er et frikort, hvis komponenten trækker en kendt sårbarhed eller mangler opdateringsmekanisme ind i jeres produkt.
I 2026 ser mange virksomheder især tre praktiske konsekvenser: 1) compliance-arbejdet flytter tidligere ind i designfasen, 2) sårbarhedshåndtering bliver en løbende driftsdisciplin med rapporteringspligter, og 3) teknisk dokumentation bliver et produktkrav, ikke et “audit-bilag”.
Fra “security features” til secure-by-design som arkitekturkrav
Secure-by-design under CRA handler ikke om at tilføje et par sikkerhedsfunktioner til sidst. Det handler om, at arkitekturen fra start reducerer angrebsfladen, gør fejl mindre sandsynlige og gør konsekvenserne mindre, når noget går galt. I praksis er det ofte her, compliance lykkes eller fejler: Hvis designet ikke understøtter patching, logging eller adgangskontrol, kan du ikke dokumentere dig ud af problemet senere.
Risikomodellering, der faktisk kan spores til krav og test
En risikovurdering, der kun ender som en PDF, skaber sjældent værdi i markedsovervågning. Den skal kunne kobles til konkrete sikkerhedskrav, designbeslutninger og verifikation. Et robust mønster i 2026 er at holde en “traceability-kæde” fra trussel til kontrol til test: Trussel (fx fjernudnyttelse via management-port) → krav (authn/authz, rate limiting, hardening) → design (ingen default credentials, mTLS, firewall rules) → test (pen test-scenarier, fuzzing, negative tests) → release-gate.
For industrielle styresystemer ser jeg ofte, at risikovurderingen undervurderer “operational reality”: segmentering er ikke garanteret, OT-net er fladt, og remote service bliver åbnet under tidspres. Det bør afspejles i kravene, fx at serviceadgang kræver tidsbegrænsede credentials, stærk autentificering og audit logs, der kan eksporteres.
Minimal angrebsflade og sikre standardindstillinger
Markedsovervågning kigger i praksis efter klassiske designfejl: åbne debug-porte, hårdkodede credentials, unødvendige services, usikre standardindstillinger og opdateringsmekanismer uden integritetskontrol. En enkel tommelfingerregel er: Hvis en funktion ikke er nødvendig for produktets primære formål, skal den være fjernet eller deaktiveret som default.
Et konkret eksempel: En IoT-gateway med web-UI til lokal konfiguration kan være legitim, men hvis UI’et også eksponeres på WAN, eller hvis det er muligt at aktivere uden stærk autentificering, bliver det hurtigt en compliance-risiko. I 2026 bliver “secure defaults” ofte testet gennem standardopsætning direkte fra fabriksindstillinger — ikke gennem jeres interne “best practice deployment guide”.
Sårbarhedshåndtering og CVD: det er en proces, ikke en e-mailadresse
CRA presser virksomheder til at operationalisere sårbarhedshåndtering: modtagelse, triage, reproduktion, afhjælpning, kommunikation og opfølgning. Mange har tidligere haft en “security@”-mail og en sporadisk patch-cyklus; i 2026 er det ikke nok, hvis man skal kunne dokumentere rettidighed, prioritering og ansvar.
Koordineret sårbarhedsafdækning (CVD) i praksis
CVD betyder, at I gør det muligt for eksterne (kunder, forskere, CERT’er) at rapportere sårbarheder sikkert, og at I håndterer rapporten struktureret. Det bør som minimum omfatte en offentlig politik, forventningsafstemning om responstider, en måde at udveksle tekniske detaljer sikkert og en proces for advisories.
En typisk faldgrube er at love mere, end man kan levere: “Vi svarer inden for 24 timer” uden en bemandet vagtordning skaber både compliance- og omdømmerisiko. En bedre praksis er realistiske SLA’er, tydelig eskalation og en intern “stop-the-line” mekanisme, når en sårbarhed er aktivt udnyttet.
Rapportering af aktivt udnyttede sårbarheder: få styr på triggers og evidens
I 2026 er der skærpet fokus på, om virksomheder kan identificere, hvornår en sårbarhed er aktivt udnyttet, og om de kan handle hurtigt. Det kræver både tekniske signaler (telemetri, support-cases, threat intel) og en beslutningsproces: Hvem vurderer udnyttelse? Hvilken evidens er “god nok”? Hvornår går man fra “suspected” til “confirmed”?
Her fejler mange på grænsefladen mellem produkt og drift: Produktteamet ejer koden, men drift/support ser hændelserne først. Et praktisk værktøj er en fælles “exploitation rubric” (fx 0–3), der kombinerer indikatorer som PoC i omløb, kunderapporter, log-signaturer og bekræftet kompromittering.
Teknisk dokumentation under CRA: tænk “tilsynsklar” fra dag 1
Teknisk dokumentation er ikke et bilag, man skriver, når produktet er færdigt. Under CRA skal dokumentationen kunne vise, at sikkerhedskrav er identificeret, implementeret og verificeret, og at I kan vedligeholde sikkerheden over tid. I 2026 ser vi, at markedsovervågning ofte efterspørger sporbarhed: ikke kun “har I en proces?”, men “kan I vise, at processen blev fulgt for denne release?”
Midt i arbejdet giver det mening at have en fast “CRA-dokumentpakke” pr. produktlinje og pr. større release. Mange teams organiserer den som et levende repo med versionsstyring, så man kan dokumentere historik og ændringer.
Hvis du har brug for et mere samlet overblik over, hvordan kravene typisk nedbrydes til konkrete leverancer, kan du tage udgangspunkt i Cyber Resilience Act krav og omsætte dem til jeres egne kontrolpunkter og release-gates.
Hvad der typisk skal være med (og hvad der ofte mangler)
Som praktiker ser jeg, at følgende elementer ofte bliver afgørende, når dokumentationen skal kunne bære i en kontrolsituation:
- System- og sikkerhedsarkitektur: dataflows, trust boundaries, nøglekomponenter, interfaces og angrebsflader.
- Risikostyring: trusselsmodellering, risikovurdering, beslutninger om risikobehandling og residual risiko.
- Secure development evidence: coding guidelines, code review-krav, SAST/DAST-konfiguration, dependency scanning og håndtering af findings.
- SBOM og komponentstyring: komponentliste, versioner, licenser og mapping til kendte sårbarheder.
- Test og verifikation: sikkerhedstestcases, fuzzing-resultater, pen test-opsummeringer og retest efter fixes.
- Patch- og update-mekanisme: signering, rollback-beskyttelse, nøglehåndtering og opdateringskanaler.
Den hyppigste mangel i 2026 er ikke, at der ingen dokumenter er, men at de ikke hænger sammen: SBOM findes, men er ikke knyttet til release; risikovurdering findes, men ændringer i arkitekturen er ikke reflekteret; testresultater findes, men man kan ikke vise, hvilke krav de dækker.
Opdateringsforpligtelser: “hvor længe” er ikke kun et kommercielt spørgsmål
CRA tvinger producenter til at tage stilling til sikkerhedsopdateringer som en del af produktets livscyklus. I 2026 er “vi udgiver patches, når vi kan” blevet erstattet af forventningen om planlagte processer, tydelig kommunikation og realistiske garantier for, hvor længe produktet holdes sikkert.
Det praktiske spørgsmål, mange stiller, er: Hvad koster det? Svaret afhænger af arkitektur og modenhed, men omkostningen ligger ofte mindre i selve patchen og mere i maskineriet omkring: CI/CD-hardening, signering, testautomatisering, release governance, support og kommunikation. For produkter med lang levetid i industri (10–15 år) bliver det især dyrt, hvis man ikke har designet til opdaterbarhed fra start.
Design til patching: det du ikke kan opdatere, kan du sjældent forsvare
For tilsluttede komponenter og embedded-enheder er opdateringsmekanismen ofte den største compliance-risiko: Hvis firmwareopdatering kræver fysisk adgang, proprietære værktøjer eller “service laptop” uden sporbarhed, bliver det svært at argumentere for, at sikkerhedsopdateringer kan leveres effektivt.
Bedste praksis i 2026 er at kunne levere sikre opdateringer med signering, integritetskontrol og klare rollback-strategier. For ICS-miljøer er “maintenance windows” sjældne, så det er værdifuldt at kunne levere mindre, målrettede patches og have en klar mitigationsplan, hvis patch ikke kan udrulles straks.
Forsyningskæden: tredjepartskomponenter er jeres problem, når I sætter jeres navn på produktet
Det mest konfliktfyldte område i 2026 er ansvarsfordeling i forsyningskæder: open source biblioteker, kommercielle SDK’er, kommunikationsmoduler, cloud-tjenester og integrerede underleverandørkomponenter. Når en sårbarhed dukker op i en afhængighed, er det jer, der skal kunne vurdere eksponering, levere afhjælpning og dokumentere beslutninger.
En klassisk faldgrube er at behandle SBOM som en “compliance-export” i stedet for et styringsværktøj. Hvis SBOM ikke bruges aktivt til at matche CVE’er, prioritere opdateringer og drive dialog med leverandører, mister den sin værdi, netop når tilsynet spørger: “Hvordan vidste I, at I ikke var ramt?”
Kontrakter, krav og bevis: sådan gør du leverandørstyring audit-klar
Det, der virker i praksis, er at kombinere tekniske kontroller med kontraktuelle forpligtelser. Ikke som “papir-sikkerhed”, men som en måde at sikre adgang til information og rettigheder til at reagere.
- Kræv komponentoplysninger (SBOM, versioner, EOL/EOS) og opdateringsløfter fra leverandører.
- Definér sårbarheds-SLA’er: triage-tid, fix-tid og kommunikationskrav ved aktiv udnyttelse.
- Sørg for rettigheder til at distribuere patches (eller selv patch’e) ved kritiske sårbarheder.
- Indfør krav om secure-by-default konfiguration og dokumentation af hardening.
- Lav en eskalationsvej, hvis leverandøren ikke leverer, inkl. mulighed for komponentudskiftning.
Et konkret eksempel fra connected komponenter: Hvis I bygger et produkt på et tredjeparts Linux-baseret modul, men ikke har en klar aftale om kernel- og OpenSSL-opdateringer, ender I ofte med at “eje” patchingen uden at have build-kæden. Det er både en sikkerheds- og compliance-gælde, fordi I så ikke kan garantere rettidig afhjælpning eller reproducérbare builds.
Markedsovervågning og håndhævelse i 2026: hvad bliver der faktisk kigget efter?
Virksomheder spørger ofte: “Hvad er sandsynligheden for, at vi bliver kontrolleret?” I 2026 er det mere relevant at spørge: “Kan vi demonstrere compliance hurtigt og sammenhængende, hvis vi bliver udtaget?” Håndhævelse udløses ikke kun af tilfældige stikprøver, men også af hændelser, kundeklager, sårbarhedsafsløringer og sektor-fokus (fx kritisk infrastruktur og industri).
I praksis bliver der ofte kigget efter tegn på modenhed og sporbarhed: Har I en vedligeholdt sårbarhedsproces? Kan I fremvise teknisk dokumentation for den aktuelle release? Kan I dokumentere opdateringskapacitet? Har I styr på tredjepartsafhængigheder? Og kan I bevise, at sikkerhed ikke er en engangsindsats, men en løbende forpligtelse?
De typiske fejl, der koster tid, penge og markedsadgang
De mest almindelige fejl i CRA-arbejdet i 2026 er sjældent “vi gjorde ingenting”. Det er oftere, at man gjorde noget, men på en måde der ikke kan skaleres, ikke kan bevises, eller som kommer for sent i udviklingsforløbet.
- Compliance starter efter MVP: sikkerhed og dokumentation forsøges “boltet på” efter arkitekturen er låst.
- Uklare roller: ingen ejer CVD, ingen ejer SBOM-kvalitet, og “security” kan ikke stoppe en release.
- SBOM uden drift: komponentliste findes, men bruges ikke til løbende sårbarhedsvurdering.
- Patch uden distributionsplan: I kan bygge en fix, men ikke få den sikkert ud til kunderne.
- For svag leverandørstyring: manglende rettigheder og SLA’er gør jer afhængige af tredjeparts tempo.
- Dokumentation uden sporbarhed: dokumenter findes, men kan ikke kobles til den konkrete release og test.
Den mest effektive måde at undgå dem på er at etablere få, hårde “gates” i produktprocessen: ingen release uden opdateret SBOM, ingen release uden lukning/accept af kritiske findings, ingen release uden opdateret teknisk dokumentation og en verificeret update-path.
En handlingsorienteret CRA-tjekliste til produktteams i 2026
Hvis du skal omsætte CRA til noget, der kan stå i en Jira-ep
