Granskad 17 oktober 2026.
Vad är EU:s cyberresiliensförordning?
EU:s cyberresiliensförordning (Cyber Resilience Act, CRA), förordning (EU) 2024/2847, är en EU-förordning som ställer cybersäkerhetskrav på produkter med digitala element: hård- och mjukvara som ansluter till en enhet eller ett nätverk, även produkter med inbyggd programvara och komponenter som säljs separat. De flesta skyldigheterna ligger på tillverkaren, alltså företaget som släpper ut produkten på EU-marknaden under eget namn. Tillverkaren ska konstruera produkten för en lämplig säkerhetsnivå (bilaga I), hantera sårbarheter under en supportperiod på minst fem år om produkten inte förväntas användas kortare tid (artikel 13.8) och rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter, med en tidig varning inom 24 timmar (artikel 14). Tillverkaren ska också spara teknisk dokumentation, inklusive en mjukvaruförteckning (SBOM), i minst tio år (artikel 13.13) och CE-märka produkten innan den säljs. Rapporteringen gäller från den 11 september 2026 och resten av förordningen från den 11 december 2027 (artikel 71).
Artikelhänvisningarna i guiden avser den officiella texten på EUR-Lex.
Den här guiden och de fördjupande sidorna
Den här sidan förklarar förordningen: vilka den omfattar, när den gäller och vad den kräver. Tre sidor går djupare:
- CRA-checklistan för konstruktion: arbetet för ett konstruktionsteam, steg för steg från klassificering till arkivering, med artikeln eller bilagan bakom varje punkt. Den går att skriva ut.
- SBOM och produktdata: vad CRA kräver av en mjukvaruförteckning, vilka format och datafält som gäller och hur ni kopplar varje SBOM till en firmwareversion och en hårdvarurevision.
- CRA-efterlevnad med neo: hur neo håller den tekniska dokumentationen styrd och kopplad till produktrevisioner, och vad neo inte gör.
Vilka som omfattas
Förordningen gäller produkter med digitala element, som i artikel 3.1 definieras som en mjukvaru- eller hårdvaruprodukt och dess lösningar för fjärrdatabehandling, inklusive komponenter som släpps ut på marknaden separat. Har er produkt inbyggd programvara, ansluter den till ett nätverk eller en app, eller levereras den med mjukvara, omfattas den sannolikt.
De flesta skyldigheterna ligger på tillverkaren, alltså företaget som släpper ut produkten på EU-marknaden under eget namn eller varumärke. Importörer och distributörer har egna, lättare skyldigheter.
Artikel 2 undantar vissa produkter som redan regleras av sektorslagstiftning, bland annat:
- Medicintekniska produkter enligt förordning (EU) 2017/745 och medicintekniska produkter för in vitro-diagnostik enligt förordning (EU) 2017/746.
- Fordon enligt förordning (EU) 2019/2144.
- Civil luftfart enligt förordning (EU) 2018/1139 och marin utrustning enligt direktiv 2014/90/EU.
Utvecklar ni medicinteknik, gå igenom vilka av era produkter som omfattas av MDR eller IVDR. Tillbehör, kompletterande hårdvara och icke-medicinska produktlinjer kan ändå falla under CRA. Bilaga III tar till exempel upp bärbara produkter för hälsoövervakning som MDR och IVDR inte gäller för.
Tidslinje
| Datum | Vad som händer | Källa |
|---|---|---|
| 20 november 2024 | Förordningen publiceras i Europeiska unionens officiella tidning | EUT L, 2024/2847 |
| 10 december 2024 | Förordningen träder i kraft | Artikel 71.1 |
| 11 juni 2026 | Reglerna om anmälan av organ för bedömning av överensstämmelse börjar gälla (kapitel IV) | Artikel 71.2 |
| 11 september 2026 | Rapporteringsskyldigheten för aktivt utnyttjade sårbarheter och allvarliga incidenter börjar gälla (artikel 14) | Artikel 71.2 |
| 11 december 2027 | Förordningen gäller i sin helhet | Artikel 71.2 |
Två detaljer är lätta att missa. Rapporteringsskyldigheten i artikel 14 gäller alla produkter som omfattas, även de som släppts ut på marknaden före den 11 december 2027 (artikel 69.3). För sådana äldre produkter gäller övriga krav bara om de genomgår en väsentlig ändring från och med det datumet (artikel 69.2).
Tillverkarens viktigaste skyldigheter
Väsentliga cybersäkerhetskrav
Enligt bilaga I del I ska produkter konstrueras, utvecklas och tillverkas så att de har en lämplig cybersäkerhetsnivå utifrån riskerna. Bilagan räknar upp konkreta egenskaper, bland annat: inga kända utnyttjbara sårbarheter vid lansering, säker standardkonfiguration, möjlighet att ta emot säkerhetsuppdateringar, åtkomstkontroll, skydd av datas konfidentialitet och integritet, dataminimering, begränsad attackyta, säkerhetsloggning och ett sätt för användaren att säkert radera data och inställningar.
Sårbarhetshantering
Bilaga I del II beskriver hur tillverkaren ska hantera sårbarheter under supportperioden. Tillverkaren ska identifiera och dokumentera komponenter och sårbarheter, åtgärda sårbarheter utan dröjsmål, testa säkerheten regelbundet, offentliggöra information om åtgärdade sårbarheter, ha en policy för samordnat offentliggörande av sårbarheter, distribuera uppdateringar säkert och tillhandahålla säkerhetsuppdateringar utan dröjsmål och utan kostnad.
Riskbedömning och tillbörlig aktsamhet
Artikel 13.2 kräver en cybersäkerhetsriskbedömning som påverkar planering, konstruktion, utveckling, tillverkning, leverans och underhåll. Artikel 13.5 kräver tillbörlig aktsamhet när ni bygger in komponenter från tredje part, även programvara med öppen källkod.
Supportperiod
Supportperioden ska vara minst fem år, om inte produkten förväntas användas kortare tid. Då motsvarar den den förväntade användningstiden (artikel 13.8). Varje säkerhetsuppdatering som ges ut under supportperioden ska finnas tillgänglig i minst tio år efter att den gavs ut, eller under resten av supportperioden om den är längre (artikel 13.9). Tillverkaren ska tala om för användaren när supportperioden upphör (bilaga II).
Rapportering
Enligt artikel 14 ska tillverkaren anmäla aktivt utnyttjade sårbarheter och allvarliga incidenter till den CSIRT som utsetts till samordnare och till Enisa, via den gemensamma rapporteringsplattformen. Tidsgränserna: en tidig varning inom 24 timmar från att tillverkaren fått kännedom, en anmälan inom 72 timmar och en slutrapport (14 dagar efter att en åtgärd finns tillgänglig för sårbarheter, en månad efter anmälan för incidenter). I checklistan finns tidsgränserna i en tabell, tillsammans med processen runt dem.
Bedömning av överensstämmelse och CE-märkning
Innan produkten släpps ut på marknaden ska tillverkaren genomföra en bedömning av överensstämmelse, upprätta en EU-försäkran om överensstämmelse (artikel 28) och anbringa CE-märkningen (artikel 30). Förfarandet beror på produktens klass (artikel 32):
| Produktklass | Exempel ur förordningen | Bedömning av överensstämmelse |
|---|---|---|
| Standard | De flesta produkter med digitala element | Intern kontroll (modul A) är tillåten |
| Viktig, klass I (bilaga III) | Operativsystem, routrar och switchar, lösenordshanterare, mikrostyrenheter med säkerhetsrelaterade funktioner, smarta hemprodukter med säkerhetsfunktioner | Modul A bara om harmoniserade standarder, gemensamma specifikationer eller en certifieringsordning tillämpas; annars tredjepartsbedömning (modul B och C, eller H) |
| Viktig, klass II (bilaga III) | Brandväggar, intrångsdetekteringssystem, hypervisorer, manipuleringssäkra mikrostyrenheter | Tredjepartsbedömning (modul B och C, eller H) eller en europeisk certifieringsordning för cybersäkerhet |
| Kritisk (bilaga IV) | Hårdvaruenheter med säkerhetsboxar, gateways för smarta mätare, smartkort och säkra element | Europeisk certifieringsordning för cybersäkerhet där det krävs, annars som klass II |
En produkt räknas som viktig när dess kärnfunktion motsvarar en kategori i bilaga III (artikel 7.1). Det räcker inte att den innehåller en sådan komponent.
Vilken teknisk dokumentation kräver CRA?
Enligt CRA är den tekniska dokumentationen det underlag som tillverkaren tar fram innan en produkt med digitala element släpps ut på EU-marknaden, för att visa att produkten uppfyller de väsentliga cybersäkerhetskraven (artikel 31). Bilaga VII anger vad den minst ska innehålla: en allmän beskrivning av produkten och dess avsedda ändamål, information om konstruktion, utveckling och tillverkning som ritningar och systemarkitektur, processen för sårbarhetshantering med mjukvaruförteckningen (SBOM), cybersäkerhetsriskbedömningen, motiveringen för supportperioden, de standarder eller specifikationer som tillämpats, testrapporter och en kopia av EU-försäkran om överensstämmelse. SBOM:en ska vara i ett vanligt förekommande, maskinläsbart format och åtminstone omfatta beroendena på högsta nivå (bilaga I del II punkt 1), men tillverkaren behöver inte offentliggöra den (skäl 77). Dokumentationen ska hållas aktuell och finnas tillgänglig för marknadskontrollmyndigheterna i minst tio år efter att produkten släppts ut på marknaden, eller under supportperioden om den är längre (artikel 13.13).
Checklistan delar upp bilaga VII i punkter som ni kan bocka av, och SBOM och produktdata går igenom mjukvaruförteckningen i detalj.
Vad det betyder för konstruktion och produktdata
CRA är en cybersäkerhetsförordning, ändå handlar mycket av arbetet om hur ni styr konstruktionsdata. För hårdvaruteam innebär det:
- Dokumentationen måste höra till en bestämd produkt. Programvaruversioner, SBOM, testrapporter och försäkran om överensstämmelse beskriver alla ett visst utförande. När firmware eller hårdvara ändras behöver ni veta vilka dokument som ändras med.
- Ändringar måste vara spårbara. Ni behöver underlag för att visa om en ändring är "väsentlig": vad som ändrades, varför och vem som godkände det.
- Dokumentationen måste överleva projektteamet. Tio år eller mer är längre än de flesta filservrar, verktyg och anställningar varar, så underlaget måste gå att hitta och vara intakt.
- Leverantörerna är en del av bilden. Tillbörlig aktsamhet för komponenter från tredje part innebär att ni samlar in och styr leverantörsinformation tillsammans med er egen.
Så kommer ni igång
- Kartlägg produktportföljen. Lista produkter med digitala element och stäm av var och en mot undantagen och kategorierna i bilaga III och IV.
- Förbered rapporteringen. Artikel 14 gäller redan. Bestäm vem som tar emot sårbarhetsrapporter, vem som beslutar och vem som anmäler.
- Fastställ supportperioden för varje produkt och dokumentera motiveringen.
- Inför SBOM-generering i byggprocessen för firmware och mjukvara med ett särskilt verktyg.
- Strukturera den tekniska dokumentationen enligt bilaga VII och koppla den till produktrevisioner.
- Gör en gapanalys mot bilaga I och planera vägen till bedömning av överensstämmelse.
CRA-checklistan för konstruktion bryter ned stegen ytterligare.
Där ett PDM-system hjälper
Ett PDM-system gör inte en produkt säker, genererar inte SBOM:er och söker inte efter sårbarheter; det kräver särskilda verktyg och en process för sårbarhetshantering. Det som PDM kan göra är att hålla riskbedömning, SBOM, testrapporter och försäkran om överensstämmelse versionshanterade, godkända och kopplade till den produktrevision de beskriver, så länge förordningen kräver. CRA-efterlevnad med neo visar hur det fungerar i neo och var gränserna går, eller prata med oss om era produkter.