Jag håller med. December 2027 känns otroligt långt bort. Men när det gäller Cyber Resilience Act (CRA) är det klokt att inte låta sig luras av kalendern. För dig som utvecklar, tillverkar eller säljer produkter med digitala komponenter innebär det här ”inte bara” ytterligare ett compliance-initiativ från EU – utan ett tydligt skifte i hur cybersäkerhet behöver hanteras i praktiken.
Det som gör CRA särskilt intressant är att förordningen flyttar cybersäkerhet från att vara en intern IT-fråga till att bli en central del av produktansvaret. Många organisationer är vana vid att tänka cybersäkerhet i termer av nätverk, identitetshantering, endpointskydd och incidentrespons. Cyber Resilience Act fokuserar istället på själva produkten. Det betyder att säkerhet inte längre bara handlar om hur organisationen skyddar sig, utan om hur produkten står emot digitala hot när den används av kunden.
CRA förändrar spelplanen för produktansvar
Det här var också ett tydligt budskap under vårt webinar om CRA:s praktiska tillämpning, där Lynda Woollard beskrev förändringen med en formulering som egentligen säger allt:
“If your product is not secure, it is not safe.”
Det är en enkel mening, men konsekvenserna är stora. Om cybersäkerhet blir en del av definitionen av produktsäkerhet förändras också förväntningarna på företag. Det räcker inte längre att bygga en funktionell produkt och sedan hantera säkerhetsproblem när de uppstår. Säkerhet måste finnas med från början, genom hela utvecklingsprocessen och vidare genom produktens livscykel.
Det här är också en av de vanligaste missuppfattningarna kring Cyber Resilience Act. Många ser det som ett regelverk som kommer att kräva mer dokumentation, några tekniska kontroller och kanske vissa förändringar i rapportering. I verkligheten handlar det om något betydligt större. För många företag innebär CRA compliance ett behov av att förändra arbetssätt, ansvarsfördelning och produktstyrning i grunden.
Till skillnad från NIS2 direktivet, eller cybersäkerhetslagen som vi kallar det i Sverige (som många nu arbetar intensivt med) riktar sig CRA inte primärt mot organisationens operativa cybersäkerhet. Fokus ligger istället på de produkter som sätts på marknaden. För svenska företag som utvecklar uppkopplade produkter, mjukvara eller digitala komponenter innebär det att Cyber Resilience Act kommer att påverka betydligt fler verksamheter än vad många först tror.
Det som gör att bilder blir mer komplex är att CRA inte bygger på ett traditionellt checkbox-tänk. Det handlar inte om att alla företag ska implementera exakt samma kontroller eller följa en universell checklista. Som Lynda Woollard betonade under webinariet:
“This is a risk-based approach.”
Det innebär att företag behöver förstå sin egen riskbild och bygga skydd utifrån den. Det är i grunden ett sunt och modernt synsätt. Men det kräver också en mognad som inte alla organisationer har idag. För att kunna arbeta riskbaserat enligt Cyber Resilience Act requirements krävs inte bara teknisk förståelse, utan också processer, ansvar, beslutsvägar och dokumentation som faktiskt håller ihop.
För CRA handlar inte bara om att säkra den egna koden. De flesta moderna produkter är beroende av open source-komponenter, externa bibliotek, tredjepartsmoduler och olika former av integrationslager. Den digitala leveranskedjan är idag en självklar del av produktutvecklingen, men också en växande riskyta. Cyber Resilience Act gör det tydligt att det ansvaret inte kan ignoreras.
Därför är 2027 närmare än många tror
Om en produkt bygger på komponenter från andra aktörer behöver företaget förstå vad det faktiskt innebär. Vilka beroenden finns? Hur upptäcks sårbarheter i dem? Hur snabbt kan uppdateringar hanteras? Finns kontroll över vad som faktiskt används? För många organisationer är det här ett betydligt större arbete än själva produktutvecklingen, just eftersom beroenden ofta vuxit fram organiskt över tid.
Det är också därför tiden är så avgörande.
Ett av de mest träffande citaten från webinariet handlade just om den här risken:
“If you start to look at this secure-by-design approach with 12 months to go, then chances are you’re not going to meet the timeframe.”
Det är lätt att tänka att 2027 fortfarande känns avlägset. Men secure by design, som är en central del av Cyber Resilience Act compliance, är inte något som implementeras i slutet av ett projekt. Om säkerhet ska byggas in i produktarkitektur, utvecklingsprocesser och leverantörsstyrning behöver förändringsarbetet börja långt tidigare. För företag med komplexa produktportföljer eller äldre system kan det här vara ett arbete som sträcker sig över flera år.
Sårbarhetshantering är ett annat område där CRA kommer att kräva en högre mognadsnivå än många företag är vana vid. Att kunna identifiera, prioritera och åtgärda säkerhetsbrister är inte längre en rekommendation eller best practice – det är ett regulatoriskt krav. Det innebär att företag behöver tänka i livscykel snarare än releasecykel. En produkt är inte “klar” ur säkerhetsperspektiv när den lanseras. Den behöver kunna hållas säker över tid.
Det väcker ganska praktiska frågor. Hur länge ska produkten supporteras? Vem ansvarar för säkerhetsuppdateringar? Hur kommuniceras patchar till kunder? Hur identifieras nya sårbarheter när produkten väl är ute på marknaden?
För många organisationer innebär det här ett skifte från projektlogik till långsiktigt produktansvar enligt Cyber Resilience Act.
CRA är inte bara en säkerhetsfråga – det är en ledningsfråga
Samma sak gäller incidentrapportering. När aktivt exploaterade sårbarheter eller säkerhetsincidenter upptäcks behöver företag kunna agera snabbt. Det ställer krav inte bara på tekniska säkerhetsfunktioner, utan på intern samordning och tydliga processer. Om en incident upptäcks mitt under sommaren, på en fredag eftermiddag eller i samband med en release behöver organisationen fortfarande kunna reagera inom regulatoriskt acceptabla tidsramar.
Det är just i de här lägena som CRA slutar vara en teknisk fråga och blir en affärsfråga.
Lynda Woollard satte fingret på det ganska tydligt:
“Management buy-in is a critical requirement.”
Det är svårt att argumentera emot. Om Cyber Resilience Act innebär förändringar i utvecklingsprocesser, krav på dokumentation, stärkta leverantörsprocesser och nya säkerhetsrutiner, då räcker det inte att säkerhetsfunktionen tycker att frågan är viktig. Ledningen behöver förstå omfattningen, prioritera resurser och skapa förutsättningar för att arbetet faktiskt ska lyckas.
Det gäller särskilt eftersom CRA inte bara handlar om att göra rätt – utan om att kunna visa det.
Dokumentation blir därför en större fråga än många först tror. Tekniskt mogna organisationer har ofta relativt stark säkerhet i praktiken, men betydligt svagare formalisering. Man vet hur produkten fungerar, men det finns inte alltid tydliga riskbedömningar, processbeskrivningar eller dokumenterade beslutsunderlag som håller regulatoriskt.
Det är ett problem, eftersom Cyber Resilience Act kräver just den typen av spårbarhet.
Och det är här många företag sannolikt kommer att upptäcka att det verkliga arbetet inte handlar om teknik – utan om styrning.
Företagen som börjar nu kommer ha ett försprång
Det positiva i allt detta är att CRA inte bara bör ses som en regulatorisk belastning. För företag som börjar i tid finns en tydlig strategisk uppsida. Organisationer som bygger strukturer för produktnära cybersäkerhet stärker inte bara sin compliance-position. De bygger bättre produkter, ökar kundernas förtroende och skapar bättre intern kontroll över sin digitala leveranskedja.
I en marknad där cybersäkerhet i allt högre grad blir en konkurrensfördel är det svårt att se det som något negativt.
Den viktigaste frågan är därför kanske inte om Cyber Resilience Act kommer att påverka ditt företag.
Den viktigaste frågan är om ni börjar i tid.
