CRA-rapportering av sårbarheter och incidenter

Sedan den 11 september 2026 måste CRA-tillverkare rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter via ENISA Single Reporting Platform. Den här guiden förklarar vad som utlöser en rapport, hur tidsfristerna på 24 timmar, 72 timmar, 14 dagar och 1 månad fungerar, och var CVD, VEX och användarinformation passar in.

Vad som måste rapporteras

CRA-rapportering har två obligatoriska händelseflöden och en skyldighet att informera användare. Skyldigheten ligger hos tillverkaren av produkten med digitala element på EU-marknaden:

1. Rapportera varje aktivt utnyttjad sårbarhet i produkten till koordinator-CSIRT och ENISA enligt 24h / 72h / 14d.
2. Rapportera varje allvarlig incident som påverkar produktens säkerhet enligt 24h / 72h / 1 månad.
3. Informera berörda användare om sårbarheten eller incidenten och korrigerande åtgärder utan onödigt dröjsmål.

Sidan täcker också två angränsande kontroller: obligatorisk CVD-policy och tillämplighetsbevis som VEX. Ingen av skyldigheterna har storlekströskel. Mikroföretag och småföretag får bara en smal sanktionslättnad för 24h-varningen; de är inte undantagna från rapportering.

ENISA Single Reporting Platform (SRP)

SRP är den enda kanalen för obligatoriska CRA-rapporter om sårbarheter och incidenter. Tillverkaren rapporterar en gång via koordinator-CSIRT:s elektroniska slutpunkt; rapporten är samtidigt tillgänglig för ENISA om inte den exceptionella mekanismen för fördröjd spridning tillämpas. Koordinator-CSIRT sprider därefter informationen till berörda CSIRT i andra medlemsstater.

Regeln om uppskjuten spridning låter koordinator-CSIRT skjuta upp den vidare spridningen under exceptionella omständigheter, på motiverade cybersäkerhetsrelaterade skäl och under den tid som är absolut nödvändig. Tillverkaren kan begära det och kan ange hur känslig informationen är, men beslutet ligger hos CSIRT och inte hos dig. Det finns en andra, separat fördröjning för en sårbarhet som koordinator-CSIRT har fått kännedom om genom ett förfarande för samordnad sårbarhetsutlämning. Då kan CSIRT hålla inne anmälan på motiverade cybersäkerhetsrelaterade skäl, under en tid som inte är längre än vad som är absolut nödvändigt och till dess att parterna i den utlämningen samtycker till att sårbarheten offentliggörs. Det är värt att känna till om du driver en CVD-process, men beslutet ligger hos CSIRT även här, så räkna inte med att ett embargo håller.

Särskilt exceptionella omständigheter, PEC, är en snävare och separat mekanism. Den gäller bara 72-timmarsanmälan om en aktivt utnyttjad sårbarhet, och bara när utnyttjandet är begränsat till din koordinators medlemsstat, när en bredare spridning skulle strida mot den statens väsentliga intressen, eller när själva spridningen skulle skapa en överhängande hög cybersäkerhetsrisk. Du åberopar den med en växlingsknapp i plattformen och kan lägga till en motivering. Koordinator-CSIRT beslutar. Så länge den gäller får ENISA ändå en begränsad uppsättning uppgifter: att en anmälan har gjorts, allmän information om produkten, utnyttjandets allmänna karaktär och att säkerhetsrelaterade skäl har angetts. Den fullständiga anmälan följer när fördröjningen upphör. ENISA:s PEC-vägledning beskriver förfarandet.

Status den 6 november 2026: SRP har varit tillgänglig sedan den 11 september 2026 på portal.cra-srp.enisa.europa.eu. På startsidan väljer du rollen Assigned Representative, det SRP-konto som rapporterar för en tillverkare eller en förvaltare av programvara med fri och öppen källkod. Det är inte samma sak som ett auktoriserat ombud enligt CRA. Inloggningen sker med EU Login, och EU Login-konton är personliga och måste ha flerfaktorsautentisering aktiverad. ENISA uppgraderade plattformen till version 1.3 den 4 november 2026 och uppger att dokumentationen fortfarande uppdateras. FAQ:n bär datumet 15 oktober 2026, och registrerings-, gränssnitts- och anmälningsvägledningen för Assigned Representative bär datumet 12 september 2026. Den 9 september 2026 publicerade ENISA först AR User Manual och gav ut den på nytt som version 1.3 den 4 november 2026, klick-för-klick-genomgången av registreringen, de tre inlämningsstegen och hur du uppdaterar en anmälan. SRP-ordlistan är version 1.6 och är referensen fält för fält. Den finns bara på engelska. Listan över CSIRT som utsetts till koordinatorer bär datumet 10 september 2026. Det finns inget API i den första versionen, så varje notifiering lämnas in via plattformens gränssnitt, och frivillig rapportering är inte tillgänglig ännu. ENISA anger att all vägledning är bästa tillgängliga kunskap i dag och kan ändras. Skapa ditt EU Login-konto innan du behöver det, använd vägledningen för ENISA SRP-registrering och kontakta cra-srp-helpdesk@enisa.europa.eu vid behov.

Rapporteringstidsfrister i detalj

Rapporteringstabell

Vad varje inlämning innehåller

Tidig varning (24 timmar). Den tidiga varningen är en varning, inte full analys. För sårbarheter ska den skickas utan onödigt dröjsmål och inom 24 timmar efter att du fått kännedom, och den ska i förekommande fall ange de medlemsstater där tillverkaren vet att produkten har tillhandahållits. För allvarliga incidenter ska den dessutom minst ange om incidenten misstänks vara orsakad av olagliga eller fientliga handlingar. Interna mallar kan lägga till fält för produktversion, allvarlighetsgrad, omfattning och ansvarig, men det är operativa fält och inte alla är lagliga minimikrav.

Detaljerad anmälan (72 timmar). Två skilda skyldigheter ligger i det här steget. 72-timmarsanmälan om en sårbarhet gäller aktivt utnyttjade sårbarheter och ger allmän information om produkten, exploiten, sårbarheten, vidtagna åtgärder, åtgärder för användare och känslighet där relevant. 72-timmarsanmälan om en incident gäller allvarliga incidenter och ger allmän information om incidenten, en första bedömning, vidtagna åtgärder, åtgärder för användare och känslighet där relevant.

Slutrapport. För sårbarheter börjar 14-dagarsklockan löpa när en korrigerande eller riskreducerande åtgärd finns tillgänglig, inte vid upptäckten och inte vid 72-timmarsanmälan. Slutrapporten ska minst innehålla en beskrivning av sårbarheten, allvarlighetsgrad och påverkan, information om fientliga aktörer där sådan finns och uppgifter om säkerhetsuppdateringen eller andra korrigerande åtgärder. För allvarliga incidenter förankras månadsfristen vid 72-timmarsanmälan om incidenten, och slutrapporten ska minst innehålla en detaljerad beskrivning av incidenten, allvarlighetsgrad och påverkan, trolig hottyp eller grundorsak samt tillämpade eller pågående riskreducerande åtgärder.

1. Tillverkaren får kännedom. 24h-klockan startar när en snabb inledande bedömning ger tillverkaren en rimlig grad av säkerhet om att en sårbarhet i produkten exploateras aktivt.
2. +24h. Skicka den tidiga varningen via ENISA SRP.
3. +72h. Lägg till tekniska detaljer, berörda versioner, exploateringsstatus och åtgärdsstatus.
4. Åtgärd tillgänglig. För sårbarheter börjar slutrapportens klocka här, inte vid upptäckt.
5. +14d. Skicka slutuppgifterna för sårbarhets- eller incidentflödet.

Allvarliga incidenter följer samma inledande steg på 24 timmar och 72 timmar, med slutrapporten förfallen inom 1 månad efter 72-timmarsanmälan.

Datafält i SRP:s rapporteringsmall

ENISA:s SRP-ordlista är referensen fält för fält över vad plattformen frågar efter i varje steg. Version 1.6 listar 43 fält: 19 gemensamma för båda flödena, 13 som bara gäller en aktivt utnyttjad sårbarhet, 9 som bara gäller en allvarlig incident och 2 avslutande anmärkningsfält. Den finns bara på engelska, och ENISA anger den som bästa tillgängliga kunskap i dag som kan ändras. Koder: X obligatorisk, O valfri, C kopieras från föregående steg som standard eller uppdateras, I obligatorisk om informationen är tillgänglig, - ej tillämplig i det steget.

Allvarlighetsgrad, kriterier (i34): en allvarlig incident är en som (1) negativt påverkar, eller kan negativt påverka, produktens förmåga att skydda tillgängligheten, autenticiteten, riktigheten eller konfidentialiteten för känsliga eller viktiga data eller funktioner, eller (2) har lett eller kan leda till att skadlig kod introduceras eller exekveras i produkten eller i en användares nätverks- och informationssystem.

Källa: ENISA:s SRP-ordlista, version 1.6, senast uppdaterad 21 oktober 2026.

Vad som utlöser rapporteringsskyldighet

1. Aktivt utnyttjade sårbarheter

En aktivt utnyttjad sårbarhet är en sårbarhet i produkten där det finns tillförlitliga bevis på att en fientlig aktör har utnyttjat den i ett system utan tillstånd. Tillverkaren måste också ha fått kännedom om utnyttjandet innan rapporteringsklockan startar.

Det är inte samma sak som offentligt avslöjande, en publicerad PoC eller en forskare som i ett labb visar att sårbarheten går att utnyttja. De signalerna hör till sårbarhetshanteringen och CVD-triagen, om de inte skapar tillförlitliga bevis på illvilligt utnyttjande mot ett verkligt system.

2. Allvarliga incidenter

En allvarlig incident är en incident som påverkar produktens säkerhet och som uppfyller något av två kriterier:

• den påverkar negativt, eller kan påverka negativt, produktens förmåga att skydda tillgängligheten, autenticiteten, riktigheten eller konfidentialiteten för känsliga eller viktiga data eller funktioner, eller
• den har lett eller kan leda till att skadlig kod förs in eller körs i produkten eller i användarens nätverks- och informationssystem.

Rapporteringspliktiga och icke-rapporteringspliktiga scenarier

Kännedom och bevis

CRA-definitionen använder tillförlitliga bevis för att fastställa en aktivt exploaterad sårbarhet. Kännedom är ett separat test: efter en snabb inledande bedömning måste tillverkaren ha en rimlig grad av säkerhet om att en sårbarhet i produkten exploateras aktivt. En slutförd forensisk utredning krävs inte.

CVD-intag och rapporteringströskel

CVD-policyn är intaget som gör externa rapporter till strukturerad triage. Om triage pekar på aktiv exploatering ska den bedömas snabbt. Den brådskande rapporteringsklockan startar när den inledande bedömningen ger tillverkaren en rimlig grad av säkerhet. Policyn är obligatorisk för varje produkt med digitala element, och det finns ingen tröskel för storlek eller små och medelstora företag. En offentlig CVD-sida och en security.txt under /.well-known/security.txt är det praktiska sättet att göra rapporteringskanalen hittbar.

Om själva CVD-policyn, inklusive obligatoriskt innehåll, konventioner för avslöjandefönster, språk om säker hamn och mallar för kommunikation med forskare, se guiden CRA samordnad sårbarhetsredovisning. Hur CVD passar in i hela livscykeln för sårbarhetshantering beskrivs i CRA sårbarhetshantering. Den samlade översikten över hantering och rapportering enligt artikel 14 finns i sårbarhetshantering och rapportering.

VEX och sårbarhetens tillämplighet

VEX (Vulnerability Exploitability eXchange) är ett strukturerat, maskinläsbart uttalande om huruvida en sårbarhet i en SBOM-komponent faktiskt påverkar en specifik produkt. Det omvandlar råa CVE-träffar till en försvarbar produktspecifik status:

För rapporteringen är nyckelfrågan tillämplighet plus aktiv exploatering. En sårbarhet som märkts affected och som stöds av tillförlitliga bevis på aktiv exploatering är den typ av händelse som startar 24-timmarsklockan för tidig varning. En sårbarhet som märkts not_affected med en väl underbyggd motivering stöder ett beslut att inte rapportera. Cyberresiliensförordningen nämner inte VEX vid namn, men VEX är ett praktiskt sätt att bevara den motiveringen. För VEX-format, exempel, motiveringstyper, verktyg och SBOM-integration, se VEX-guiden.

Lättnad för små tillverkare

Mikroföretag och småföretag (definierat som färre än 50 anställda och en årlig omsättning eller balansomslutning på upp till 10 miljoner euro; mikroföretag: färre än 10 anställda, 2 miljoner euro) har en smal lättnad från administrativa böter enbart för att missa den första 24h-varningen. Lättnaden gäller bara tidsböter för det första steget.

Fortfarande obligatoriskt, utan lättnad för små företag:

• 72-timmarsanmälan.
• Slutrapporten efter 14 dagar för sårbarheter och slutrapporten efter 1 månad för allvarliga incidenter.
• CVD-policyn.
• Alla andra produktsäkerhetsskyldigheter i CRA, inklusive baslinjen om inga kända exploaterbara sårbarheter.

Medelstora företag får ingen sådan lättnad. Det är ett snävt undantag från sanktioner och inte ett lättare rapporteringssystem. Hela strukturen finns i CRA-böter och enforcement.

Vanliga misstag

• Vänta på forensisk säkerhet. En snabb inledande bedömning och en rimlig grad av säkerhet räcker; en slutförd forensisk utredning krävs inte.
• Blanda ihop CVD och brådskande rapportering. Forskarens rapport är CVD-intag; rapportering börjar när den inledande bedömningen ger tillverkaren en rimlig grad av säkerhet om aktiv exploatering.
• En enda eskaleringsperson. 24h-klockan pausar inte för helger.
• Ingen publicerad CVD-policy. Ett internt dokument räcker inte.
• Inga tillämplighetsbeslut. Utan VEX eller motsvarande är det svårt att försvara varför en CVE inte påverkar produkten.
• Behandla SRP som framtidsproblem. Mallar, jour och CSIRT-relationer behövs redan innan den första händelsen.

1. Ordlistan förklarar fältet som tidpunkten då du eller en annan relevant part först upptäckte sårbarheten (”first detected”). Detektion är inte samma sak som kännedom, så notera båda. ↩︎