Cyber Resilience Act (CRA) 2026–2027: vad vi redan vet, vad som fortfarande saknas och hur man i praktiken förbereder en produkt – innan de harmoniserade standarderna finns på plats

Vad vi säkert vet i dag (och varför det inte är en “fråga för 2027”)

Cyber Resilience Act kan se ut som ännu ett dokument “från Bryssel” som går att lägga åt sidan till senare. Det är en naturlig reaktion, särskilt om företaget lever i projektcykler: prototyp, införande, serieproduktion, service. Regleringar kommer ofta in som ett “slutkrav” — något man knyter ihop på mållinjen. CRA ändrar den logiken, eftersom det inte bara handlar om det som syns i produkten på försäljningsdagen. Det handlar om huruvida tillverkaren kan upprätthålla produktens säkerhet över tid och visa att det gjorts medvetet, inte av en slump.

Det viktigaste faktumet är enkelt, men får strategiska konsekvenser: CRA är en produktreglering, förankrad i EU-marknadens mekanik (inklusive CE-märkning). Europeiska kommissionen beskriver uttryckligen att produkter ska bära CE-märkning som en signal om överensstämmelse med CRA, och att tillsynen ligger hos marknadskontrollmyndigheterna. Det är alltså inte en “IT-standard” som kan behandlas som ett internt förbättringsprogram. Det är en ram som påverkar möjligheten att sälja.

Datum som hjälper att strukturera tänket

I själva texten i förordning (EU) 2024/2847 syns en stegvis tillämpning. CRA tillämpas från och med 11 december 2027, men med tydliga undantag. Artikel 14 (rapportering) gäller från 11 september 2026, och kapitlet om anmälan av organ för bedömning av överensstämmelse (Chapter IV) från 11 juni 2026. Det är tre datum som är värda att se som “milstolpar”, eftersom de motsvarar tre olika typer av beredskap: operativ, institutionell och produktmässig.

Kommissionen kommunicerar det ännu enklare: CRA trädde i kraft den 10 december 2024, de grundläggande skyldigheterna från 11 december 2027 och rapporteringen från 11 september 2026. Om någon i företaget säger “vi har tid till 2027” syftar man oftast på konstruktionskrav och bedömning av överensstämmelse. Men rapporteringen kommer tidigare och gäller händelser som inte väntar på en tidplan.

Rapportering: en skyldighet som tvingar fram en process (inte ett dokument)

Rapporteringskravet är ett bra lackmustest, eftersom det visar hur CRA förstår “produktsäkerhet inom cybersäkerhet”. Det är ingen avsiktsförklaring och ingen “policy”. Det är en process som måste fungera i en stressad situation: när en sårbarhet som aktivt utnyttjas dyker upp, eller när en allvarlig incident inträffar.

Kommissionen beskriver detta entydigt: tillverkaren ska anmäla sårbarheter som aktivt utnyttjas samt severe incidents som påverkar produktens säkerhet. Det krävs en “early warning” inom 24 timmar från det att man fått kännedom, en fullständig anmälan inom 72 timmar och en slutrapport: inom 14 dagar efter att en åtgärd finns tillgänglig för sårbarheter som aktivt utnyttjas, samt inom en månad för severe incidents.

I praktiken innebär det att organisationen behöver mer än en checklista. Den behöver en mekanism som besvarar tre frågor: hur får vi veta att problemet finns; vem avgör om det redan är “aktivt utnyttjat” eller “severe”; och hur organiserar vi informationsflödet och en korrigering inom en tidsram som inte lämnar utrymme för improvisation.

Om det blir rörigt på utbildningar beror det ofta på att CRA träffar en lucka mellan IT och produkten. För IT kan en “incident” vara en händelse i infrastrukturen. För en tillverkare är en “incident” en händelse som berör produkten hos kunden, versionen, konfigurationen och sättet den är införd på. CRA tvingar ihop dessa världar till ett enda ansvar.

Vad CRA omfattar: produkten som en relation till nätverket, inte en “apparat på bordet”

I praktiken har vi i riskbedömningar av maskiner lärt oss att risk inte är en egenskap hos själva maskinen — den uppstår i relationen människa–maskin. I CRA sker en liknande perspektivförskjutning: säkerhet finns inte “i enheten”, utan i relationen mellan produkten och den digitala omgivningen, användningssättet och tillverkarens förmåga att reagera.

Kommissionen, när den sammanfattar CRA, lyfter fram definitionen av “produkter med digitala element” och att rapporteringsskyldigheterna gäller alla sådana produkter som tillhandahålls på EU-marknaden — även dem som släppts ut på marknaden före 11 december 2027. Det är ett avgörande förtydligande, eftersom det tar bort en vanlig myt: “för gamla produkter spelar det ingen roll”. Rapportering — gör det.

Vad som fortfarande saknas (harmoniserade standarder) och varför det inte bör lamslå

W diskussioner om CRA dyker ofta frasen upp: “det finns inga harmoniserade standarder ännu, så det går inte att agera”. Det låter logiskt, men här finns en dold fallgrop. Harmoniserade standarder är ett verktyg som gör det enklare att visa överensstämmelse (presumtion om överensstämmelse), men de är inte den enda vägen till verklig produktsäkerhet. Och de är inte ett villkor för att börja konstruera på rätt sätt.

Kommissionen driver uttryckligen standardiseringsfrågan via sidan “CRA Standardisation” och informerar att den har antagit standardisation request M/606, som omfattar en uppsättning 41 standarder som stödjer CRA — både horisontella och vertikala (produktspecifika). Det är viktigt, eftersom det visar att EU förstår marknadens problem: utan standarder kommer företag att bygga upp sin efterlevnad på olika sätt, och marknadskontrollen får svårare.

Horisontella och vertikala standarder: vad betyder det för tillverkaren

Förenklat:

• horisontella standarder ska beskriva “hur” man bygger och upprätthåller produktsäkerhet oavsett kategori (processer, metoder, riskbaserat angreppssätt),
• vertikala standarder ska precisera kraven för specifika produktklasser (där risker och arkitekturer är typiska).

Den här uppdelningen får praktiska konsekvenser. Om du tar fram en industriprodukt där delar av miljön är “OT” och livscykeln är lång, behöver du standarder som inte är skrivna för en SaaS-applikation. Och det är just därför vertikala standarder är viktiga: de hjälper till att gå från övergripande principer till vad som faktiskt ska kontrolleras i verkliga arkitekturer.

Tidsplan: standarderna kommer stegvis, inte “i ett paket före 2027”

Kommissionen visar i material om implementeringen av CRA att CRA införs stegvis, och att standarderna ska stödja processen över tid. På faktanivå, som är säker i dag: vi har en formellt antagen förordning och vi har en igångsatt standardiseringsmekanism (M/606).

Det viktigaste i praktiken är att förstå en mening: även när en standard tas fram av standardiseringsorganisationer uppstår “presumtion om överensstämmelse” i juridisk mening först när hänvisningen till standarden publiceras som harmoniserad standard i EU:s officiella tidning. Det är samma mekanik som i EU:s harmoniseringsmodell: standarder är bron mellan juridik och ingenjörspraktik, men bron måste formellt “erkännas” av EU.

Ur tillverkarens perspektiv innebär det att åren 2026–2027 blir en period där vissa företag kommer att arbeta utifrån egna metoder för att visa överensstämmelse (riskbaserat + bevis), medan andra redan kommer att mappa mot de standarder som börjar komma. Och det är normalt.

“Avsaknad av standarder” betyder inte “avsaknad av skyldighet” — det betyder större tyngd på bevis

Här uppstår en viktig konsekvens: om det saknas standarder som ger den enklaste vägen att visa överensstämmelse, ökar betydelsen av det som i revisions- och granskningspraktik alltid är avgörande: en sammanhängande beslutslogg.

Vilka risker har vi bedömt? Vilka scenarier har vi antagit som realistiska? Hur valde vi skyddsåtgärder? Hur hanterar vi sårbarheter? Hur länge stödjer vi produkten? Hur informerar vi kunden? CRA kräver inte att tillverkaren “gissar framtida EN-standarder”. Det kräver att tillverkaren kan visa att besluten inte var godtyckliga, utan riskbaserade och i linje med state of the art.

Hur man i praktiken förbereder en produkt för CRA (en roadmap för tillverkare och integratör)

Det största värdet med CRA är att det tvingar fram mognad: cybersäkerhet slutar vara ett tillägg till produkten och blir en del av dess egen kärna. Men mognad uppstår inte av deklarationer. Den uppstår genom en process som är tillräckligt precis för att fungera i praktiken och tillräckligt enkel för att ingenjörsarbetet inte ska börja runda den.

Vid riskbedömning av maskiner uppstår de bästa konstruktionsbesluten när vi slutar fråga “vilka faror har maskinen” och i stället börjar fråga “i vilka uppgifter och tillstånd exponeras människan”. I CRA är det analogt: vi slutar fråga “vilka sårbarheter har produkten” och börjar fråga “under vilka förhållanden blir produkten exponerad och vad kan tillverkaren då göra”. Den förskjutningen skapar ordning i arbetet.

Steg 1: Definiera produkten som ett system (inte som en enhet)

Börja med att definiera vad som i ditt fall är en “produkt med digitala element”. Inte bara hårdvara och firmware, utan också sådant som ofta förbises eftersom det inte ryms i kartongen: komponenter, bibliotek, uppdateringsmekanismer, tjänster som produkten behöver för att uppfylla sin funktion. I CRA är detta viktigt, eftersom tillverkarens ansvar avser det som släpps ut på marknaden som produkt — inte bara det som mekanikavdelningen har tagit fram.

Det är också första tillfället då integratörer behöver vara ärliga mot sig själva: om du integrerar komponenter och konfigurerar dem på ett sätt som skapar en “slutprodukt” i kundens ögon, då är du inte bara en som “implementerar”. Du är medskapare av risken och medskapare av ansvaret.

Steg 2: Gör CRA-riskbedömningen så att den blir ett beslutsstöd

Det handlar inte om en “matris” på slides. Det handlar om en riskbedömning som leder till konstruktionsbeslut och som går att upprepa.

I praktiken börjar ett bra angreppssätt till CRA med en enkel fråga: vilka är de verkliga missbruksscenarierna i kundens miljö, och inte bara i laboratoriet? Vem har serviceåtkomst? Hur ser nätverket ut? Hur ofta uppdaterar vi? Vilka blir konsekvenserna av ett driftstopp? I industrin är de här frågorna mer obekväma än i IT, eftersom svaren ofta är: “vi kan inte uppdatera varje vecka” eller “vi har ingen telemetri”. Och det är just därför de måste ställas. CRA är lag, men effekterna är konstruktionsmässiga.

Krok 3: Bygg “vulnerability handling” som en produktionsprocess, inte som en krisreaktion

Rapporteringskraven som Kommissionen beskriver (24h/72h/14 dagar/månad) är obarmhärtiga för en organisation som saknar process. Om du vill vara redo till den 11 september 2026 måste du behandla “vulnerability handling” som en del av produktens livscykel, inte som en “uppgift för security-teamet”.

Det innebär:

• en kanal för att ta emot rapporter (CVD policy + kontakt),
• triage med en tydlig ansvarig och kriterier,
• en mekanism för att bygga och leverera security updates,
• en kommunikationsmodell till kunder som inte bygger på improvisation,
• beredskap för rapportering (vem rapporterar, med vilka data, hur snabbt).

Allt detta låter som “organisatoriskt” arbete. I praktiken är det produktarbete, eftersom det handlar om versioner, kompatibilitet, uppdateringsarkitektur och supportstrategi.

Krok 4: Välj support period som ett affärsbeslut, inte som ett minimikrav

Om dina produkter lever i industrin i 10–15 år är support period strategisk. CRA tvingar fram att support inte får vara ett löfte utan täckning. Det betyder att support period bör bygga på en analys: hur länge produkten kommer att användas, hur komponenternas leveranskedja ser ut, hur länge du kommer att kunna leverera korrigeringar. I praktiken börjar support period “dra med sig” hela ekosystemet: avtal med leverantörer, tillgång till build environment, förvaltning av toolchains, och till och med beslut om huruvida produkten ska ha fjärrfunktioner eller vara isolerad.

Om du behandlar support period som en formalitet hamnar du senast 2027 i en konflikt: kunden förväntar sig support, men du har inte längre resurser eller beroenden för att kunna leverera den. CRA skapar inte det här problemet — CRA synliggör det bara.

Krok 5: Få ordning på leveranskedjan: dialogen med leverantörer är en del av efterlevnaden

I CRA finns ingen “magi” som gör att externa komponenter blir säkra. Om din enhet bygger på bibliotek, kommunikationsmoduler, operativsystem, SDK eller hårdvarukomponenter, så är din risk direkt beroende av kvaliteten i leverantörens arbetssätt.

Därför är det värt att redan nu ta upp sådant som inte låter som marknadsföring, utan som ingenjörsarbete:

• om leverantören kan informera om sårbarheter på ett förutsägbart sätt,
• vilken responstid de har,
• om de har en process för att publicera korrigeringar,
• om de kan underhålla komponenten under en period som är förenlig med din support period.

Det är här CRA verkligen träffar affären: en leverantör som inte kan hantera sårbarheter är inte “billigare”. Det är en regulatorisk risk.

Krok 6: Bygg dokumentationen som ett sammanhängande spår: lag → risk → beslut → bevis

I efterlevnadsrevisioner vinner alltid konsekvens. Om riskbedömningen visar att ett visst gränssnitt är kritiskt, men dokumentationen inte beskriver hur du säkrar det; om du deklarerar att uppdateringar är säkra, men inte kan visa hur du säkerställer paketens integritet; om du säger att du har en process för sårbarhetshantering, men inte kan visa hur du triage:ar inkomna rapporter — då är det inte “brist på papper”. Det är brist på bevis för att processen fungerar.

I CRA, när harmoniserade standarder saknas, är det här spåret särskilt viktigt. För det kommer att vara grunden för dialogen med marknadskontrollmyndigheten, enterprise-kunden och, i vissa produktkategorier, även med organet för bedömning av överensstämmelse. Och lika viktigt: det blir grunden för intern stabilitet. Teamet vet varför vi gör något, inte bara “att vi måste”.

Avslutning: CRA som ett nytt konstruktionskrav, inte ett “compliance-projekt”

Om jag skulle lämna kvar en tanke som binder ihop alla tre delarna: CRA är inte ett problem som ska lösas på slutet. Det är en ram som förändrar hur man tänker om produkten. Precis som ISO 12100 lär att risk uppstår i relationen människa–maskin, så lär CRA att cybersäkerhet uppstår i relationen produkt–miljö–tillverkarens livscykel.

Harmoniserade standarder kommer och förenklar vissa vägar. Men att de saknas är inget skäl att stå still. Det är ett skäl att fokusera på det som CRA alltid bedömer: beslut, bevis och förmågan att agera i verkligheten — inte i en presentation.