Ja. Den 11 september 2026 inträffar en viktig delstart för Cyber Resilience Act (CRA), förordning (EU) 2024/2847. Från det datumet börjar artikel 14 om tillverkares rapporteringsskyldighet att tillämpas, trots att huvuddelen av CRA börjar gälla först den 11 december 2027. (eur-lex.europa.eu)

Det innebär att företag som är tillverkare av produkter med digitala element redan från den 11 september måste ha en fungerande incident- och sårbarhetsprocess.

Vad måste rapporteras?

Det är viktigt att skilja CRA från exempelvis NIS2. Alla säkerhetsincidenter och alla sårbarheter ska inte CRA-rapporteras. Två kategorier är obligatoriska:

1. Aktivt utnyttjad sårbarhet – en sårbarhet i en produkt där det finns tillförlitliga belägg för att en illvillig aktör faktiskt har utnyttjat sårbarheten utan systemägarens tillstånd.
2. Allvarlig incident som påverkar produktens säkerhet – en incident med allvarlig påverkan på produktens förmåga att skydda tillgänglighet, autenticitet, integritet eller konfidentialitet. (eur-lex.europa.eu)

Det betyder exempelvis att en CVE i en komponent ni använder inte automatiskt innebär rapporteringsskyldighet. Frågan är bland annat om sårbarheten finns i er produkt och om den är aktivt exploaterad.

Tidsfristerna

När företaget får kännedom om en rapporteringspliktig händelse börjar klockan gå:

24-timmarsrapporten är alltså en tidig varning. Företaget behöver inte ha gjort en fullständig teknisk analys innan den lämnas. (digital-strategy.ec.europa.eu)

Vart ska rapporteringen göras?

Här har det skett en viktig konkretisering under sommaren.

Rapporteringen ska göras genom ENISA:s CRA Single Reporting Platform (SRP). ENISA uppger nu uttryckligen att plattformen ska vara operativ från 11 september 2026. Tillverkaren skickar rapporten elektroniskt via SRP och väljer relevant nationell CSIRT designated as coordinator. (enisa.europa.eu)

ENISA – CRA Single Reporting Platform

Det är alltså inte tänkt att ett svenskt företag först ska rapportera separat till ENISA och sedan skicka samma CRA-rapport till svensk myndighet. Rapporteringen sker en gång genom SRP.

Plattformen gör rapporten tillgänglig för relevant nationell CSIRT och ENISA och informationen kan därefter distribueras till andra berörda CSIRT:er. (digital-strategy.ec.europa.eu)

För ett företag med huvudsaklig etablering i Sverige blir den svenska CRA-koordinatorn relevant. CRA bestämmer huvudsaklig etablering primärt utifrån var besluten om produkternas cybersäkerhet huvudsakligen fattas, inte enbart var bolaget är registrerat. Om detta inte går att avgöra används i nästa steg den etablering i EU som har flest anställda. (eur-lex.europa.eu)

Den svenska utredningen har föreslagit att MSB ska vara den myndighet som tar emot rapporterna enligt CRA. (regeringen.se)

En viktig detalj inför den 11 september

Rapporteringsskyldigheten omfattar inte bara produkter som släpps ut på marknaden efter 11 september. CRA:s rapporteringsregler kan även träffa produkter som redan har gjorts tillgängliga på EU-marknaden. (digital-strategy.ec.europa.eu)

Däremot anger ENISA:s aktuella vägledning att skyldigheten inte innebär att man den 11 september retroaktivt ska börja rapportera alla aktivt exploaterade sårbarheter som företaget redan kände till före rapporteringsreglernas ikraftträdande. (enisa.europa.eu)

Vad jag skulle se till att ett svenskt teknikföretag har klart före 11 september

Ni bör framför allt ha en intern process som snabbt kan gå från:

Upptäckt → bedömning → CRA-beslut → 24 h-rapport → 72 h-rapport → åtgärd → slutrapport

Den kritiska interna frågan bör vara:

1. Berör händelsen en produkt med digitala element som vi är tillverkare av?
↓ Ja
2. Är det en sårbarhet eller säkerhetsincident?
↓
3A. Sårbarhet: finns tillförlitliga belägg för aktiv exploatering?
→ Ja → CRA-rapportering

3B. Incident: uppfyller incidenten kriterierna för en severe incident having an impact on the security of the product?
→ Ja → CRA-rapportering

↓
4. Starta 24-timmarsfristen från tidpunkten då företaget anses ha blivit medvetet om händelsen.
↓
5. Rapportera via CRA Single Reporting Platform.
↓
6. Komplettera inom 72 timmar.
↓
7. Slutrapport enligt respektive tidsfrist.

Det här gör frågan om "awareness" – när tillverkaren juridiskt anses ha blivit medveten om händelsen – mycket viktig. Det räcker därför inte att bara ge CISO eller säkerhetschefen instruktioner. Support, utveckling, SOC, PSIRT, produktägare och andra som kan få information om en exploatering måste veta hur informationen omedelbart eskaleras.

För er typ av verksamhet skulle jag dessutom bygga processen så att samma händelse parallellt prövas mot CRA och NIS2/Cybersäkerhetslagen, eftersom en och samma cyberhändelse potentiellt kan skapa rapporteringsskyldighet enligt båda regelverken.

Jag kan ta fram en svensk praktisk CRA-rutin för användning från 11 september 2026, inklusive beslutsflöde, 24/72-timmarsprocess, ansvarsmatris och en intern CRA-rapporteringsblankett anpassad till ENISA SRP.

ja ta fram en rutin

Absolut. Nedan är en praktisk rutin som ni kan införa direkt. Jag har utgått från CRA artikel 14, kommissionens aktuella vägledning från juli 2026 och ENISA:s SRP-vägledning, senast uppdaterad i augusti 2026. Rapporteringsskyldigheten börjar gälla 11 september 2026. (ENISA)

Rutin – rapportering enligt Cyber Resilience Act (CRA)

Dokumentägare: Informationssäkerhetschef/CISO
Gäller från: 11 september 2026
Rättslig grund: Förordning (EU) 2024/2847, särskilt artikel 14–16
Omfattning: Produkter med digitala element som organisationen tillverkar och gör tillgängliga på EU-marknaden.

1. Syfte

Rutinen säkerställer att organisationen identifierar, bedömer, eskalerar och rapporterar sådana sårbarheter och säkerhetsincidenter som omfattas av CRA inom föreskrivna tidsfrister.

Från 11 september 2026 ska tillverkare rapportera:

• aktivt utnyttjade sårbarheter, och
• allvarliga incidenter som påverkar säkerheten hos en produkt med digitala element.

Rapportering sker genom ENISA:s CRA Single Reporting Platform (SRP). (ENISA)

2. Ansvar

Följande ansvar bör fastställas internt.

Minst två personer bör kunna genomföra rapportering i SRP, så att sjukdom, semester eller annan frånvaro inte äventyrar 24-timmarsfristen.

ENISA:s SRP använder rollen Assigned Representative (AR) och stöder Primary respektive Secondary/Backup AR. Autentisering sker via EU Login. (ENISA)

3. När processen ska startas

CRA-bedömningen ska omedelbart startas när organisationen får information om exempelvis en möjlig exploatering av en sårbarhet, intrång mot en produkt, information från kund eller forskare, CERT/CSIRT-information, CVE, leverantörsinformation, information om exploatering av en tredjepartskomponent eller upptäckt genom intern säkerhetsövervakning.

Viktigt: intern utredning får inte innebära att rapporteringen fördröjs tills alla fakta är kända. 24-timmarsfristen räknas från att tillverkaren blivit medveten om den rapporteringspliktiga händelsen. (Digital Strategy EU)

4. Beslutsflöde

Använd följande flöde vid varje potentiell produktsäkerhetshändelse:

Information om sårbarhet eller incident

                 │

                 ▼

 Berör händelsen en produkt med

 digitala element som omfattas av CRA?

          │              │

         NEJ            JA

          │              │

          ▼              ▼

 Dokumentera       Sårbarhet eller incident?

 beslutet             │           │

                  SÅRBARHET    INCIDENT

                      │           │

                      ▼           ▼

                Finns till-    Är incidenten

                förlitliga     allvarlig enligt

                belägg för     CRA art. 14(5)?

                aktivt             │

                utnyttjande?       │

                  │    │          │    │

                 NEJ  JA         NEJ  JA

                  │    │          │    │

                  ▼    └────┐     ▼    │

              Dokumentera   │ Dokumentera

                            │          │

                            ▼          ▼

                      RAPPORTERINGSPLIKT

                            │

                            ▼

                    Starta CRA-process

                            │

                 ┌──────────┼───────────┐

                 ▼          ▼           ▼

               ≤24 h      ≤72 h     Slutrapport

                 │          │           │

                 └──────────┴───────────┘

                            │

                            ▼

                       ENISA SRP

5. Bedömning av aktivt utnyttjad sårbarhet

En sårbarhet ska inte rapporteras enbart därför att den existerar.

Rapporteringsskyldigheten aktualiseras när det finns tillförlitliga belägg för att en illvillig aktör har utnyttjat sårbarheten. (ENISA)

Bedömningen ska därför dokumentera:

A. Finns sårbarheten i vår produkt?

B. Vilka produktversioner är berörda?

C. Finns tillförlitliga belägg för faktisk exploatering?

D. Är exploateringen relevant för vår produkt/konfiguration?

Exempel:

Ett bibliotek i produkten får CVE med CVSS 9,8.

Detta innebär inte automatiskt CRA-rapportering.

Men:

CVE:n finns i vår produkt och det finns tillförlitliga uppgifter om att angripare aktivt exploaterar sårbarheten.

Detta ska omedelbart eskaleras för CRA-rapportering.

6. Bedömning av allvarlig incident

En incident är rapporteringspliktig om den har en allvarlig påverkan på säkerheten hos produkten.

CRA artikel 14(5) anger kriterier för denna bedömning. Bland annat ska incidenten betraktas som allvarlig om den negativt påverkar eller kan påverka produktens förmåga att skydda bland annat:

• tillgänglighet,
• autenticitet,
• integritet eller
• konfidentialitet

på ett sätt som exempelvis kan leda till införande eller exekvering av skadlig kod eller påverka andra produkter eller nätverks- och informationssystem. (ENISA)

Bedömningen och skälen för beslutet ska dokumenteras även när slutsatsen är att händelsen inte är rapporteringspliktig.

7. Rapportering

När rapporteringsplikt konstaterats ska rapportering ske genom:

ENISA – CRA Single Reporting Platform (SRP)

ENISA – Single Reporting Platform

Tillverkaren väljer där relevant CSIRT Designated as Coordinator (CDaC). Rapporten blir samtidigt tillgänglig för ENISA, och mottagande CSIRT hanterar vidare spridning enligt CRA. (ENISA)

Det innebär att organisationens interna rutin bör säga:

CRA-rapportering ska göras genom ENISA CRA Single Reporting Platform (SRP).

och inte exempelvis:

"Rapportera CRA-incidenten till MSB via MSB:s incidentformulär."

Det senare riskerar att blandas ihop med rapporteringsprocessen enligt NIS2/Cybersäkerhetslagen.

8. 24-timmarsrapport – Early Warning

Rapportering ska ske utan onödigt dröjsmål och senast inom 24 timmar efter att organisationen blivit medveten om händelsen. (Digital Strategy EU)

Rapporten ska utifrån då tillgänglig information bland annat identifiera den berörda produkten och ge en första beskrivning av händelsen.

Organisationen ska inte vänta på fullständig teknisk utredning.

Internt mål:

CRA Early Warning ska vara inskickad senast 20 timmar efter fastställd awareness-tidpunkt.

Det ger fyra timmars säkerhetsmarginal.

9. 72-timmarsrapport

Senast 72 timmar efter awareness ska en mer fullständig rapport lämnas. (Digital Strategy EU)

Den interna utredningen ska därför prioritera att fastställa bland annat:

• berörd produkt,
• produktversion,
• sårbarhet/CVE om sådan finns,
• attackvektor,
• exploateringssätt,
• omfattning,
• berörda kunder/användare,
• geografisk spridning,
• teknisk påverkan,
• säkerhetskonsekvenser,
• vidtagna åtgärder,
• planerade åtgärder,
• patch/workaround,
• eventuell påverkan på andra produkter.

10. Slutrapport

Aktivt utnyttjad sårbarhet

Slutrapport ska lämnas senast 14 dagar efter att en korrigerande eller riskreducerande åtgärd finns tillgänglig. (Digital Strategy EU)

Rapporten ska bland annat beskriva sårbarheten, dess allvarlighetsgrad och påverkan samt den korrigerande eller riskreducerande åtgärden.

Allvarlig incident

Slutrapport ska lämnas senast en månad efter 72-timmarsrapporten. (Digital Strategy EU)

Rapporten ska sammanfatta incidenten, dess allvarlighetsgrad och påverkan samt grundorsak och genomförda åtgärder.

11. Intern tidslinje

Jag rekommenderar följande skarpare interna SLA:

12. Intern CRA-incidentblankett

Varje ärende bör omedelbart registreras med åtminstone följande uppgifter:

CRA-ärendenummer:
Datum/tid för upptäckt:
Datum/tid för awareness (T0):
Rapporterat internt av:
Ansvarig incidentledare:
Produkt:
Produktversion:
Berörda komponenter:
Sårbarhet/CVE:
Typ: ☐ Sårbarhet ☐ Incident

Aktivt utnyttjad sårbarhet?
☐ Ja ☐ Nej ☐ Under utredning

Tillförlitliga belägg för exploatering:

Allvarlig incident enligt CRA?
☐ Ja ☐ Nej ☐ Under utredning

Motivering:

CRA-rapporteringspliktig:
☐ Ja ☐ Nej

Beslut fattat av:
Datum/tid:

Early Warning skickad:
Datum/tid: __________

72-timmarsrapport skickad:
Datum/tid: __________

Slutrapport skickad:
Datum/tid: __________

ENISA SRP referensnummer:

13. Parallell bedömning mot NIS2/Cybersäkerhetslagen

CRA-bedömningen ska inte ersätta annan incidentbedömning.

För varje allvarligare händelse bör därför följande kontroll göras:

CRA? → Produktperspektivet

NIS2/Cybersäkerhetslagen? → Verksamhets-/tjänsteperspektivet

GDPR? → Personuppgiftsincident

Säkerhetsskydd? → Säkerhetsskyddsincident

En händelse kan omfattas av flera regelverk samtidigt. CRA-rapporteringen genom SRP innebär därför inte automatiskt att organisationens övriga rapporteringsskyldigheter är uppfyllda.

14. Förberedelser som ska vara klara före 11 september

Jag skulle prioritera följande innan ikraftträdandet:

1. Utse Primary och Backup Assigned Representative för CRA SRP.
2. Säkerställ EU Login och åtkomst till SRP. ENISA har redan publicerat särskild registreringsvägledning. (ENISA)
3. Fastställ vem som får fatta beslut om CRA-rapportering.
4. Upprätta kontaktväg support → PSIRT/CISO.
5. Inför 24/7-eskalering för potentiellt rapporteringspliktiga händelser.
6. Upprätta produktregister med produkt, version, supportperiod, produktägare och relevanta komponenter.
7. Koppla SBOM/CVE-hantering till CRA-processen.
8. Öva ett scenario där en aktivt exploaterad sårbarhet upptäcks fredag kl. 16:00. 24-timmarsfristen tar inte helg.
9. Testa att både ordinarie och backup-person kan genomföra SRP-processen.
10. Dokumentera varje beslut om rapportering/icke rapportering.

ENISA har nu publicerat konkret användarvägledning för både registrering, gränssnitt och hur en AEV (Actively Exploited Vulnerability) respektive SI (Severe Incident) lämnas och uppdateras i SRP. (ENISA)

Min rekommendation är därför att göra denna rutin till en del av er befintliga incidenthantering, inte skapa ett helt separat CRA-spår. Incidentprocessen bör få en tidig "regulatory assessment" där CRA, NIS2, GDPR och eventuellt säkerhetsskydd prövas parallellt.

EU-kommissionen – CRA Reporting Obligations
ENISA – CRA SRP FAQ, uppdaterad 31 augusti 2026
ENISA – instruktion för att lämna CRA-rapport i SRP