Från och med 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 börjar 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.
Status i juni 2026: SRP är planerad att vara operativ senast den 11 september 2026, med testperiod innan dess. ENISA uppger att åtkomst- och registreringsanvisningarna, samt utbildnings- och övningsmaterial, publiceras under juni 2026, så registreringsmekaniken är fortfarande under publicering. ENISA uppger också att inget SRP-API tillhandahålls i detta skede, så planera rapporteringsberedskapen kring inlämning via plattformen, inte kring API-automatisering. För registreringsmekaniken, se ENISA SRP-registrering. Följ kommissionens rapporteringssida och ENISA SRP-sidan innan du förlitar dig på ett specifikt registreringssteg.
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 tillverkaren får tillförlitliga bevis på aktiv exploatering.
- +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-FAQ (fråga 16) listar de fält som förväntas vid varje rapporteringssteg. ENISA beskriver dessa som fält som kommer att vara obligatoriska (direkt ur CRA eller som logisk följd) eller valfria, varför de bör betraktas som preliminära tills plattformen är slutgiltig. Koder: X obligatorisk, O valfri, C kopieras från föregående steg som standard eller uppdateras, A automatisk (visas inte för inlämnaren), I obligatorisk om informationen är tillgänglig.
| # | Fält | 24h | 72h | Final |
|---|---|---|---|---|
| Gemensamma fält | ||||
| 1 | Anmälningstyp (sårbarhet eller incident) | X | C | C |
| 2 | Anmälningsnivå (24h, 72h eller final) | X | X | X |
| 3 | Rapporteringstid, 24h | A | A | A |
| 4 | Rapporteringstid, 72h | A | A | A |
| 5 | Rapporteringstid, final | A | A | A |
| 6 | Rapportör | A | A | A |
| 7 | Tillverkare | X | C | C |
| 8 | Produkt | X | C | C |
| 9 | Produkttyp (standard, viktig eller kritisk) | O | C | C |
| 10 | Produktkategori (om typen är viktig eller kritisk) | O | C | C |
| 11 | Medlemsstater där produkten är tillgänglig | I | C | C |
| 12 | Titel | X | C | C |
| Sårbarhet | ||||
| v13 | CVE-ID | O | C | C |
| v14 | EUVD-ID | O | C | C |
| v15 | Allmän information, i synnerhet: | O | X | C |
| v16 | a. Sårbarhetens allmänna karaktär | O | X | C |
| v17 | b. Exploateringens allmänna karaktär | O | X | C |
| v18 | Vidtagna korrigerande eller riskreducerande åtgärder | O | X | C |
| v19 | Korrigerande eller riskreducerande åtgärder som användare kan vidta | O | X | C |
| v20 | Bedömd informationskänslighet | O | I | C |
| v21 | Datum då korrigerande eller riskreducerande åtgärd blev tillgänglig | O | O | X |
| v22 | Fullständig beskrivning av sårbarheten, inkl.: | O | O | X |
| v23 | a. Sårbarhetens allvarlighetsgrad | O | O | X |
| v24 | b. Sårbarhetens påverkan | O | O | X |
| v25 | Fientlig aktör som utnyttjat eller utnyttjar den | O | O | I |
| v26 | Detaljer om säkerhetsuppdateringen eller korrigerande åtgärder | O | O | X |
| Incident | ||||
| i13 | Incident som misstänks orsakad av olagliga eller fientliga handlingar | X | C | C |
| i14 | Allmän information om incidentens karaktär | O | X | C |
| i15 | Datum och tid för upptäckt av incidenten | O | X | C |
| i16 | Datum och tid för incidenten | O | X | C |
| i17 | Inledande bedömning av incidenten | O | X | C |
| i18 | Vidtagna korrigerande eller riskreducerande åtgärder | O | X | C |
| i19 | Korrigerande eller riskreducerande åtgärder som användare kan vidta | O | X | C |
| i20 | Bedömd informationskänslighet | O | I | C |
| Detaljerad beskrivning av incidenten, inkl.: | O | O | X | |
| i21 | a. Incidentens allvarlighetsgrad (kriterier nedan) | O | O | X |
| i23 | b. Incidentens påverkan | O | O | X |
| i24 | Typ av hot eller trolig grundorsak | O | O | X |
| i25 | Tillämpade och pågående riskreducerande åtgärder | O | O | X |
Allvarlighetsgrad, kriterier (i22): 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 SRP-FAQ, fråga 16.
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 |
Kännedom och bevis
CRA-definitionen använder tillförlitliga bevis, inte forensisk säkerhet. Om bevisen ännu inte är tillförlitliga ligger händelsen kvar i CVD- eller incidenttriage; när de blir tillförlitliga startar 24-timmarsklockan när tillverkaren får kännedom.
CVD-intag och rapporteringströskel
CVD-policyn är intaget som gör externa rapporter till strukturerad triage. När triage ger tillförlitliga bevis på aktiv exploatering löper brådskande rapportering parallellt med åtgärd och samordnat offentliggörande. 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 är inte obligatoriskt med namn, men ett tillämplighetsregister är mycket användbart. Det dokumenterar om en CVE i en SBOM-komponent är not_affected, affected, fixed eller under_investigation för en specifik produktversion. 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. Tillförlitliga bevis räcker; en slutförd forensisk utredning krävs inte före tidig varning.
- Blanda ihop CVD och brådskande rapportering. Forskarens rapport är CVD-intag; rapportering börjar med tillförlitliga bevis på 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 före september 2026.
Vanliga frågor
När börjar CRA-rapporteringsskyldigheterna?
Obligatorisk CRA-rapportering av sårbarheter och incidenter börjar 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 och frivilliga rapporter; ENISA uppger att funktionen för frivillig rapportering aktiveras efter den 11 september 2026. SRP är ännu inte i drift och ENISA uppger att åtkomst- och registreringsanvisningarna publiceras under juni 2026. 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.