CRA sårbarhetsrapportering: ENISA SRP, 24h/72h/14d-klocka

EU:s cyberresilienslag (förordning (EU) 2024/2847) gör sårbarhetsrapportering till en tidsbunden rättslig skyldighet för varje tillverkare av en produkt med digitala element. Från och med den 11 september 2026 kräver Artikel 14 att aktivt utnyttjade sårbarheter och allvarliga incidenter rapporteras via ENISA Single Reporting Platform (SRP) enligt ett schema om 24 timmar, 72 timmar och 14 dagar, med stöd av en obligatorisk policy för samordnat sårbarhetssläpp (CVD) enligt Bilaga I Del II. Den här sidan är den kanoniska referensen: vad lagen kräver, när varje klocka börjar ticka, vad en regelföljande CVD-policy måste innehålla, hur VEX stödjer skyldigheten om "inga kända exploaterbara sårbarheter" och vilka böter enligt Artikel 64 som gäller när rapportering brister.

Vad kräver CRA för sårbarhetsrapportering?

Artikel 14 i cyberresilienslagen är det operativa kärnan i förordningens incidenthanteringsregim. Den ålägger varje tillverkare av en produkt med digitala element som släpps på EU-marknaden tre skyldigheter:

1. Anmäla varje aktivt utnyttjad sårbarhet i produkten simultant till den samordnande CSIRT och till ENISA, enligt schemat 24h / 72h / 14d (art. 14(1), 14(2)).
2. Anmäla varje allvarlig incident som påverkar produktens säkerhet, enligt schemat 24h / 72h / 1 månad (art. 14(3), 14(4)).
3. Informera användarna av den berörda produkten om sårbarheten eller incidenten och om eventuella korrigerande åtgärder, utan onödigt dröjsmål (art. 14(8)).

Artikel 14 kompletterar två andra skyldigheter som den här sidan också täcker: den obligatoriska CVD-policyn enligt Bilaga I Del II och kravet på "inga kända exploaterbara sårbarheter" enligt Bilaga I Del I, vilket är anledningen till att VEX är relevant för en CRA-regelföljande produkt. Ingen av dessa skyldigheter har en storleksgräns. SMF-företag har viss lättnad avseende påföljder för 24-timmarsfristen (se nedan) men är inte undantagna från rapportering.

ENISA Single Reporting Platform (SRP)

SRP är den enda kanalen genom vilken varje Artikel 14-anmälan flödar. Den finns till för att Artikel 14(1) kräver att tillverkaren anmäler simultant till den samordnande CSIRT och till ENISA, och 27 separata inlämningar vore ogenomförbart. Artikel 16(1) placerar plattformen under ENISA:s operativa ansvar: "den dagliga driften av den gemensamma rapporteringsplattformen ska skötas och underhållas av ENISA."

Hur det fungerar i praktiken:

• Du lämnar in en gång via det elektroniska slutpunkten hos den CSIRT som är utsedd som samordnare enligt Artikel 14(7).
• Inlämningen når simultant den samordnande CSIRT och ENISA.
• Den samordnande CSIRT sprider sedan anmälan vidare till CSIRT:er i övriga medlemsstater där din produkt säljs (art. 16). Det sekundära spridningssteget är CSIRT:ens ansvar, inte tillverkarens.
• Artikel 16(2) tillåter en CSIRT att fördröja vidare spridning i synnerligen exceptionella omständigheter. Artikel 16(6) tillåter fördröjning under samordnat sårbarhetssläpp med tillverkarens samtycke.

Status per maj 2026: SRP planeras vara i drift senast den 11 september 2026, enligt ENISA:s SRP-sida. Implementeringen upphandlades under ENISA/2025/OP/0001 (fyraårigt kontrakt) med anbudstidens utgång i mars 2025. Leverantörens identitet har inte offentliggjorts. Ingen registrerings-URL har publicerats. En testperiod förväntas; inga specifika datum har annonserats. Genomförandeakter enligt Artikel 14 om format och struktur för anmälningar var fortfarande under beredning vid tidpunkten för skrivandet.

Vad tillverkare bör göra nu: identifiera din samordnande CSIRT enligt Artikel 14(7), utarbeta och förhandsgodkänn rapportmallar för 24h-, 72h- och 14d-inlämningar, och definiera en jourrota dygnet runt. Mallar och processer kan inte tas fram medan 24-timmarsklockan tickar.

Rapporteringstidslinjer i detalj

Både sårbarheter och allvarliga incidenter följer en stegvis rapporteringsmodell. Klockorna skiljer sig åt på slutrapportledet.

Artikel 14 Rapporteringsschema

Steg	Sårbarhet (art. 14(2))	Allvarlig incident (art. 14(4))	Klockankare
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 en korrigerande eller riskreducerande åtgärd finns tillgänglig	1 månad efter 72-timmars incidentanmälan	Olika ankare för varje spår
Användarinformation	Utan onödigt dröjsmål	Utan onödigt dröjsmål	Per art. 14(8)

Vad varje inlämning innehåller

Tidig varning (24 timmar). Minimiinformation för att varna myndigheterna: tillverkarens identitet, berörd produkt och version, kortfattad beskrivning, inledande allvarlighetsbedömning, om exploatering är bekräftad eller misstänkt och en indikation på påverkans omfattning. Den tidiga varningen är en signal, inte en analys.

Detaljerad anmälan (72 timmar). Två separata skyldigheter gäller vid detta steg. 72-timmars sårbarhetsanmälan enligt Artikel 14(2)(b) avser aktivt utnyttjade sårbarheter. 72-timmars incidentanmälan enligt Artikel 14(4)(b) avser allvarliga incidenter. I båda fallen utvidgar inlämningen den tidiga varningen med tekniska detaljer, berörda versioner och konfigurationer, exploateringsmetod (om känd), aktuell åtgärdsstatus, tidsplan för åtgärd, känd användaromfattning och pågående samordning med andra parter.

Slutrapport. För sårbarheter börjar 14-dagarsfristen "senast 14 dagar efter att en korrigerande eller riskreducerande åtgärd finns tillgänglig" (art. 14(2)(c)), inte från detektering och inte från 72-timmarsanmälan. För allvarliga incidenter ankras 1-månadsfristens start till 72-timmars incidentanmälan enligt Artikel 14(4)(c). Slutrapporten täcker rotorsaksanalys, fullständig teknisk beskrivning, vidtagna åtgärder, implementerade förebyggande åtgärder och bekräftad konsekvensanalys.

1. Tillverkaren får kännedom. 24-timmarsklockan startar det ögonblick rimlig tro om aktiv exploatering bildas.
2. + 24 timmar. Tidig varning inlämnad via ENISA SRP (art. 14(2)(a)).
3. + 72 timmar. Detaljerad anmälan inlämnad med tekniska detaljer, berörda versioner och åtgärdsstatus (art. 14(2)(b)).
4. Korrigerande eller riskreducerande åtgärd tillgänglig. 14-dagarsfristens slutrapport börjar här, inte vid detektering.
5. + 14 dagar. Slutrapport inlämnad: rotorsak, fullständig teknisk beskrivning, åtgärd, bekräftad påverkan (art. 14(2)(c)).

Vad utlöser en rapporteringsskyldighet?

Artikel 14 täcker två utlösarkategorier.

1. Aktivt utnyttjade sårbarheter

En sårbarhet i din produkt som:

• är känd för dig (hittad internt eller rapporterad externt),
• har använts av en angripare, och
• påverkar, eller kan påverka, användarna av produkten.

CRA definierar en aktivt utnyttjad sårbarhet som en där "en angripare utnyttjar en brist." Det är inte samma sak som offentliggörande, ett publicerat proof-of-concept eller att en säkerhetsforskare demonstrerar utnyttjbarhet. Utlösaren är faktisk skadlig användning.

2. Allvarliga incidenter

Säkerhetsincidenter som påverkar produktens säkerhet, komprometterar utvecklingsmiljön på sätt som påverkar produktsäkerheten, orsakar utbredd driftstörning för användare eller leder till utbredd kompromittering.

Rapporteringspliktiga och icke-rapporteringspliktiga situationer

Situation	Rapporteringspliktig?	Varför
Säkerhetsforskare rapporterar sårbarhet privat	Nej	Inga exploateringsbevis; hantera via CVD
PoC publiceras på GitHub	Nej	Publicering är inte exploatering
Kund rapporterar aktivitet förenlig med sårbarheten	Ja	Tröskeln för rimlig tro uppnådd
Sårbarhet detekteras som utnyttjas i det vilda	Ja	Aktiv skadlig användning
Komponent i din SBOM har känd utnyttjad sårbarhet	Bedöm	Rapporteringspliktig bara om exploateringen påverkar din produkt (VEX är relevant här)
Din produkt attackeras specifikt av namngivna hotaktörer	Ja	Direkt exploateringsbevis
Generell skadlig kod utnyttjar en sårbarhetsklass din produkt har	Bedöm	Bara om din specifika implementation påverkas

Standarden "rimlig tro"

Forensiskt bevis på exploatering krävs inte. Artikel 14-standarden är rimlig tro baserat på tillgänglig information: ovanliga åtkomstmönster förenliga med kända exploateringstekniker, kundrapporter om kompromittering, hotinformation som pekar på att din produkt är utsatt eller detektering av exploateringskod riktad mot din produkt. Välj att rapportera vid osäkerhet. En förtidig tidig varning som visar sig obefogad är långt bättre än en missad frist för faktisk exploatering, och 72-timmarsanmälan kan uppdatera bedömningen.

Policy för samordnat sårbarhetssläpp (CVD): kopplingen till artikel 14

Bilaga I del II punkt 5 i CRA kräver att tillverkare "inför och tillämpar en policy för samordnad sårbarhetsredovisning". CVD-policyn är den operativa mekanism som omvandlar externa forskarrapporter till ett strukturerat triageflöde och, när aktiv exploatering konstateras under triage, startar artikel 14-rapporteringsklockan parallellt. Policyn är obligatorisk för varje produkt med digitala element; det finns ingen SMF-tröskel eller storleksgräns. Miniminivån för leverans är en offentlig URL plus en security.txt-fil under /.well-known/security.txt (RFC 9116), så att rapporterna är hittbara för de forskare som förordningen är utformad att kanalisera.

För själva CVD-policyn, inklusive obligatoriskt innehåll, konventioner för offentliggörandefönster, formuleringar om rättsligt skydd och kommunikationsmallar för forskare, se den dedikerade CRA-guiden för samordnad sårbarhetsredovisning. För hur CVD passar in bland de andra skyldigheterna i bilaga I del II (SBOM, åtgärdande, säkra uppdateringar, kostnadsfri leverans), se CRA hantering av sårbarheter. Den här sidan fokuserar på artikel 14:s rapporteringskadens som utlöses när triage bekräftar aktiv exploatering.

VEX: Kommunicera sårbarhetens tillämplighet

Bilaga I Del I kräver att CRA-produkter levereras utan kända exploaterbara sårbarheter och med säker standardkonfiguration. SBOM-skanning ger långa listor över CVE:er mot komponenter, varav de flesta inte faktiskt är exploaterbara i din specifika produkt. VEX (Vulnerability Exploitability eXchange) är mekanismen som omvandlar dessa råa skanningsresultat till en försvarbar "ej påverkad / påverkad / åtgärdad / under utredning"-position per CVE, vilket är vad förordningen, harmoniserade standarder under utveckling och tysk upphandling enligt BSI TR-03183 Del 3 förväntar sig.

Vad VEX är

VEX är ett strukturerat, maskinläsbart utlåtande om huruvida en sårbarhet i en komponent faktiskt påverkar en specifik produkt. Det svarar på: "CVE-XXXX finns i vår SBOM. Påverkar den vår produkt, varför eller varför inte, och vad bör användaren göra?" De fyra kärntillstånden är:

Tillstånd	Innebörd
not_affected	Sårbarheten finns i komponenten men påverkar inte den här produkten (sårbar kodsökväg nås ej, funktion anropas ej, konfiguration begränsar, etc.). 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	Status ännu inte fastställd; bedömning pågår.

Kopplingen till CRA

VEX namnges inte i CRA-texten, men är det operativa verktyget bakom tre av förordningens klausuler:

• Bilaga I Del I, inga kända exploaterbara sårbarheter. Ett not_affected VEX-utlåtande med dokumenterad motivering är beviset för att du utvärderat ett CVE och dragit slutsatsen att det inte är tillämpligt. Utan det är varje CVE i din SBOM en presumtiv ansvarsfråga.
• Bilaga I Del II, sårbarhetshantering. VEX är revisionsspåret för hur varje CVE förflyttats från under_investigation till not_affected, affected eller fixed över tid.
• Artikel 14, rapporteringsutlösare. En sårbarhet märkt som affected och känd att vara aktivt utnyttjad är exakt den utlösare som startar 24-timmarsklockan. En sårbarhet märkt som not_affected med välgrundad motivering är det inte.

VEX-format

Två format är praktiskt relevanta. CycloneDX VEX är inbäddat direkt i en CycloneDX SBOM under vulnerabilities[].analysis. CSAF VEX är ett separat dokument i CSAF 2.0 (det format BSI TR-03183 Del 3 kräver för säkerhetsrådgivningar och det format tyska CERT publicerar och konsumerar som standard). Båda är maskinläsbara och uppfyller samma operativa roll.

Ett minimalt CycloneDX VEX-påstående:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2027-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is not called in our implementation."
      },
      "affects": [{ "ref": "pkg:generic/openssl@3.0.12" }]
    }
  ]
}

CycloneDX 1.5-specifikationen definierar sex analysstatus (in_triage, exploitable, not_affected, false_positive, resolved, resolved_with_pedigree), ett finare ordförråd än OpenVEX:s fyra (not_affected, affected, fixed, under_investigation), vilket de avbildas mot. BSI TR-03183 Del 3 förväntar sig VEX-utlåtanden vid sidan av SBOM:er för CRA-anpassade produkter. För en fullständig bild av SBOM och BSI TR-03183, se SBOM-klusterguiden.

SMF-undantag och begränsade skyldigheter

Artikel 64(10) ger en begränsad lättnad avseende påföljder för de minsta tillverkarna. Det undantar ingen från rapportering.

Mikroföretag och småföretag (definierade som färre än 50 anställda och en årsomsättning eller balansomslutning upp till 10 miljoner euro; mikroföretag: färre än 10 anställda, 2 miljoner euro) är undantagna från böter specifikt för att missa 24-timmars tidiga varningsfrister enligt Artikel 14(2)(a) och Artikel 14(4)(a). Lättnaden täcker bara tidpunktssanktioner avseende 24-timmarsledet.

Fortfarande obligatoriskt, utan SMF-lättnad:

• 72-timmars detaljerad anmälan (art. 14(2)(b) och 14(4)(b)).
• 14-dagars slutrapport för sårbarheter och 1-månads slutrapport för allvarliga incidenter.
• CVD-policyn enligt Bilaga I Del II.
• Alla andra CRA-skyldigheter, inklusive kravet på "inga kända exploaterbara sårbarheter" enligt Bilaga I Del I.

Medelstora företag (upp till 250 anställda) täcks inte av SMF-lättnaden alls. Undantaget är en begränsad påföljdscarve-out, inte ett reducerat rapporteringsregim.

Vanliga misstag

• Vänta på forensisk säkerhet innan klockan startas. Artikel 14 tillämpar standarden rimlig tro. Att vänta på bevis missar fristen.
• Blanda ihop CVD med Artikel 14-rapportering. En forskarrapport är ett CVD-indata; Artikel 14-rapportering utlöses när det finns bevis på aktiv exploatering. CVD-policyn måste innehålla en explicit grindpunkt för detta.
• Enda kontaktpunkt som eskalering. En person behörig att rapportera, onåbar en fredagskväll. 24-timmarsklockan pausas inte.
• Första kontakten med den samordnande CSIRT under en incident. Etablera relationen och routingen nu, medan ingen klocka tickar.
• Ingen publicerad CVD-policy. Skyldigheten enligt Bilaga I Del II uppfylls inte av ett internt dokument.
• Inga VEX-påståenden. Varje CVE i din SBOM presumeras exploaterbar tills du säger annat. Bilaga I Del I är mycket svårare att försvara utan VEX.
• Att behandla SRP-lanseringen som ett framtida problem. Mallar, jourotor och CSIRT-relationer måste finnas på plats före september 2026, inte byggas efteråt.