Kort version

CRA gör cybersäkerhet till en produktsäkerhetsfråga — CE-märkning, konformitetsbedömning och livscykelansvar. Nästan all hårdvara som kommunicerar och kommersiell programvara omfattas. Tre datum att planera kring: 11 juni 2026 (regler om anmälda organ), 11 september 2026 (sårbarhetsrapportering till ENISA) och 11 december 2027 (fullständig tillämpning med CE-märkningskrav). Den som säljer produkter med digitala element på EU-marknaden utan SBOM (Software Bill of Materials — en maskinläsbar förteckning över alla programvarukomponenter), definierad supportperiod och en kanal för säkerhetsrapporter kommer inte att kunna CE-märka efter december 2027.

September 2026 — sårbarhetsrapportering

Sårbarhetsrapportering är det första operativa kravet. Från 11 september 2026 ska tillverkaren rapportera aktivt utnyttjade sårbarheter till ENISA inom 24 timmar (tidig varning) och 72 timmar (uppföljning). Det förutsätter att bolaget har:

  • En intern process för att identifiera och triagera sårbarheter i realtid — inte bara i egen kod utan i alla open source-beroenden.
  • En extern rapporteringskanal där säkerhetsforskare kan skicka in upptäckter. Standarden är security.txt i webbdomänens rot, men kanalen måste bemannas.
  • En beslutsgång som klarar 24-timmarskravet. Det går inte att köra sårbarhetsrapportering genom ordinarie incidenthantering om den har 48 timmars SLA.

Tre klasser — och de flesta hamnar i fel fack

CRA delar in produkter i tre klasser med stigande krav:

  • Default. Majoriteten av produkter. Intern konformitetsbedömning räcker. Men intern betyder inte informell — dokumentationskraven är omfattande.
  • Important (klass I och II). Utpekade kategorier i bilaga III: brandväggar, lösenordshanterare, VPN-produkter, industriella styrsystem med flera. Anmält organ krävs i vissa fall. Många bolag har inte klassificerat sin portfölj och vet inte om de hamnar här.
  • Critical. Smarta mätare, HSM-moduler och vissa säkerhetskomponenter. Kräver europeiskt cybersäkerhetscertifikat.

Det vanligaste misstaget är att anta att alla egna produkter hamnar i default-klassen. En router med VPN-funktion är inte default. Ett industriellt styrsystem är inte default. Klassificeringen avgör om bolaget behöver ett anmält organ — och de organen har begränsad kapacitet.

SBOM och supportperiod — operativa grundkrav

Varje produkt ska ha en Software Bill of Materials som möjliggör sårbarhetsspårning. SBOM bör genereras automatiskt i CI/CD-pipelinen vid varje build — manuella listor blir omedelbart inaktuella.

Supportperioden ska vara minst fem år eller produktens förväntade användningstid, beroende på vilket som är längst. Den ska kommuniceras tydligt till kunden före köp. Marknadsföring som lovar fem års stöd men levererar tre års patchar blir en tillsynsfråga.

Vad bolag bör göra

  1. Klassificera produktportföljen mot bilaga III nu. Gå igenom varje produktfamilj: default, important klass I, important klass II eller critical? Dokumentera beslutet. Om en produkt hamnar i important eller critical, kontakta anmält organ redan under 2026.
  2. Bygg sårbarhetsrapporteringskanalen före september 2026. Publicera security.txt, sätt upp intern triagering med 24-timmars eskalering, och testa flödet med en simulerad sårbarhet.
  3. Automatisera SBOM-generering. Integrera i CI/CD-pipelinen så att varje build producerar en maskinläsbar SBOM (CycloneDX eller SPDX). Manuella listor klarar inte kraven.
  4. Definiera och publicera supportperioden per produktfamilj. Stäm av med produktledning och marknadsföring att det som kommuniceras till kund matchar det faktiska patchningsåtagandet.
  5. Granska open source-beroendena. Kommersiellt stöd för open source (betald support, inbäddning i kommersiell produkt) kan trigga CRA-krav uppströms. Identifiera vilka beroenden som har kommersiella kopplingar och bedöm ansvarskedjan.

Källor