Föreställ dig en fredag eftermiddag på ett svenskt teknikbolag. En produktansvarig får in en rapport från en kund om att något beter sig fel i en av de uppkopplade enheterna. Åtkomstmönstren ser onormala ut, det finns färska indikationer i ett hotunderrättelseflöde, och det börjar framstå som rimligt att någon faktiskt utnyttjar en svaghet som ingen kände till i förrgår. Någon patch finns inte. Ingen vet ännu hur stor skadan är. Men i samma ögonblick som bolaget får tillförlitliga bevis för att sårbarheten faktiskt utnyttjas av en utomstående aktör börjar en klocka ticka. Från den 11 september 2026 har bolaget tjugofyra timmar på sig att lämna en första varning, och den ska gå till bolagets samordnande CSIRT och till ENISA samtidigt.
Det här är kärnan i artikel 14 i Cyber Resilience Act, och det är den del av regelverket som börjar gälla först. De materiella säkerhetskraven, det vill säga skyldigheten att bygga produkter säkra från början och att hantera sårbarheter löpande, med allt vad det för med sig av kontroll över komponenterna (i praktiken ofta en SBOM) och säkerhetsuppdateringar, träder i kraft först den 11 december 2027. Rapporteringsplikten kommer alltså femton månader tidigare, och den gäller även produkter som redan finns på marknaden. En tillverkare kan med andra ord vara skyldig att rapportera en klass av misslyckanden som den ännu inte är skyldig att förebygga.
Mekaniken är enkel att beskriva och svår att leva upp till. Två saker utlöser plikten: en aktivt utnyttjad sårbarhet och en allvarlig incident som påverkar produktens säkerhet. När bolaget blir medvetet om något av detta lämnas först en tidig varning inom tjugofyra timmar, sedan en mer fullständig anmälan inom sjuttiotvå timmar, och därefter en slutrapport. För sårbarheter ska slutrapporten lämnas senast fjorton dagar efter att en åtgärd finns tillgänglig, för allvarliga incidenter inom en månad. Allt sker via en enda kanal, Single Reporting Platform, som ENISA bygger och driver. En inlämning når den samordnande CSIRT:en i det land där bolaget har sin huvudsakliga etablering, och ENISA, samtidigt. Den mottagande CSIRT:en sprider sedan informationen vidare, utan dröjsmål, till motsvarande team i andra medlemsstater där produkten finns och till marknadskontrollmyndigheterna.
Det som sällan sägs är vad som händer när man lägger ihop alla dessa rapporter.
Regelverket som misstänker sig självt
Varje enskild anmälan är en beskrivning av en levande, oåtgärdad och bevisat exploaterbar svaghet i en produkt som finns ute på marknaden. Lägg ihop dem, dygn efter dygn, från hela unionen, och resultatet är en central och ständigt uppdaterad samling av exakt den information en angripare helst av allt vill ha. Det är, rent funktionellt, ett av de mest attraktiva underrättelsemål man kan konstruera.
Regelverket vet om detta. Huvudregeln är att den samordnande CSIRT:en och ENISA får tillgång samtidigt, om inte särskilt exceptionella omständigheter föreligger, och den vidare spridningen till andra länders CSIRT:er får i undantagsfall fördröjas på cybersäkerhetsgrunder. Kommissionen antog den 11 december 2025 delegerad förordning (EU) 2026/881, publicerad i EUT den 20 april 2026, som preciserar när en sådan fördröjning är tillåten. Grunderna faller i tre slag. Det första rör informationens egen karaktär: spridningen får skjutas upp om en åtgärd eller vägledning väntas inom sjuttiotvå timmar, om själva anmälan innehåller tillräckligt för att någon ska kunna bygga en exploateringsteknik utan vidare efterforskning, eller om informationen redan hanteras inom en pågående samordnad sårbarhetshantering. Det andra rör den mottagande CSIRT:ens förmåga att skydda uppgifterna, exempelvis när den själv drabbats av en incident. Det tredje är att själva plattformen har komprometterats eller tillfälligt inte fungerar.
Läs det en gång till. Ett instrument vars hela syfte är öppenhet och samordning var tvunget att förses med ventiler för hemlighållande riktade mot sin egen konstruktion. Det är inte en svaghet i lagstiftningen, det är ett ärligt erkännande av vad man håller på att bygga. Att intresseorganisationer som Cybersecurity Coalition och Hacking Policy Council under samrådet invände att sjuttiotvå timmar är för stelt, att tröskeln för vad som räknas som tillräckligt för en exploit borde tolkas brett, och att det saknas en tydlig process för att lösa tvister om fördröjningsbeslut, säger samma sak från andra hållet: det känsliga ligger inte i att rapportera, utan i vad som sedan sker med det rapporterade.
Det är också värt att skilja på två saker som lätt blandas ihop. Single Reporting Platform är intaget, platsen dit det färska och oläkta kommer in. Den europeiska sårbarhetsdatabasen EUVD, som ENISA lanserade i maj 2025, är publiceringen, platsen där åtgärdade sårbarheter görs kända. Det är skillnaden mellan ett sår och ett ärr, och det är intaget, inte publiceringen, som utgör risken.
Lärdomen vi redan har
Det här är ingen teoretisk oro. Redan under lagstiftningsarbetet varnade en grupp ledande säkerhetsforskare i ett öppet brev för att en skyldighet att lämna oåtgärdade sårbarheter till myndigheter riskerar att skapa statliga lager av sådan kunskap och att avskräcka från den ansvarsfulla, samordnade rapportering som faktiskt fungerar. Invändningen handlade inte om att rapportering är fel, utan om koncentration.
Historien har redan gett oss exemplet. EternalBlue var en sårbarhet som en statlig aktör kände till och behöll, tills kunskapen läckte och kort därefter användes i WannaCry och NotPetya, med global skada som följd. CRA bygger inte upp något offensivt lager i den meningen. Men den skapar koncentration. Den ser till att det färskaste, mest exploaterbara och minst åtgärdade konvergerar på ett ställe. Och en sådan plats är värd precis lika mycket för den som vill skydda som för den som vill skada.
Här finns en tråd som den som följt diskussionen om gränsöverskridande myndighetsåtkomst känner igen. När en sådan samling väl existerar flyttas den intressanta frågan från om uppgifterna är krypterade till vem som ytterst kan framtvinga åtkomst till dem. Det är inte en fråga CRA besvarar, men det är en fråga den gör mer angelägen.
Det som avgörs innan plattformen ens är igång
För en svensk tillverkare är den praktiskt viktigaste punkten inte deadlinen i sig, utan när klockan startar. Plikten knyts till att bolaget blir medvetet, och legaldefinitionen är preciserad: en aktivt utnyttjad sårbarhet är enligt artikel 3.42 en sårbarhet för vilken det finns tillförlitliga bevis för att en illvillig aktör har utnyttjat den i ett system utan systemägarens tillstånd. Det utesluter sårbarheter som hittats i god tro genom forskning eller egna tester, och det räcker inte med en publicerad sårbarhet eller ett demonstrerat angreppssätt. Men ett larm från en SOC, ett bekräftat intrång via produkten eller trovärdig underrättelse om att den utnyttjas i det vilda räcker. Tröskeln gäller faktiskt utnyttjande, inte en bekräftad slutsats om vidden, och tjugofyra timmar kan börja löpa innan säkerhetsteamet hunnit kartlägga någonting. Det som då avgör är inte hur snabbt man patchar, utan om man i efterhand kan visa när medvetenheten uppstod. Ett enda ställe dit alla rapporter, interna som externa, leds in. Ett dokumenterat triagebeslut. En namngiven person med behörighet och inloggning klar att lämna anmälan.
Och så den tystare poängen. Den apparat som krävs för att överhuvudtaget kunna rapportera, kontroll över komponenterna (i praktiken ofta en SBOM), kontinuerlig bevakning och en fungerande triage, är samma apparat som CRA:s materiella krav formellt inte kräver förrän i december 2027. Rapporteringsklockan drar fram de skyldigheterna i praktiken. De tillverkare som behandlar september 2026 som ett rapporteringsproblem kommer att famla. De som behandlar datumet som ögonblicket då hela sårbarhetshanteringen måste finnas på plats är tidigt ute med något de ändå hade varit tvungna att bygga.
Databasen som inte får läcka är, för stunden, mest ett löfte om arkitektur och delegerade akter. Det varje tillverkare faktiskt råder över är de tjugofyra timmarna, och förmågan att visa exakt när de började.