Cyber Resilience Acts rapporteringsplikt är i kraft. De flesta tillverkares processer är fortfarande teater.

Idag, den 11 september 2026, träder Cyber Resilience Acts rapporteringsplikt i kraft i hela Europeiska unionen. Inte i december 2027, när de väsentliga produktkraven landar och alla har fått höra att den riktiga uppgörelsen väntar då. Idag. Om du tillverkar en produkt med digitala element och säljer den på EU-marknaden börjar klockan för din första anmälan att ticka från och med nu, oavsett om din organisation hade markerat datumet eller inte.

Jag skrev i juli att Cyber Resilience Act var den reglering som ingen bevakade tillräckligt noga, den som kan dra en produkt av marknaden i stället för att bara bötfälla företaget bakom den. Den texten fokuserade på den stora efterlevnadsbilden: tillämpningsområde, kategorisering, förhållandet till NIS2. Den här handlar om den mycket smalare, mycket skarpare skyldighet som just trädde i kraft, och om det obekväma gapet mellan hur många tillverkare som säger att de känner till den och hur många som faktiskt kan agera på den inom de timmar lagen ger dem.

Datumet ingen bevakade

Det mesta av bevakningen av CRA kretsar fortfarande kring december 2027, och det är förståeligt, eftersom det är då de väsentliga cybersäkerhetskraven och skyldigheterna kring bedömning av överensstämmelse gäller fullt ut. Men artikel 14 i förordningen skilde ut ett separat, tidigare datum specifikt för rapportering: från och med den 11 september 2026 måste tillverkare anmäla aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar deras produkter, och den plikten gäller produkter som redan finns på marknaden, inte bara nya lanseringar.

Europeiska kommissionen publicerade sin praktiska vägledning om detta den 27 juli 2026, bara veckor innan datumet trädde i kraft. Det är ett smalt fönster för en skyldighet med en första tidsfrist på 24 timmar kopplad till sig. De väsentliga kraven i december 2027 ger tillverkare ungefär femton månaders startsträcka från och med nu. Rapporteringsplikten gav långt mindre.

Vad exakt måste du rapportera?

Det här är frågan som ställer till det för folk, och den är värd att besvara precist snarare än i allmänna ordalag.

Du rapporterar en aktivt utnyttjad sårbarhet, alltså att det finns trovärdiga bevis för att någon just nu använder den mot din produkt. Du rapporterar en allvarlig incident, alltså något som faktiskt äventyrar din produkts säkerhet, inte bara en teoretisk svaghet. Vad du inte rapporterar är varje CVE som tilldelas din kodbas, varje fynd från ditt eget penetrationstest, eller varje inrapportering genom ditt program för ansvarsfull sårbarhetsrapportering eller din bug bounty, om det inte finns bevis för att den faktiskt har utnyttjats. Det webbinarium som det nederländska ekonomi- och klimatministeriet och National Cyber Security Centre (NCSC) höll den 27 augusti var tydligt om just den distinktionen, och med goda skäl: utan den skulle tillverkare antingen dränka sitt nationella CSIRT i brus eller, ännu värre, anta att varje sårbarhetsrapport kräver samma 24-timmarsbrådska och bränna ut det team som ska hantera dem som faktiskt betyder något.

Du kan fortfarande rapportera fallen med lägre allvarlighetsgrad frivilligt, och det finns goda skäl att bygga upp den vanan. Men den rättsliga plikten vilar specifikt på aktivt utnyttjande och allvarliga incidenter, och att veta var den gränsen går är det första din incidenthanteringsprocess måste få rätt.

Klockan pausar inte för ert incidenthanteringsmöte

När du väl vet är tidslinjen stegvis och obeveklig. En tidig varning går ut inom 24 timmar från att du blir medveten. En fylligare anmälan följer inom 72 timmar och täcker det du vet vid den tidpunkten om karaktären, konsekvenserna och de begränsande åtgärderna. En slutrapport avslutar ärendet: fjorton dagar efter att en korrigerande åtgärd blir tillgänglig för en sårbarhet, eller en månad för en allvarlig incident, enligt Europeiska kommissionens vägledning.

Freshfields analys av den nya skyldigheten gör en poäng som är värd att stanna vid: rapporteringsperioderna börjar i samma stund som du blir medveten, och klockan stannar inte på helger eller helgdagar. Det finns ingen respit för att din säkerhetsansvariga var på en konferens, eller för att incidenten inträffade en fredagkväll. Om din organisation inte redan har en definierad process för vem som bedömer en rapport, vem som avgör att den passerar tröskeln och vem som lämnar in den, då bygger du den processen för första gången under en pågående 24-timmarsfrist, vilket är precis fel ögonblick att bygga någonting.

Rapporteringen i sig går genom ditt nationella CSIRT, NCSC i Nederländerna, och den EU-omfattande Single Reporting Platform som drivs av ENISA, så en tillverkare i Belgien, Tyskland eller var som helst annars i EU följer samma stegvisa tidslinje via sin egen nationella kontaktpunkt. Mekaniken skiljer sig något åt mellan medlemsstaterna; skyldigheten och tidsfristerna gör det inte.

Varför är beredskapssiffrorna så här dåliga?

Här är var påståendet att “de flesta tillverkares processer är teater” måste förtjäna sin plats, och enkätdatan stöder det mer skarpt än jag hade väntat mig.

ENISA:s SME Cyber Resilience Maturity Assessment Model, publicerad den 13 juli 2026 och baserad på fältarbete med 194 organisationer i 31 länder, fann hög medvetenhet om CRA men genomgående svag praktisk beredskap, där incidenthantering och hantering av produktens livscykel poängsattes som de två svagaste områdena totalt sett. Medvetenhet om att en lag finns är inte samma sak som att ha en process som kan agera inom ett 24-timmarsfönster.

Linux Foundation och OpenSSF:s beredskapsforskning om CRA för 2026, hämtad från 843 respondenter, berättar en liknande historia från en annan vinkel. Sextiosex procent visste fortfarande inte vad de faktiskt behövde göra för att uppfylla kraven, en siffra som knappt hade rört sig från 62 procent året innan. Bara 41 procent av tillverkarna förväntade sig att nå full efterlevnad till tidsfristen i december 2027, och bara 34 procent identifierade det datumet korrekt över huvud taget. Bland de respondenter som alls var medvetna om CRA kunde 54 procent fortfarande inte tydligt skilja mellan en tillverkares skyldigheter och en förvaltares.

Inget av detta är en kritik mot något enskilt efterlevnadsteam. Det speglar en reglering som gick från abstrakt till operativ snabbare än de flesta organisatoriska processer kunde följa. Men det innebär att en betydande andel av de tillverkare som läser detta passerade gränsen den 11 september utan någon beprövad process bakom sig, vilket är precis det scenario som rapporteringsplikten var utformad att avslöja.

Vem måste faktiskt rapportera?

Enligt CRA vilar rapporteringsskyldigheten på tillverkaren, den aktör som släpper ut en produkt med digitala element på EU-marknaden under sitt eget namn eller varumärke, och organisationens storlek undantar dig inte. En importör eller distributör bär i allmänhet ingen självständig rapporteringsplikt, om den inte säljer under sitt eget varumärke eller väsentligt modifierar produkten, i vilket fall den i praktiken blir tillverkaren för den produkten. Förvaltare av öppen källkod möter en lättare version av samma plikt, vilket speglar det annorlunda förhållande de har till de produkter de underhåller. Små och mikroföretag omfattas också fullt ut; den enda eftergift som det nederländska NCSC har bekräftat är att det inte finns någon påföljd för att missa det strikta 24-timmarsfönstret i den kategorin, vilket är en förmildring, inte ett undantag.

En detalj värd att lyfta fram eftersom den orsakar verklig förvirring: CRA i sig kräver ingen registrering i förväg innan du kan rapportera. Du behöver inget konto eller någon inloggning för att lämna in en anmälan. Det är ett medvetet designval, skilt från den registreringsplikt som finns enligt Cyberbeveiligingswet (den nederländska implementeringen av NIS2) för organisationer som också omfattas av den lagen. De två skyldigheterna löper parallellt, inte som en kombinerad process, och att blanda ihop dem är ett lätt misstag att göra.

Hur ser “förberedd” faktiskt ut?

Att förbereda sig för CRA:s rapporteringsplikt är i princip inte komplicerat. Det är krävande i praktiken, vilket är ett annat problem.

Börja med en ärlig inventering av vad som faktiskt finns i dina produkter, helst genom en Software Bill of Materials (SBOM), eftersom du inte kan bedöma om en rapporterad sårbarhet påverkar dig om du inte vet vilka komponenter du levererar. Sätt dina egna interna trösklar i förväg för vad som räknas som aktivt utnyttjande eller en allvarlig incident, så att den bedömningen inte görs för första gången under press. Bygg en eskaleringsväg med namngivna roller: vem som slår larm, vem som beslutar, vem som lämnar in. Skriv utkast till mallar för den tidiga varningen, 72-timmarsanmälan och slutrapporten nu, medan ingen står under en tidsfrist. Och samordna detta med vad du redan rapporterar under, eftersom ett rimligt antal av de tillverkare som läser detta också omfattas av Cyberbeveiligingswet eller AVG, och att driva tre osamordnade rapporteringsprocesser är en risk i sig.

Detta är, inte av en tillfällighet, samma disciplin som jag argumenterade för i juli när jag skrev om CRA:s bredare efterlevnadskrav: vet vad du har, kategorisera det ärligt och bygg pappersarbetet innan tillsynsmyndigheten frågar efter det. Rapporteringsplikten har helt enkelt flyttat det argumentet från “så småningom” till “nu”.

Om en kund berättade för dig i morse att någon aktivt utnyttjade en sårbarhet i din produkt, skulle din organisation då veta, inom 24 timmar, exakt vem som tar emot den rapporten? Om det ärliga svaret är “det löser vi”, då trädde rapporteringsplikten inte i kraft idag för intet.

Källor

• European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: digital-strategy.ec.europa.eu/en/policies/cra-reporting
• ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026.
• Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: linuxfoundation.org
• Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: freshfields.com
• Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.