Cyber Resilience Act: Hvorfor den første frist allerede falder i september 2026

En misforståelse viser sig at være sejlivet: at Cyber Resilience Act først vedrører producenter fra slutningen af 2027. Det gælder for en del af forpligtelserne — men ikke for den første, og den er den mest ubehagelige. Den træder i kraft allerede den 11. september 2026. Mens jeg skriver dette, er det mindre end et kvart år væk.

Jeg betragter ikke CRA som bureaukrati for bureaukratiets skyld. Den tvinger en branche, der i årtier har behandlet sikkerhed som et valgfrit ekstra, til noget, der længe har været en selvfølge i sikkerhedskritiske felter: at dokumentere, hvad man gør. Alligevel undervurderer mange, hvor tidligt uret begynder at tikke. Derfor denne artikel.

Hvad CRA kræver — og fra hvornår

Cyber Resilience Act (forordning (EU) 2024/2847) har været i kraft siden december 2024. Den fastlægger, hvor sikre "produkter med digitale elementer" skal være mod angreb — altså alt, der indeholder software eller forbinder sig til et netværk. Fra den smarte termostat til den industrielle styring. Der er to skæringsdatoer, og de bør ikke forveksles:

11. september 2026 — indberetningspligten. Fra denne dato skal jeg indberette enhver aktivt udnyttet sårbarhed og enhver alvorlig sikkerhedshændelse inden for 24 timer til de relevante myndigheder — EU-agenturet ENISA og de nationale beredskabshold (CSIRT'er). Det gælder også produkter, der længe har været på markedet og stadig er i support.

11. december 2027 — resten. Fra da skal produktet være sikkert konstrueret fra bunden, modtage sikkerhedsopdateringer i hele sin levetid, fremvise en komplet softwarestykliste, gennemgå en overensstemmelsesvurdering og bære CE-mærket.

Lægger man de to datoer ved siden af hinanden, viser det egentlige problem sig: man kan kun indberette det, man ved sidder i sit produkt. Og det fører direkte til den undervurderede forhindring.

Hvorfor indberetningspligten er den egentlige forhindring

At indberette en sårbarhed inden for 24 timer lyder som en organisatorisk bagatel. Det er det ikke. For overhovedet at kunne vurdere, om en netop offentliggjort fejl rammer mit eget produkt, har jeg brug for en komplet liste over alle indbyggede softwarekomponenter — den såkaldte SBOM (software bill of materials), styklisten for programkode. Uden den sidder jeg i mørke ved hver ny sårbarhedsmelding og gætter på, om en af mine komponenter er berørt.

Med andre ord: den SBOM, der officielt først bliver obligatorisk i 2027, har jeg reelt brug for allerede i september 2026. Den, der først da begynder at kortlægge sine afhængigheder, har allerede tabt den første alvorlige hændelse. Dertil kommer den rene logistik: hvem opdager en udnyttet fejl, hvem vurderer den, hvem indberetter den — og virker den kæde også en lørdag aften? 24 timer er 24 timer.

Driftssikkerhed og angrebssikkerhed vokser sammen

Her bliver det interessant for mit kernearbejde. I mere end tre årtier har jeg udviklet sikkerhedskritisk embedded-software, en stor del af den efter ISO 26262 — standarden for funktionssikkerhed i køretøjer. Funktionssikkerhed spørger: hvad sker der, hvis en komponent svigter? CRA stiller et andet spørgsmål ved siden af: hvad sker der, hvis nogen angriber enheden med vilje?

Disse to spørgsmål var længe adskilte verdener. Det er de ikke længere. Et anskueligt eksempel er den fjernstyrede indtrængen i en Jeep Cherokee i 2015: to sikkerhedsforskere overtog kontrollen over bremser og gearkasse gennem en fejl i infotainmentsystemet — på afstand, via mobilnettet. 1,4 millioner køretøjer måtte tilbagekaldes. Enhver sikkerhedsdokumentation for bremsen var dermed værdiløs, for bremsen svigtede ikke tilfældigt, men på en angribers kommando. En fejl i softwaren var blevet et sikkerhedsproblem i ordets bogstavelige forstand.

Det er præcis her, de dyre huller opstår i dag: hos producenter, der har styr på deres driftssikkerhed, men aldrig har set systematisk på angrebssiden. Den, der tænker ISO 26262 uden en flankerende sikkerhedsbetragtning, lukker ikke længere sin argumentationskæde.

Hvad der konkret ændrer sig i firmwaren

CRA afvises gerne som et juristtema. Det holder jeg for en fejl. Bag kravene ligger meget konkrete opgaver for firmwaren — styringssoftwaren, der sidder fast i enheden. Fire punkter er efter min mening centrale:

Softwaren skal ligge krypteret i enheden. Den, der kan læse programkoden ukrypteret ud af flashen, har en åben dør. Moderne mikrocontrollere tilbyder beskyttelse til dette — sikker udlæsningsspærring, signeret opstart, nøglebundne hukommelsesområder. Det afgørende er også at forvalte dem rent i produktionen i stedet for at miste nøglerne undervejs.

Opdateringer skal være forfalskningssikre. En enhed skal kunne modtage sikkerhedsopdateringer i hele sin levetid — og sådan, at ingen kan indsmugle fremmed software. Et produkt uden en signeret, verificeret opdateringssti er fra 2027 ganske enkelt ikke længere salgbart.

Hver komponent skal være kendt og overvåget. Hvert tilkøbt bibliotek, hver byggesten i realtidsstyresystemet, hver krypto-stak hører hjemme i styklisten og skal overvåges for kendte sårbarheder. Dertil hører at genkende forældede komponenter, der ikke længere vedligeholdes af den oprindelige leverandør — før en myndighed gør det.

Ren kode betaler sig. I sikkerhedskritiske projekter udvikler jeg efter strenge kodningsregler, f.eks. MISRA-C. Mange af disse regler eliminerer netop de udefinerede adfærdsmønstre, hvorfra exploits senere bygges. Den, der arbejder sådan fra starten, har allerede klaret en del af CRA-lektien — men bør også kunne dokumentere det.

Den lille producent er også "producent"

En udbredt fejlslutning lyder: det vedrører kun store koncerner. Forkert. CRA gælder for enhver, der bringer et produkt med digitale elementer på EU-markedet — fra den mellemstore virksomhed til den specialiserede enkeltudvikler. Også den, der importerer eller videresælger enheder, bærer sine egne pligter. Og bøderne er ingen skræmmehistorie: de når op til 15 millioner euro eller 2,5 procent af den globale årsomsætning.

Den, der hidtil troede, at sikkerhed var en mulighed for "senere produktversioner", har ikke længere det valg.

Hvad jeg råder producenter til nu

De kommende måneder afgør, om september 2026 møder et velordnet forløb eller hektisk improvisation. Mit råd er uspektakulært, men det virker: gå i gang. En kortlægning af, hvilke produkter der er berørt og stadig understøttes. En første softwarestykliste pr. produkt. En defineret indberetningsvej, der organisatorisk reelt bærer 24-timers fristen. Og parallelt hærdning af firmwaren — som en gennemtænkt arkitektur, ikke som en lap sat på bagefter.

En ærlig selvindplacering til sidst: den, der søger et stempel på, at alt allerede passer, er forkert hos mig. Den, der vil vide, hvor produkterne reelt står i september 2026, og hvad der skal gøres i firmwaren inden da, er rigtigt hos mig.

Konklusion

CRA er ikke et fjernt problem for i overmorgen. Den første bindende frist falder i september 2026, og den forudsætter, at jeg allerede i dag ved, hvad der sidder i mine produkter. Den, der starter tidligt, fordeler arbejdet og undgår dyre hasteløsninger lige før fristen.

Den største løftestang ligger sjældent i teknikken alene. Den ligger i det rene samspil mellem stykliste, indberetningsproces og enhedshærdning — og i endelig at tænke driftssikkerhed og angrebssikkerhed som ét fælles koncept, ikke som to adskilte skuffer. Det er præcis den bro, jeg helst arbejder på.