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.
Sammanfattning
- Brådskande rapportering gäller sedan den 11 september 2026: båda flödena använder en 24h tidig varning och en 72h anmälan; slutrapporten ska lämnas 14 dagar efter att en korrigerande eller riskreducerande åtgärd finns tillgänglig för sårbarheter och inom 1 månad efter 72h-anmälan för allvarliga incidenter.
- Skicka en gång via ENISA SRP: plattformen dirigerar rapporten till koordinator-CSIRT och gör den tillgänglig för ENISA.
- Aktiv exploatering kräver tillförlitliga bevis för att en fientlig aktör exploaterade sårbarheten i ett system utan tillstånd; offentliggörande, offentlig PoC eller forskardemonstration räcker inte i sig.
- CVD-policyn är obligatorisk: skriftlig, publicerad, tillämpad och kopplad till rapporteringströskeln när triage finner aktiv exploatering.
- VEX stödjer rapporteringsbeslut genom att dokumentera om en CVE i en SBOM-komponent faktiskt påverkar produkten.
- Bötesdetaljer hör hemma i enforcement-guiden: sena eller uteblivna rapporter kan skapa allvarlig sanktionsrisk; se CRA-böter och enforcement för nivåer och SME-undantag.
Rapporteringsmodellen i praktiken: tidig varning, detaljerad anmälan, slutrapport och hänvisning till enforcement.
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:
- Rapportera varje aktivt utnyttjad sårbarhet i produkten till koordinator-CSIRT och ENISA enligt 24h / 72h / 14d.
- Rapportera varje allvarlig incident som påverkar produktens säkerhet enligt 24h / 72h / 1 månad.
- 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 11 september 2026: SRP är tillgänglig 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 uppdaterade sin FAQ och sin registreringsvägledning för Assigned Representative den 10 september 2026, och sin gränssnittsvägledning och anmälningsvägledning den 9 september 2026. Den 9 september 2026 publicerade ENISA också en AR User Manual på 55 sidor, klick-för-klick-genomgången av registreringen, de tre inlämningsstegen och hur du uppdaterar en anmälan. SRP-ordlistan är version 1.3 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 vid lanseringen. ENISA anger att all vägledning är bästa tillgängliga kunskap i dag och kan ändras. Skapa ditt EU Login-konto nu, använd vägledningen för ENISA SRP-registrering och kontakta cra-srp-helpdesk@enisa.europa.eu vid behov.
Rapporteringstidsfrister i detalj
Rapporteringstabell
| Steg | Sårbarhet | Allvarlig incident | Startpunkt |
|---|---|---|---|
| Tidig varning | 24 timmar | 24 timmar | Tillverkaren får kännedom |
| Detaljerad anmälan | 72 timmar | 72 timmar | Tillverkaren får kännedom |
| Slutrapport | 14 dagar efter att korrigerande eller riskreducerande åtgärd finns | 1 månad efter 72h-incidentanmälan | Olika ankare |
| Användarinformation | Utan onödigt dröjsmål | Utan onödigt dröjsmål | Användarinformation |
Vad varje inlämning innehåller
Den tidiga varningen är en varning, inte full analys. 72h-anmälan ger allmän information om produkt, exploit eller incident, vidtagna åtgärder, användaråtgärder och känslighet där relevant. Slutrapporten innehåller minst de uppgifter som krävs för respektive flöde: sårbarhetsbeskrivning, allvarlighetsgrad, påverkan och korrigerande åtgärder, eller incidentbeskrivning, trolig orsak och pågående åtgärder.
- 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.
- +24h. Skicka den tidiga varningen via ENISA SRP.
- +72h. Lägg till tekniska detaljer, berörda versioner, exploateringsstatus och åtgärdsstatus.
- Åtgärd tillgänglig. För sårbarheter börjar slutrapportens klocka här, inte vid upptäckt.
- +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.3 listar 39 fält: 18 gemensamma för båda flödena, 12 som bara gäller en aktivt utnyttjad sårbarhet och 9 som bara gäller en allvarlig incident. 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.
| # | Fält | Tidig varning 24h | 72h | Slutrapport |
|---|---|---|---|---|
| Gemensamma fält | ||||
| 1 | Anmälningstyp (sårbarhet eller incident) | X | C | C |
| 2 | Titel | X | C | C |
| 3 | Sammanfattning | X | C | C |
| 4 | Tillverkarens namn | X | C | C |
| 5 | Medlemsstater där produkten är tillgänglig (berörd CSIRT) | X | C | C |
| 6 | Produktnamn | X | C | C |
| 7 | Produktversion | X | C | C |
| 8 | Produkttyp (standard, viktig eller kritisk) | O | C | C |
| 9 | Produktklass | O | C | C |
| 10 | Produktkategori | O | C | C |
| 11 | Indikator för att stödet upphört | O | C | C |
| 12 | Komponentnamn | O | C | C |
| 13 | Riskreducerande åtgärd väntas inom kort | O | C | C |
| 14 | Användaråtgärd som kan minska påverkan | O | C | C |
| 15 | Bedömd informationskänslighet | O | O | C |
| 16 | Vidtagna korrigerande eller riskreducerande åtgärder | O | O | X |
| 17 | Korrigerande eller riskreducerande åtgärder som användare kan vidta | O | O | X |
| 18 | Angreppsvektor | - | O | O |
| Aktivt utnyttjad sårbarhet | ||||
| v19 | CVE-ID | O | C | C |
| v20 | EUVD-ID | O | C | C |
| v21 | Allmän information | O | X | C |
| v22 | Datum då korrigerande eller riskreducerande åtgärd blev tillgänglig | O | O | X |
| v23 | Detaljer om den tillgängliga säkerhetsuppdateringen eller korrigerande åtgärden | O | O | X |
| v24 | Fullständig beskrivning av sårbarhetens allvarlighetsgrad | O | O | X |
| v25 | Fullständig beskrivning av sårbarhetens påverkan | O | O | X |
| v26 | Datum och tid då du fick kännedom om den aktivt utnyttjade sårbarheten [1] | X | C | C |
| v27 | Fientlig aktör som har utnyttjat eller utnyttjar sårbarheten | O | O | I |
| v28 | Särskilda exceptionella omständigheter (PEC) | - | O | - |
| v29 | Skäl till PEC-fördröjning | - | O | - |
| v30 | Ytterligare information | O | O | C |
| Allvarlig incident | ||||
| i31 | Incident som misstänks orsakad av olagliga eller fientliga handlingar | X | C | C |
| i32 | Allmän information om incidentens karaktär | O | X | C |
| i33 | Tillämpade och pågående riskreducerande åtgärder | O | O | X |
| i34 | Detaljerad beskrivning av incidentens allvarlighetsgrad | O | O | X |
| i35 | Detaljerad beskrivning av incidentens påverkan | O | O | X |
| i36 | Typ av hot eller trolig grundorsak till incidenten | O | O | X |
| i37 | Datum och tid då du fick kännedom om incidenten (UTC) [2] | X | X | C |
| i38 | Datum och tid då incidenten inträffade (UTC) | O | X | O |
| i39 | Inledande bedömning av incidenten | O | X | C |
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.3, senast uppdaterad 10 september 2026.
Vad som utlöser rapporteringsskyldighet
1. Aktivt utnyttjade sårbarheter
Aktivt utnyttjad sårbarhet betyder att det finns tillförlitliga bevis på att en fientlig aktör exploaterade sårbarheten i ett system utan tillstånd och att tillverkaren fått kännedom om det. Offentlig PoC eller forskardemonstration räcker inte i sig.
2. Allvarliga incidenter
En allvarlig incident är rapporteringspliktig när den påverkar, eller kan påverka, produktens skydd av tillgängligheten, autenticiteten, riktigheten eller konfidentialiteten för känsliga eller viktiga data eller funktioner, eller när den leder eller kan leda till skadlig kod i produkten eller användarens system.
Rapporteringspliktiga och icke-rapporteringspliktiga scenarier
| Scenario | Rapporteringsplikt? | Varför |
|---|---|---|
| Privat forskarrapport | Nej | Inga bevis på exploatering; hantera via CVD |
| Offentlig PoC | Nej | Publicering är inte exploatering |
| Kund rapporterar aktivitet som matchar exploatering | Bedöm | Rapportera om bevisen är tillförlitliga |
| Exploatering observerad i det fria | Ja | Tillförlitligt bevis på illvillig användning |
| SBOM-komponent med känd exploaterad CVE | Bedöm | Endast om din produkt påverkas |
| Din produkt är måltavla för namngivna hotaktörer | Ja | Direkta bevis på exploatering |
| Generisk skadlig kod utnyttjar en sårbarhetsklass som din produkt har | Bedöm | Endast om din specifika implementering påverkas |
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. Rapporteringstiden startar när den inledande bedömningen ger tillverkaren en rimlig grad av säkerhet. En offentlig CVD-sida och security.txt under /.well-known/security.txt är det praktiska sättet att göra kanalen hittbar.
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:
| Status | Innebörd |
|---|---|
not_affected |
Sårbarheten finns i komponenten men påverkar inte den här produkten (den sårbara kodvägen är inte nåbar, funktionen anropas inte, konfigurationen begränsar risken och så vidare). En motivering förväntas. |
affected |
Sårbarheten påverkar den här produkten. Åtgärd och rekommendation förväntas. |
fixed |
Sårbarheten fanns och har åtgärdats i den här versionen. |
under_investigation |
Statusen är ännu inte fastställd; bedömningen pågår. |
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 tar inte bort rapporteringsskyldigheten och täcker inte 72h-anmälan eller slutrapporter. Medelstora företag får ingen sådan lättnad. 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.
Vanliga frågor
När börjar CRA-rapporteringsskyldigheterna?
Obligatorisk CRA-rapportering av sårbarheter och incidenter gäller sedan den 11 september 2026. Från det datumet måste tillverkare använda ENISA SRP för 24h-varning, 72h-anmälan och slutrapporter. De bredare produktkraven gäller från 11 december 2027.
Vad är ENISA SRP?
SRP är den gemensamma kanalen för obligatoriska CRA-rapporter. Frivillig rapportering är inte tillgänglig vid lanseringen och kommer i en senare fas. ENISA har publicerat ett faktablad och tre vägledningar, skrivna för Assigned Representative, det SRP-konto som rapporterar för en tillverkare eller en förvaltare av programvara med fri och öppen källkod. Plattformen är tillgänglig från den 11 september 2026 på portal.cra-srp.enisa.europa.eu. Följ kommissionens sida och ENISA SRP-sidan för registreringsdetaljer.
Är CVD-policy obligatorisk?
Ja. Varje tillverkare behöver en CVD-policy och en praktisk intagskanal. security.txt nämns inte i CRA men är ett praktiskt sätt att publicera kontaktadressen.
Behövs VEX?
VEX krävs inte vid namn, men ett tillämplighetsregister är mycket användbart för att motivera varför en känd CVE inte påverkar produkten.
Vilka böter gäller?
Sena eller uteblivna rapporter kan skapa allvarlig sanktionsrisk; bara mikro- och småföretag har en smal lättnad för den första 24h-varningen. Se CRA-böter och enforcement för hela strukturen.
Var skickar vi in om produkten säljs i flera medlemsstater?
Skicka en gång via din koordinator-CSIRT:s SRP-slutpunkt. Utan huvudsakligt etableringsställe i unionen används kedjan tillverkarens representant, importör, distributör, största användarkoncentration.
Pausar 24h-klockan på helger?
Nej. Klockorna går på kalendertid, så helg- och helgdagsberedskap är operativt nödvändig.
Hur samspelar CRA med NIS 2?
Båda kan gälla samma händelse, men CRA är produktnivå via SRP och NIS 2 är entitets- eller tjänstenivå via nationell kanal. Behandla påståenden om att en inlämning räcker för båda som obekräftade tills myndigheterna publicerar slutlig vägledning.
Ordlistan anger fältet som obligatoriskt vid den tidiga varningen på 24 timmar och noterar i samma rad att det kommer i nästa version av plattformen. Tills den versionen är på plats kan du sakna fältet på skärmen. Håll din egen tidsstämpel för kännedom och var beredd att lämna den oavsett vilket. ↩︎
Ordlistan noterar att fältet i den nuvarande versionen har etiketten ”Date and time when the incident was detected (UTC time)”. Detektion är inte samma sak som kännedom, så notera båda. ↩︎