Cyber Resilience Act: varför den första tidsfristen redan infaller i september 2026

En missuppfattning visar sig vara seglivad: att Cyber Resilience Act berör tillverkare först från slutet av 2027. Det stämmer för en del av skyldigheterna — men inte för den första, och den är den mest obekväma. Den träder i kraft redan den 11 september 2026. När jag skriver detta är det mindre än ett kvartal bort.

Jag betraktar inte CRA som byråkrati för byråkratins skull. Den tvingar en bransch som i decennier behandlat säkerhet som ett valfritt extra till något som länge varit en självklarhet i säkerhetskritiska områden: att bevisa vad man gör. Ändå underskattar många hur tidigt klockan startar. Därav den här artikeln.

Vad CRA kräver — och från när

Cyber Resilience Act (förordning (EU) 2024/2847) har gällt sedan december 2024. Den fastställer hur säkra "produkter med digitala element" måste vara mot angrepp — alltså allt som innehåller programvara eller ansluter till ett nätverk. Från den smarta termostaten till industristyrningen. Det finns två viktiga datum, och de bör inte förväxlas:

11 september 2026 — rapporteringsplikten. Från detta datum måste jag rapportera varje aktivt utnyttjad sårbarhet och varje allvarlig säkerhetsincident inom 24 timmar till behöriga organ — EU-byrån ENISA och de nationella responsgrupperna (CSIRT). Det gäller även produkter som länge funnits på marknaden och fortfarande har support.

11 december 2027 — resten. Från då måste produkten vara säkert konstruerad från grunden, få säkerhetsuppdateringar under hela sin livslängd, kunna visa en fullständig programvaruförteckning, genomgå en bedömning av överensstämmelse och bära CE-märket.

Lägger man de två datumen sida vid sida framträder det egentliga problemet: man kan bara rapportera det man vet sitter i sin produkt. Och det leder rakt till det underskattade hindret.

Varför rapporteringsplikten är det verkliga hindret

Att rapportera en sårbarhet inom 24 timmar låter som en organisatorisk detalj. Det är det inte. För att över huvud taget kunna bedöma om en nyss offentliggjord brist berör min egen produkt behöver jag en fullständig lista över alla inbyggda programvarukomponenter — den så kallade SBOM:en (software bill of materials), stycklistan för programkoden. Utan den sitter jag i mörker vid varje ny sårbarhetsrapport och gissar om någon av mina komponenter är berörd.

Med andra ord: den SBOM som officiellt blir obligatorisk först 2027 behöver jag i praktiken redan i september 2026. Den som börjar kartlägga sina beroenden först då har redan förlorat den första skarpa händelsen. Till detta kommer den rena logistiken: vem upptäcker en utnyttjad brist, vem bedömer den, vem rapporterar den — och fungerar den kedjan även en lördagskväll? Tjugofyra timmar är tjugofyra timmar.

Driftsäkerhet och angreppsmotstånd växer samman

Här blir det intressant för mitt kärnarbete. I mer än tre decennier har jag utvecklat säkerhetskritisk inbyggd programvara, en stor del enligt ISO 26262 — standarden för funktionssäkerhet i fordon. Funktionssäkerhet frågar: vad händer om en komponent slutar fungera? CRA ställer en andra fråga bredvid: vad händer om någon angriper enheten med flit?

Dessa två frågor var länge skilda världar. Det är de inte längre. Ett åskådligt exempel är fjärrintrånget i en Jeep Cherokee 2015: två säkerhetsforskare tog kontroll över bromsar och växellåda via en brist i infotainmentsystemet — på distans, över mobilnätet. 1,4 miljoner fordon måste återkallas. Varje säkerhetsbevis för bromsen blev därmed värdelöst, för bromsen fallerade inte slumpmässigt utan på en angripares kommando. En brist i programvaran hade blivit ett säkerhetsproblem i ordets bokstavliga mening.

Det är precis här de dyra luckorna uppstår idag: hos tillverkare som har sin driftsäkerhet under kontroll men aldrig sett systematiskt på angreppssidan. Den som tänker ISO 26262 utan en åtföljande säkerhetsanalys sluter inte längre sin argumentationskedja.

Vad som konkret förändras i den fasta programvaran

CRA avfärdas gärna som ett juristämne. Det håller jag för ett misstag. Bakom kraven ligger mycket konkreta uppgifter för den fasta programvaran — styrprogramvaran som sitter fast i enheten. Fyra punkter är enligt mig centrala:

Programvaran måste ligga krypterad i enheten. Den som kan läsa ut programkoden okrypterad ur flashminnet har lämnat en dörr öppen. Moderna mikrokontroller erbjuder skydd för detta — säker utläsningsspärr, signerad start, nyckelbundna minnesområden. Det avgörande är att förvalta dem rent även i produktionen, i stället för att tappa bort nycklarna på vägen.

Uppdateringar måste vara manipuleringssäkra. En enhet måste kunna ta emot säkerhetsuppdateringar under hela sin livslängd — och så att ingen kan smuggla in främmande programvara. En produkt utan en signerad, verifierad uppdateringsväg är från 2027 helt enkelt inte längre säljbar.

Varje komponent måste vara känd och bevakad. Varje inköpt bibliotek, varje byggsten i realtidsoperativsystemet, varje kryptostack hör hemma i stycklistan och måste bevakas för kända sårbarheter. Dit hör att känna igen föråldrade komponenter som den ursprungliga leverantören inte längre underhåller — innan en myndighet gör det.

Ren kod lönar sig. I säkerhetskritiska projekt utvecklar jag efter strikta kodningsregler, som MISRA-C. Många av dessa regler eliminerar just de odefinierade beteenden som exploits senare byggs av. Den som arbetar så från början har redan gjort en del av CRA-läxan — men bör också kunna bevisa det.

Även den lilla tillverkaren är "tillverkare"

En utbredd feltanke lyder: det berör bara stora koncerner. Fel. CRA gäller för var och en som släpper ut en produkt med digitala element på EU-marknaden — från det medelstora företaget till den specialiserade ensamutvecklaren. Även den som importerar eller säljer vidare enheter bär sina egna skyldigheter. Och böterna är ingen skrämselbild: de når upp till 15 miljoner euro eller 2,5 procent av den globala årsomsättningen.

Den som hittills trodde att säkerhet var ett alternativ för "senare produktversioner" har inte längre det valet.

Vad jag råder tillverkare till nu

De kommande månaderna avgör om september 2026 möter ett ordnat förlopp eller en hektisk improvisation. Mitt råd är ospektakulärt, men det fungerar: börja. En inventering av vilka produkter som berörs och fortfarande stöds. En första programvaruförteckning per produkt. En definierad rapporteringsväg som organisatoriskt verkligen bär 24-timmarsfristen. Och parallellt härda den fasta programvaran — som en genomtänkt arkitektur, inte som en lapp påklistrad i efterhand.

En ärlig självplacering till sist: den som söker en stämpel på att allt redan stämmer är på fel ställe hos mig. Den som vill veta var produkterna verkligen står i september 2026, och vad som ska göras i den fasta programvaran till dess, är på rätt ställe.

Slutsats

CRA är inte ett avlägset problem för i övermorgon. Den första bindande tidsfristen infaller i september 2026, och den förutsätter att jag redan idag vet vad som finns i mina produkter. Den som börjar tidigt fördelar arbetet och undviker dyra sistaminutenlösningar strax före fristen.

Den största hävstången ligger sällan i tekniken ensam. Den ligger i det rena samspelet mellan styckliste, rapporteringsprocess och enhetshärdning — och i att äntligen tänka driftsäkerhet och angreppsmotstånd som ett gemensamt koncept, inte som två skilda lådor. Det är precis den bro jag helst arbetar på.