Cyber Resilience Act 2027, vad det betyder och vad du behöver göra nu

Den korta sammanfattningen

CRA (EU 2024/2847) reglerar produkter med digitala element som säljs in på EU-marknaden, oavsett om de är hårdvara, mjukvara eller en kombination. Den gör säkerhet till en CE-märkningsfråga, precis som maskinsäkerhet eller EMC. När den blir fullt tillämplig 2027 får du inte sälja en sårbar produkt på EU-marknaden lagligt.

Två datum du måste ha i huvudet:

• 11 september 2026 — sårbarhets­rapportering enligt artikel 14 börjar gälla. Aktivt utnyttjade sårbarheter och allvarliga incidenter ska rapporteras till ENISA och nationell CSIRT inom 24 timmar.
• 11 december 2027 — full tillämplighet. Alla väsentliga säkerhetskrav, CE-märkning, dokumentation, SBOM, support-period m.m. gäller.

Sanktionerna är inte symboliska. Brott mot väsentliga säkerhetskrav kan ge upp till 15 miljoner euro eller 2,5 % av global årsomsättning, beroende på vad som är högst.

Vilka produkter omfattas?

Allt med digitala element som är avsett att kopplas till ett annat system eller nätverk. I praktiken:

• Konsument-IoT (smarta lampor, kameror, klockor, leksaker)
• Industriell IoT, sensorer, PLC, edge-enheter
• Routrar, switchar, lagring
• Operativsystem och firmware
• Bibliotek, ramverk och utvecklarverktyg som distribueras kommersiellt
• Mjukvara som installeras lokalt (kontorsapplikationer, ERP-klienter, branschsystem)

Och flera typer som ofta missas:

• Mobila appar som distribueras av en kommersiell utvecklare
• Säkerhetsprodukter (AV, EDR, brandväggar — paradoxalt nog)
• Krypterings­produkter

Vad är inte med?

• Rena SaaS-tjänster — täcks av andra regelverk (NIS2, DORA, GDPR). Men om SaaS-tjänsten kommer med en klient eller agent som installeras lokalt, så omfattas klienten.
• Open source som inte är kommersiellt distribuerad — om projektet inte ger ekonomisk vinst för utvecklaren ligger det utanför. "Open source stewards" får lättare obligationer.
• Produkter redan reglerade specifikt av t.ex. medicinteknik-, fordons- eller luftfartsregelverk.
• Begagnad försäljning mellan privatpersoner.

Tidslinjen i detalj

10 december 2024 — kraftträdande

Förordningen blev formellt EU-rätt. Inga obligationer ännu, men klockan börjar ticka.

11 juni 2026 — anmälda organ börjar utses

Notified Bodies som kommer att utföra tredjepartsbedömningar för Class II- och kritiska produkter måste vara på plats innan det är meningsfullt att försöka få sin produkt certifierad. Räkna med köer.

11 september 2026 — sårbarhetsrapportering

Detta är det första datum som faktiskt påverkar daglig drift:

• 24 timmar efter upptäckt: tidig varning till ENISA + nationell CSIRT om en aktivt utnyttjad sårbarhet eller en allvarlig incident med säkerhetspåverkan
• 72 timmar: uppdaterad rapport med tillgängliga detaljer
• 14 dagar (sårbarhet) / 1 månad (incident): slutgiltig rapport med åtgärder, root cause, lessons learned

24 timmar är en ny verklighet. Om din PSIRT inte är bemannad utanför kontorstid är detta första saken att lösa.

11 december 2027 — full tillämplighet

Allt annat slår in. Produkter som introduceras på marknaden efter detta datum måste uppfylla alla väsentliga krav. Produkter som redan är på marknaden måste få säkerhetsuppdateringar under hela den förväntade livslängden, dock minst fem år.

De väsentliga säkerhetskraven (bilaga I)

CRA listar krav på två nivåer.

Produktegenskaper:

• Levereras utan kända utnyttjbara sårbarheter
• Säker default-konfiguration vid driftsättning
• Skydd mot obehörig åtkomst (autentisering, sessionshantering, åtkomst­kontroll)
• Skydd av lagrad och överförd data (kryptering där relevant)
• Skydd av integritet hos kod, konfiguration och data
• Minimal angreppsyta (inga onödiga tjänster, portar, gränssnitt)
• Skydd mot DoS, eller åtminstone resiliens
• Loggning av säkerhetsrelevanta händelser
• Möjlighet till säkra uppdateringar, gärna automatiska
• Möjlighet att radera personuppgifter och konfiguration vid avveckling

Sårbarhets­hantering:

• Identifiera och dokumentera komponenter via SBOM
• Adressera sårbarheter via säkerhetsuppdateringar utan dröjsmål
• Återkommande tester och granskningar
• Publicera information om åtgärdade sårbarheter
• Tillhandahålla samordnad sårbarhets­hanterings­policy (vulnerability disclosure)
• Underlätta tredjepartsrapportering via t.ex. security.txt

Det är här penetrationstest och kontinuerlig scanning blir relevant. CRA säger inte "kör pentest", men "återkommande tester och granskningar" är hur du visar att du faktiskt verifierar säkerheten istället för att bara hävda att den finns.

Vilken klass hamnar min produkt i?

Tre nivåer styr hur strikt bedömningen blir:

• Standardprodukter — självbedömning räcker. Majoriteten av mjukvara hamnar här.
• Viktiga produkter, klass I (bilaga III) — självbedömning eller harmoniserad standard. Exempel: password managers, antivirus, browser, public key infrastructure, identity management.
• Viktiga produkter, klass II — tredjepartsbedömning krävs. Exempel: firewalls, IDS/IPS, säkra mikroprocessorer, smartcards, HSM.
• Kritiska produkter (bilaga IV) — full tredjepartsbedömning, ev. obligatorisk EU-certifiering. Hardware Security Modules, smart kortenheter, säkra element.

Som mjukvaru­leverantör kommer du sannolikt vara standardprodukt eller Class I. Som tillverkare av nätverks- eller säkerhets­utrustning bör du räkna med Class II direkt.

SBOM, det första du borde fixa

Software Bill of Materials är pratet på alla CRA-konferenser av en anledning: utan SBOM kan du inte uppfylla flera av kraven samtidigt.

Konkret behöver du:

• En SBOM per släppt produktversion, helst i SPDX eller CycloneDX
• Pipeline som genererar den vid build, inte i efterhand
• Process för att matcha komponenter mot CVE-feeds (NVD, GHSA, OSV)
• Bevarad SBOM-historik i lika många år som din supportperiod

Verktyg som syft, cyclonedx-cli och dependency-track täcker det tekniska. Det svåra är inte att generera filen, det är att hålla processen levande över årtionden.

Vad gör du nu, månad för månad

Vi har sett tillräckligt många NIS2- och DORA-implementationer för att veta hur det här går: hälften väntar tills sex månader innan deadline och får då hjälp till en panikbudget. Det vi rekommenderar är en lite mer behaglig timeline.

Q2 2026 (där vi är nu — 3,5 månader till sårbarhets­rapporteringen)

• Inventera vilka produkter du säljer som kan omfattas
• Etablera SBOM-generering i CI/CD
• Skriv en vulnerability disclosure-policy och publicera security.txt
• Sätt upp PSIRT-bemanning utanför kontorstid eller köp som tjänst
• Mappa befintligt säkerhetsarbete mot bilaga I-kraven, hitta gluggarna

Q3 2026 (in mot 11 september-deadline)

• Pilotera incidentrapporterings­flödet — kör en torrkörning mot ENISA-mallen
• Hotmodellering per produktlinje
• Process för att skicka säkerhetsuppdateringar i fält (signering, validering, rollback)
• Dokumentera supportperiod i kundavtal

Q4 2026 — H1 2027

• Återkommande extern pentest, minst årlig
• Kontinuerlig sårbarhetsscanning på de delar av produkten som är nätverks­exponerade
• Genomför conformity assessment, internt eller med Notified Body beroende på klass
• Tekniskt dokumentationspaket (bilaga V): risk­bedömning, tester, designdokument
• CE-märknings­process inklusive deklaration om konformitet

H2 2027

• Final review, gap-analys
• Inrikta hela produktbacklogen mot CRA-compliance som hygien­krav

Sårbarhets­rapporten som ENISA vill se

När en aktivt utnyttjad sårbarhet upptäcks i din produkt vill ENISA ha:

1. Tidig varning inom 24 timmar — produkt, version, indikatorer på exploatering, geografisk spridning, eventuella åtgärder du redan tagit
2. Uppföljande rapport inom 72 timmar — teknisk natur, root cause-status, säkerhetsuppdaterings-ETA, mitigations
3. Slutrapport inom 14 dagar — patch publicerad, communications-plan mot kunder, lessons learned

Det är trekantsspelet 24 / 72 / 14 som man måste lära sig automatiskt. Inkludera mallar i runbooks innan första incidenten, inte under.

Kopplingen till NIS2 och DORA

NIS2 reglerar operatörer av väsentliga och viktiga tjänster. CRA reglerar produkter. Är du SaaS-leverantör är du primärt NIS2; är du firmwareleverantör för IoT är du primärt CRA; är du finansiell IT-leverantör är du DORA. Många landar i två eller alla tre.

Bra nyhet: kontrollerna överlappar kraftigt. SBOM, vulnerability disclosure, incident response, säkra uppdateringar, kontinuerlig övervakning — allt detta behöver alla tre. Bygg en gång, mappa mot tre ramverk.

Vart du kan ta vägen härifrån

Om du tillverkar mjukvara eller hårdvara som säljs i EU så är CRA inte en risk du kan "vänta och se" med. Tidsplanen är fast, sanktionerna är reella, och Notified Body-kapaciteten kommer vara begränsad ju närmare 2027 vi kommer.

Vill du ha hjälp att kartlägga din produktportfölj mot CRA-kraven, etablera SBOM-pipeline eller köra första pentestet som ska gå in i den tekniska dokumentationen, kontakta oss. Vi gör det åt en handfull svenska tillverkare redan och kan dela hur det landat.

Och har du en produkt redan på marknaden, börja med vulnerability disclosure-policyn. Det är den billigaste åtgärden med högst risk­reduktion innan september 2026.

Se även i ordlistan: CRA, NIS2, DORA, SBOM, PSIRT, VDP, security.txt, Coordinated disclosure, CVE, ENISA, CSIRT, Hotmodellering.