Cyberresiliensförordningen (Cyber Resilience Act): rapporteringen gäller sedan 11 september 2026

De flesta EU-förordningar ger dig ett datum för regelefterlevnad och en övergångsperiod då alla i lugn och ro hinner organisera sig. Cyberresiliensförordningen gör något annat. Dess första skarpa skyldighet är en rapporteringsklocka på 24 timmar, och den har gällt sedan 11 september 2026.

En klocka på 24 timmar går inte att fasa in. Antingen finns processen på plats när en sårbarhet som utnyttjas dyker upp, eller så missar du fristen.

Vad CRA är

Förordning (EU) 2024/2847 ställer cybersäkerhetskrav på produkter med digitala element som släpps ut på EU-marknaden. Begreppet omfattar mycket mer än man först tror: varje program- eller maskinvaruprodukt, med tillhörande lösningar för fjärrdatabehandling, vars avsedda eller rimligen förutsebara användning innefattar en direkt eller indirekt dataanslutning.

Uppkopplade enheter omfattas. Det gör även det mesta av kommersiell programvara, operativsystem, webbläsare, mobilappar, inbyggd programvara (firmware) och komponenterna inuti andra produkter.

Akten publicerades i november 2024 och börjar tillämpas stegvis:

• 11 juni 2026: skyldigheter för organ för bedömning av överensstämmelse.
• 11 september 2026: rapporteringsskyldigheter för aktivt utnyttjade sårbarheter och allvarliga incidenter.
• 11 december 2027: full tillämpning, inklusive väsentliga cybersäkerhetskrav, CE-märkning, teknisk dokumentation och programvaruförteckningen (SBOM).

Det mellersta datumet är det som redan gäller, och det bygger på en förmåga som du kanske inte har.

Vad som har gällt sedan 11 september 2026

Sedan det datumet måste tillverkare rapportera:

Aktivt utnyttjade sårbarheter i sina produkter med digitala element, och

Allvarliga incidenter som påverkar säkerheten i de produkterna.

Rapporteringen går via den gemensamma rapporteringsplattformen för CRA, som drivs av ENISA, till den CSIRT som utsetts i den medlemsstat där tillverkaren har sitt huvudsakliga verksamhetsställe, och som sedan delar vidare till andra berörda CSIRT-enheter och ENISA. ENISA tog en första version av plattformen i drift 11 september 2026, samma dag som skyldigheten började gälla, och säger att fler funktioner tillkommer under de kommande månaderna.

Tidslinjen:

• Inom 24 timmar från att du fått kännedom: en tidig varning.
• Inom 72 timmar: en fullständig anmälan, inklusive vidtagna korrigerande eller begränsande åtgärder.
• Inom 14 dagar från att en korrigerande åtgärd blivit tillgänglig: en slutrapport för en aktivt utnyttjad sårbarhet.
• Inom en månad: en slutrapport för en allvarlig incident.

Tjugofyra timmar från kännedom, inte från bekräftelse och inte från åtgärd. Om en sårbarhet i en komponent i din produkt utnyttjas ute i världen en lördag, så tickar klockan på lördagen.

Varför det är svårare än det ser ut

Själva rapporteringsskyldigheten är att fylla i ett formulär. Svårigheten ligger i allt du måste ha på plats innan du kan fylla i det.

Du måste veta vad som finns i din produkt

För att rapportera att en sårbarhet i din produkt utnyttjas aktivt måste du veta att den sårbara komponenten finns i din produkt. För en modern applikation med hundratals transitiva beroenden är det inget en människa kan svara på ur minnet.

Det är därför team bygger flöden för programvaruförteckningar nu, mer än ett år före det formella SBOM-kravet i december 2027. SBOM:en är inte målet. Målet är att kunna svara på frågan ”berörs vi?” inom några timmar, och SBOM:en är det som gör att den går att besvara.

Det besvärliga är att det här gäller även produkter som du levererade för flera år sedan. Om du har enheter ute på fältet som du fortfarande stöder och som kör firmware byggd 2022 ur ett beroendeträd som ingen dokumenterade, är det ett verkligt arbete att rekonstruera det.

Du måste hålla utkik

Kännedom startar klockan, och kännedomen förväntas vara aktiv snarare än tillfällig. Det betyder att bevaka flöden med sårbarhetsinformation, prenumerera på säkerhetsmeddelanden för dina komponenter, följa kataloger över kända utnyttjade sårbarheter och ha en kanal där säkerhetsforskare kan nå dig och få svar.

Du måste ha en beslutsväg

Någon måste kunna avgöra, när som helst på dygnet, om en incident når upp till tröskeln och om klockan har börjat ticka. Utan en namngiven roll och en eskaleringsväg går de första timmarna åt till att reda ut vem som får fatta beslutet.

Beroenden som nått slutet av sin livscykel blir en belastning

Om en komponent i din produkt inte längre får säkerhetsuppdateringar har du ändå rapporteringsskyldigheten när den utnyttjas, och du har ingen rättelse uppströms att hänvisa till. Att granska beroenden som nått slutet av sin livscykel är något av det mest användbara du kan göra nu, eftersom svaret ibland tvingar fram en migrering som har sin egen ledtid.

Vad den fulla tillämpningen i december 2027 innebär

Skyldigheterna från december 2027 är det större programmet, och arbetet med dem måste börja långt innan dess.

Inbyggd säkerhet och säkerhet som standard. Produkter måste utformas, utvecklas och tillverkas så att de har en lämplig cybersäkerhetsnivå utifrån risken. Inga standardlösenord. Säker konfiguration från start. Minimerad attackyta. Skydd av data under överföring och i vila.

Hantering av sårbarheter. En dokumenterad process som täcker identifiering, åtgärd, testning, distribution och offentliggörande. Säkerhetsuppdateringar måste tillhandahållas utan dröjsmål och utan kostnad, under en supportperiod som speglar produktens förväntade livslängd, med fem år som en vanlig referenspunkt.

Programvaruförteckning. I ett maskinläsbart format, som minst täcker beroendena på högsta nivån och hålls aktuell.

Teknisk dokumentation och bedömning av överensstämmelse. De flesta produkter bedöms av tillverkaren själv. Viktiga och kritiska kategorier, som omfattar sådant som lösenordshanterare, VPN-tjänster, operativsystem och industriella styrsystem, kräver att en tredje part är inblandad.

CE-märkning. Den digitala motsvarigheten till den fysiska märkningen, som intygar överensstämmelse.

Policy för samordnat offentliggörande av sårbarheter. Publicerad, med en kontaktpunkt som fungerar.

Vem som faktiskt omfattas

Några gränsfall kommer upp hela tiden.

Fri programvara och programvara med öppen källkod som utvecklas utanför en kommersiell verksamhet faller till stor del utanför. Akten inför begreppet förvaltare av programvara med öppen källkod, med lättare skyldigheter. Men om du kommersialiserar öppen källkod, eller levererar den i en produkt som du säljer, är produktskyldigheterna dina.

Programvara som tjänst (SaaS) står i regel utanför CRA och faller i stället under NIS2, men lösningar för fjärrdatabehandling som är en integrerad del av en produkt med digitala element dras in. Om din enhet är beroende av din molnbaserade backend för att fungera följer den backenden med produkten.

Importörer och distributörer har också skyldigheter. Om du släpper ut en tredje parts produkt på EU-marknaden under ditt eget namn eller varumärke behandlas du som tillverkare.

Produkter som redan regleras på annat håll, som medicintekniska produkter, bilar och luftfartsutrustning, hanteras inom sina egna regelverk.

Frågorna om tillämpningsområdet är verkligen inte triviala, och det här är ett ställe där en timme med en jurist sparar månader av felriktat utvecklingsarbete.

Vad vi skulle göra nu

Om du omfattas och börjar nu är det här ordningen som fungerar:

Först: inventera produkterna. Vad har du faktiskt på EU-marknaden? Inklusive gamla versioner som fortfarande används, varianter under andras varumärken och produkter som du distribuerar åt någon annan. Den listan är oftast längre än någon tror.

För det andra: bygg in generering av SBOM i CI. Generera en SBOM vid varje bygge, i CycloneDX eller SPDX, spara den tillsammans med releaseartefakten och se till att den går att söka i. Poängen är att kunna fråga ”vilka av våra levererade releaser innehåller det här biblioteket?” och få ett svar inom några minuter.

För det tredje: koppla in bevakning av sårbarheter. Mata in din SBOM-data i en skanner som bevakar säkerhetsmeddelanden och kataloger över kända utnyttjade sårbarheter, och skicka larmen till en kanal som någon läser.

För det fjärde: skriv körboken för incidenter. Vem som utlyser, vem som bedömer, vem som rapporterar, vem som kommunicerar. Namngivna personer, ersättare och kontakter utanför kontorstid. Öva den sedan en gång med ett påhittat säkerhetsmeddelande. Det är under övningen som du upptäcker att personen som har inloggningsuppgifterna till rapporteringsplattformen är på semester.

För det femte: publicera en policy för offentliggörande av sårbarheter. En security.txt-fil, en adress som bevakas och en angiven svarstid. Det är en eftermiddags arbete, och det är skillnaden mellan att höra om ett problem från en forskare och att höra om det från en journalist.

För det sjätte: börja med arbetet inför december 2027. Säkra standardinställningar, uppdateringsmekanismer, beslut om supportperioder och dokumentation är arkitekturfrågor, inte pappersarbete. Produkter som du utformar 2026 kommer fortfarande att finnas på marknaden 2028.

Överlappningen som ingen utnyttjar

Det finns en betydande överlappning mellan CRA och andra regelverk, och de flesta företag hanterar vart och ett för sig, vilket är slöseri.

En SBOM som byggts för CRA besvarar de flesta frågorna om leveranskedjan i NIS2. Körboken för incidenter överlappar med den tidiga varningen inom 24 timmar i NIS2 och med anmälan av personuppgiftsincidenter inom 72 timmar enligt GDPR. Processerna för hantering av sårbarheter matar direkt in i kunders säkerhetsenkäter och i storföretags upphandlingar.

Bygg dem en gång som en plattformsförmåga. Alternativet är tre team som bygger tre versioner av samma tillgångsinventering.

Var du får hjälp

Vi bygger och underhåller programvara för företag som säljer på EU-marknaden, vilket allt oftare innebär att bygga den insyn i leveranskedjan och den uppdateringsinfrastruktur som CRA förutsätter. Om du håller på att reda ut om du omfattas, eller om rapporteringsskyldigheten redan gäller dig och ingenting bevakar dina komponenter, hör av dig på office@c9group.dev.

Vår tjänst för underhåll av äldre system är ofta där det här börjar, eftersom produkterna med sämst insyn i sina beroenden oftast är de äldsta. Den bredare regulatoriska bilden finns i vår guide till EU:s digitala regelefterlevnad 2026.

Vi är ingenjörer, inte jurister. Beslut om tillämpningsområde och klassificering hör hemma hos din jurist, och vi bygger efter det svar hen ger.