Från och med den 11 september 2026 måste tillverkare av produkter med digitala element rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter enligt EU:s cyberresiliensförordning, Cyber Resilience Act (CRA). Den första rapporten ska in inom 24 timmar. Många räknar fortfarande med att CRA "kommer 2027", men just den här delen gäller redan. Den gäller dessutom för produkter som redan finns ute hos kunderna.
Den här artikeln går igenom vad rapporteringsplikten kräver, vilka tidsfrister som gäller och vart rapporterna ska skickas. Framför allt visar vi hur du bygger in den i din DevSecOps-kedja, så att 24-timmarsfristen blir en rutin och inte en panikövning.
Har du frågor om ämnet? Tveka inte att höra av dig till oss!
Det här är en teknisk genomgång och inte juridisk rådgivning. Om du är osäker på om din produkt omfattas, ta hjälp av en jurist. De juridiska uppgifterna är kontrollerade den 8 oktober 2026.
Vad har börjat gälla?
CRA är en EU-förordning, (EU) 2024/2847. Den trädde i kraft den 10 december 2024 och gäller direkt i Sverige utan att först föras in i svensk lag. Huvuddelen av kraven gäller från den 11 december 2027. Två delar gäller tidigare (artikel 71):
- 11 juni 2026: reglerna om anmälda organ (kapitel IV), alltså de som ska göra tredjepartsbedömningar.
- 11 september 2026: artikel 14, tillverkarnas rapporteringsskyldigheter.
Det som brukar överraska folk står i artikel 69.3. Rapporteringsplikten gäller även produkter som släpptes ut på marknaden före den 11 december 2027. Har du en produkt ute hos kunder i dag, och den omfattas av CRA, då gäller tidsfristerna redan för den.
Vem räknas som tillverkare?
Kort sagt den som utvecklar eller tillverkar en produkt med digitala element, eller låter någon annan göra det, och marknadsför den under eget namn eller varumärke. Det gäller både hårdvara och fristående programvara: appar, bokföringsprogram, agentprogramvara, firmware och kommersiellt distribuerad öppen källkod.
Enligt CERT-SE omfattas bland annat inte:
- icke-kommersiell öppen källkod,
- molntjänster och SaaS som inte tillhandahåller fjärrdatabehandling för en produkt (molntjänstleverantörer regleras i stället av cybersäkerhetslagen),
- produkter som utvecklats eller ändrats uteslutande för nationell säkerhet eller försvar, eller som är särskilt utformade för att behandla säkerhetsskyddsklassificerade uppgifter (art. 2.7),
- produkter som omfattas av egna EU-regler, till exempel medicinteknik och motorfordon.
Tidsfristerna: 24 timmar, 72 timmar, 14 dagar
Artikel 14 har två spår. Klockan startar när ni får kännedom om sårbarheten eller incidenten.
Aktivt utnyttjad sårbarhet (art. 14.2):
- Tidig varning senast 24 timmar: ange, om det är känt, i vilka medlemsstater produkten har tillhandahållits.
- Anmälan senast 72 timmar: produkten, utnyttjandets och sårbarhetens art, vidtagna åtgärder och vad användarna själva kan göra.
- Slutrapport senast 14 dagar efter att en rättelse eller riskreducerande åtgärd finns tillgänglig: beskrivning och allvarlighetsgrad, eventuell hotaktör och detaljer om säkerhetsuppdateringen.
Allvarlig incident som påverkar produktens säkerhet (art. 14.4):
- Tidig varning senast 24 timmar: ange åtminstone om ni misstänker olagliga eller fientliga handlingar, och i förekommande fall i vilka medlemsstater produkten har tillhandahållits.
- Incidentanmälan senast 72 timmar: incidentens art, en första bedömning och vidtagna åtgärder.
- Slutrapport inom en månad efter incidentanmälan: detaljerad beskrivning, trolig grundorsak och åtgärder.
Utöver detta kan den mottagande CSIRT-enheten begära delrapporter (art. 14.6). Ni ska också informera berörda användare om sårbarheten eller incidenten och om vad de kan göra, om det är lämpligt i ett strukturerat, maskinläsbart format (art. 14.8).
Två definitioner avgör om ni är skyldiga att rapportera:
- Aktivt utnyttjad sårbarhet (art. 3.42): det finns tillförlitliga bevis på att en fientlig aktör har utnyttjat sårbarheten i ett system utan ägarens tillstånd. En CVE med högt CVSS-värde räcker inte i sig. Det som avgör är att den faktiskt utnyttjas.
- Allvarlig incident (art. 14.5): incidenten påverkar, eller kan påverka, produktens förmåga att skydda tillgänglighet, autenticitet, riktighet eller konfidentialitet för känsliga eller viktiga data eller funktioner. Den räknas också som allvarlig om den har lett, eller kan leda, till att skadlig kod förs in i produkten eller i användarens system.
Vart skickas rapporten?
Rapporterna lämnas via ENISA:s gemensamma rapporteringsplattform (Single Reporting Platform, SRP). De går till den samordnande CSIRT-enheten i det land där ni har ert huvudsakliga verksamhetsställe och samtidigt till ENISA (art. 14.1 och 14.7). För svenska tillverkare är det CERT-SE som tar emot rapporterna. CERT-SE ingår sedan den 1 juli 2026 i Nationellt cybersäkerhetscenter (NCSC) vid FRA.
Enligt CERT-SE behöver du ett EU Login för att komma åt SRP. En organisation kan ha upp till 20 användare, och ärenden kan kompletteras efter hand. Registrera konton innan något händer. Klockan väntar inte på att lösenordet återställs.
Svensk kompletterande lag – status den 8 oktober 2026
CRA gäller direkt, men Sverige behöver kompletterande regler, bland annat om vilka myndigheter som ska utöva tillsyn och om sanktioner. I december 2025 lämnade Cyberresiliensutredningen sitt betänkande SOU 2025:115. Där föreslås en ny kompletterande lag, att Post- och telestyrelsen (PTS) blir marknadskontrollmyndighet och att Swedac blir anmälande myndighet. Utredningen föreslog också att MSB skulle ta emot rapporterna, men sedan dess har CERT-SE flyttats till NCSC vid FRA.
Betänkandet har remissbehandlats, och remisstiden gick ut den 22 april 2026. Den 8 oktober 2026 har regeringen inte lämnat någon proposition till riksdagen, och någon kompletterande lag har inte beslutats eller trätt i kraft (kontrollerat i riksdagens dokumentdatabas och på regeringen.se). Det påverkar inte rapporteringsplikten, som gäller direkt genom EU-förordningen.
Varför 24 timmar är svårare än det låter
Tänk dig att brandlarmet går klockan 16.45 en fredag. Det är inte själva larmet som avgör hur det går. Det avgörs av om alla vet var utgångarna finns, vem som ringer räddningstjänsten och om någon har nyckeln till ställverket. Rapporteringsplikten fungerar likadant. Formuläret i SRP är inte det svåra. Det svåra är att inom ett dygn kunna svara på frågorna:
- Vilka av våra produkter och versioner innehåller den sårbara komponenten?
- Var finns de? (I vilka medlemsstater har de tillhandahållits?)
- Utnyttjas sårbarheten aktivt, och hur vet vi det?
- Vem fattar beslutet att rapportera, och vem skickar in?
Kan ni inte svara på den första frågan inom en timme har ni ett SBOM-problem, inte ett rapporteringsproblem.
Så bygger du in rapporteringsplikten i DevSecOps
Rapporteringskraven i artikel 14 hänger ihop med kraven på sårbarhetshantering i bilaga I del II, som gäller fullt ut från december 2027. Det lönar sig att bygga båda samtidigt, eftersom det är samma maskineri.
1. En SBOM för varje release, sparad och sökbar
Bilaga I del II punkt 1 kräver en programvaruförteckning (SBOM) i ett allmänt använt, maskinläsbart format som minst täcker produktens viktigaste (top-level) beroenden. I praktiken betyder det:
- Generera SBOM (SPDX eller CycloneDX) automatiskt i CI för varje byggd artefakt, inte bara för "stora" releaser.
- Signera och attestera SBOM:en tillsammans med imagen eller binären, till exempel med Sigstore/Cosign, så att du kan bevisa vilken SBOM som hör till vilken leverans.
- Spara SBOM:er för alla versioner som finns ute hos kunder, inte bara den senaste. Det är de gamla versionerna som brukar ställa till det.
- Gör dem sökbara. "Vilka releaser innehåller paket X i version Y?" ska gå att besvara med en fråga, inte med en arkeologisk utgrävning.
2. Kontinuerlig skanning mot det som redan är levererat
Att skanna i pipelinen fångar nya problem i ny kod. CRA bryr sig också om det som redan är ute.
- Skanna lagrade SBOM:er och images (till exempel med Trivy) mot sårbarhetsdata varje dag, inte bara vid bygge.
- Bevaka listor över sårbarheter som utnyttjas aktivt, till exempel CISA:s KEV-katalog, och leverantörers säkerhetsbulletiner. Det är signalen som kan starta 24-timmarsklockan.
- Låt verktygen sortera och prioritera, men låt en människa bedöma om sårbarheten faktiskt är exploaterbar i er produkt. Dokumentera bedömningen, till exempel som VEX.
3. En tydlig startsignal och en jourkedja
- Bestäm vad "kännedom" betyder hos er: vilka källor och vilken roll som gör den första bedömningen.
- Ha en namngiven rapportansvarig med ersättare och behörighet i SRP.
- Ha färdiga mallar för tidig varning, anmälan och slutrapport, där fälten matchar artikel 14.
- Öva. En tabletop-övning per kvartal räcker långt.
4. Säkerhetsuppdateringar som går att leverera snabbt
Bilaga I del II kräver att sårbarheter åtgärdas utan dröjsmål. Den kräver också att nya säkerhetsuppdateringar, där det är tekniskt möjligt, levereras separat från funktionsuppdateringar, och att de distribueras säkert och, om inget annat avtalats för en skräddarsydd produkt, utan kostnad (punkterna 2, 7 och 8). För produktteamet innebär det:
- En releasekanal för säkerhetsfixar som inte väntar på nästa feature-release.
- Stödgrenar för de versioner som omfattas av er stödperiod. Enligt artikel 13.8 ska den vara minst fem år, om produkten inte förväntas användas kortare tid än så.
- Signerade uppdateringar och en dokumenterad distributionsväg.
5. Kommunikation och samordnad delgivning
- Publicera en policy för samordnad delgivning av sårbarheter (CVD) och en kontaktadress för sårbarhetsrapporter (punkterna 5–6).
- Publicera säkerhetsmeddelanden om åtgärdade sårbarheter (punkt 4), gärna i maskinläsbart format som CSAF.
- Hittar ni en sårbarhet i en tredjepartskomponent, även i öppen källkod, ska ni rapportera den till den som underhåller komponenten (art. 13.6).
6. Bevis som skapas av sig själva
Varje steg ovan lämnar spår: SBOM-arkivet, skanningshistorik, ärenden med bedömningar, releaseloggar och rapporterna i SRP. Det är samma underlag som en marknadskontrollmyndighet kan begära in, och samma underlag som era kunder kommer att fråga efter i upphandlingar. AI-verktyg kan med fördel sammanställa underlaget och skriva första utkastet till rapporten. Beslutet att rapportera och innehållet i rapporten ska ändå alltid granskas och godkännas av en människa.
Vad händer om man missar?
Enligt artikel 64.2 kan brister mot bilaga I eller artiklarna 13–14 ge administrativa sanktionsavgifter på upp till 15 miljoner euro eller 2,5 procent av den globala årsomsättningen, beroende på vilket belopp som är högst. Reglerna om sanktioner ska fastställas av varje medlemsstat (art. 64.1). I Sverige är de kompletterande reglerna ännu inte beslutade (se avsnittet om status ovan). Artikel 64.10 innehåller två undantag:
- Mikroföretag och små företag får inte sanktionsavgift för att de missat själva 24-timmarsfristen för den tidiga varningen.
- Förvaltare av öppen källkod får inte sanktionsavgifter alls.
Det som sannolikt kostar mest är ändå inte avgiften. Det är att stå utan svar när en stor kund frågar om ni påverkas.
CRA och cybersäkerhetslagen – två klockor samtidigt
Har ni en produkt som omfattas av CRA och samtidigt driver en verksamhet som omfattas av cybersäkerhetslagen (2025:1506), till exempel som molnleverantör eller leverantör av IKT-tjänster, kan samma händelse sätta igång två rapporteringskedjor. Vid en betydande incident ska ni enligt cybersäkerhetslagen lämna en upplysning senast 24 timmar efter att ni fått kännedom om den. En incidentanmälan ska lämnas senast 72 timmar efter kännedom och en slutrapport senast en månad efter incidentanmälan (2 kap. 5–8 §§). Planera för båda i samma incidentrutin. Läs mer om hur vi arbetar med NIS2 och CRA.
Sammanfattning
- Rapporteringsplikten enligt CRA gäller sedan 11 september 2026, även för produkter som redan finns på marknaden.
- Tidsfristerna är 24 h (tidig varning), 72 h (anmälan) och 14 dagar (slutrapport för sårbarhet) eller en månad (slutrapport för incident).
- Rapporter skickas via ENISA:s SRP till CERT-SE. Skaffa EU Login och registrera användare i förväg.
- Den svenska kompletterande lagen (SOU 2025:115) är inte beslutad den 8 oktober 2026, men det påverkar inte rapporteringsplikten.
- Det svåra är att veta vad som påverkas, inte att fylla i formuläret. Det löser du med SBOM per release, kontinuerlig skanning, en tydlig jourkedja och en snabb releasekanal för säkerhetsfixar.
Du ska prioritera det här nu om:
- ni säljer programvara eller uppkopplad hårdvara i EU,
- ni inte kan säga vilka releaser som innehåller en viss komponent inom en timme,
- ingen hos er har ett EU Login för SRP i dag.
Vanliga frågor
Gäller CRA redan, eller först 2027? Rapporteringsplikten i artikel 14 gäller sedan den 11 september 2026. Resten av kraven, bland annat de väsentliga cybersäkerhetskraven och CE-märkningen, gäller från den 11 december 2027.
Måste vi rapportera alla sårbarheter vi hittar? Nej. Det obligatoriska gäller aktivt utnyttjade sårbarheter och allvarliga incidenter. Övriga sårbarheter kan rapporteras frivilligt (art. 15). De ska ändå åtgärdas enligt bilaga I del II.
Vart skickar en svensk tillverkare rapporten? Till ENISA:s Single Reporting Platform. Därifrån går den till CERT-SE och samtidigt till ENISA.
Vilken myndighet utövar tillsyn i Sverige? Det är inte beslutat ännu. SOU 2025:115 föreslår att PTS blir marknadskontrollmyndighet. Den 8 oktober 2026 har ingen proposition lämnats till riksdagen.
Omfattas vår SaaS-tjänst? Enligt CERT-SE omfattas inte SaaS och molntjänster som inte tillhandahåller fjärrdatabehandling för en produkt. De kan i stället omfattas av cybersäkerhetslagen. Agenter, appar och klientprogram som ni levererar kan däremot vara produkter med digitala element.
Vilket SBOM-format ska vi använda? CRA kräver ett "allmänt använt och maskinläsbart format". I praktiken är det SPDX eller CycloneDX. Kommissionen får specificera formatet närmare genom genomförandeakter (art. 13.24), så håll koll på det.
Vi är ett litet bolag. Gäller det oss? Ja, kraven gäller oavsett storlek. Mikroföretag och små företag slipper sanktionsavgift för en missad 24-timmarsfrist, men 72-timmarsanmälan och slutrapporten gäller fullt ut.
Vill du ha hjälp att bygga en DevSecOps-kedja som klarar CRA?
Vi bygger säkra CI/CD-kedjor med SBOM, signering, skanning och policyer, och vi hjälper till med GAP-analys mot CRA och NIS2. Kontakta oss för offert eller ett första samtal.
Läs mer på:
Källor
Alla kontrollerade 2026-10-08.
- Europaparlamentets och rådets förordning (EU) 2024/2847 av den 23 oktober 2024 (Cyber Resilience Act), EUT L, 20.11.2024. Artiklarna 3.42, 13.6, 13.8, 13.24, 14, 15, 64, 69.3 och 71 samt bilaga I del II. eur-lex.europa.eu/eli/reg/2024/2847/oj
- CERT-SE, "Rapporteringsplikt enligt CRA". cert.se/cyberresilienceact
- NCSC, "Så här fungerar cyberresiliensförordningen". ncsc.se
- NCSC, "Cyberverksamheten samlad hos FRA" (CERT-SE i FRA från 2026-07-01). ncsc.se
- SOU 2025:115, Kompletterande bestämmelser till EU:s cyberresiliensförordning. riksdagen.se
- Regeringskansliet, Remiss av SOU 2025:115 (Fi2026/00065, sista svarsdag 2026-04-22). regeringen.se
- Cybersäkerhetslag (2025:1506), 2 kap. 5–8 §§, i kraft 2026-01-15. riksdagen.se
- Cybersäkerhetsförordning (2025:1507) i lydelse enligt SFS 2026:623 (FRA som CSIRT-enhet). riksdagen.se
