Guider

CRA-guide · 11 min

EU:s cyberresiliensförordning (CRA): vad den kräver, när den gäller och vad den betyder för din leveranskedja

Cyberresiliensförordningen är EU:s första horisontella cybersäkerhetslag för produkter. Där NIS2 styr hur organisationer bedriver sin säkerhet styr CRA säkerheten hos den hårdvara och mjukvara som tillhandahålls på EU-marknaden (från uppkopplade enheter till fristående mjukvara. Den är redan i kraft, dess första rapporteringsskyldigheter börjar i september 2026, och från december 2027 får en produkt som inte uppfyller dess krav inte längre säljas lagligt i EU. Den här guiden förklarar tillämpningsområdet, tidslinjen och skyldigheterna) och, för de team som köper och är beroende av dessa produkter, vad du bör kräva av dina leverantörer och hur du styrker det.

Viktigaste punkterna

  • CRA reglerar produkter med digitala element (hårdvara och mjukvara) som säljs i EU; den riktar sig först till tillverkare, med skyldigheter även för importörer och distributörer.
  • Stegvisa datum: i kraft sedan december 2024, rapportering av sårbarheter och incidenter från den 11 september 2026, alla huvudsakliga skyldigheter från den 11 december 2027.
  • Ren SaaS faller i regel utanför CRA, men om du upphandlar produkter eller komponenter pekar din NIS2-leveranskedjeplikt och CRA nu åt samma håll: kräv bevis på inbyggd säkerhet och sårbarhetshantering.

Vad CRA är

Cyberresiliensförordningen (förordning (EU) 2024/2847) fastställer obligatoriska cybersäkerhetskrav för ”produkter med digitala element”: varje mjukvaru- eller hårdvaruprodukt, och dess lösningar för fjärrdatabehandling, som kan anslutas till en enhet eller ett nät och som tillhandahålls på EU-marknaden. Det är en förordning, så den gäller direkt i alla 27 medlemsstater utan nationellt införlivande.

Merparten av skyldigheterna ligger på tillverkaren, som måste utforma, tillverka och underhålla produkten säkert och styrka överensstämmelse (CE-märkningen). Importörer och distributörer har egna skyldigheter. De får endast tillhandahålla produkter som uppfyller kraven och måste agera när de får veta att en produkt inte gör det. Förordningen definierar även två klasser med högre risk, ”viktiga” och ”kritiska” produkter (till exempel lösenordshanterare, nätverkshanteringssystem eller hårdvarusäkerhetsmoduler), som omfattas av strängare förfaranden för bedömning av överensstämmelse.

Inom tillämpningsområdet

Hårdvaru- och mjukvaruprodukter som tillhandahålls på EU-marknaden och kan anslutas till en enhet eller ett nät: uppkopplade enheter, operativsystem, applikationer, bibliotek och de lösningar för fjärrdatabehandling som hör väsentligen samman med dem.

Utanför tillämpningsområdet (särskilt SaaS)

Ren software-as-a-service är i regel inte en ”produkt” enligt CRA utan hanteras i stället av NIS2: såvida inte en lösning för fjärrdatabehandling är väsentlig för en produkts funktion och byggd av den produktens tillverkare. Produkter som redan omfattas av sektorsregler (t.ex. medicintekniska produkter, motorfordon, vissa luftfartsprodukter) är också undantagna.

Tidslinjen som betyder något

CRA gäller stegvis. Två datum styr det mesta av planeringen:

10 dec 2024

Trädde i kraft. Klockan börjar ticka; inga materiella skyldigheter gäller ännu.

11 sep 2026

Rapporteringsskyldigheterna börjar. Tillverkare måste rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter (en tidig varning inom 24 timmar, en anmälan inom 72 timmar och en slutrapport inom 14 dagar) till sitt nationella CSIRT och ENISA via den gemensamma rapporteringsplattformen.

11 dec 2027

Full tillämpning. Alla väsentliga krav gäller; produkter med digitala element som inte uppfyller kraven får inte längre tillhandahållas på EU-marknaden.

Vad tillverkare måste göra

De väsentliga kraven löper genom hela produktens livscykel. Sammanfattningsvis måste en tillverkare som uppfyller kraven:

  • Utforma säkert (inbyggd säkerhet och säkerhet som standard): leverera med en säker konfiguration, minimera attackytan och skydda konfidentialitet och integritet.
  • Hantera sårbarheter under hela supportperioden: identifiera, dokumentera och åtgärda dem samt tillhandahålla säkerhetsuppdateringar kostnadsfritt under en supportperiod som speglar produktens förväntade livslängd (kommissionen anger minst fem år för många produkter).
  • Tillhandahålla en programvaruförteckning (SBOM): föra en maskinläsbar förteckning över komponenter så att berörda produkter snabbt kan hittas när en ny sårbarhet dyker upp i ett beroende.
  • Driva en policy för samordnat röjande av sårbarheter: publicera en kontaktpunkt och en process för att rapportera sårbarheter (den roll som security.txt fyller i praktiken).
  • Rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter: enligt tidslinjen 24 tim / 72 tim / 14 dagar, från den 11 september 2026.
  • Visa överensstämmelse och anbringa CE-märkningen: genom egenbedömning för de flesta produkter, eller bedömning av tredje part för klasserna ”viktiga” och ”kritiska”, med stöd av teknisk dokumentation.

Hur CRA förhåller sig till NIS2

NIS2 och CRA kompletterar varandra, de konkurrerar inte. NIS2 handlar om entiteter (hur en väsentlig eller viktig organisation styr och bedriver sin egen säkerhet, inklusive cyberrisken hos sina leverantörer (art. 21.2 d). CRA handlar om produkter) om de saker som släpps ut på marknaden är säkra i sin utformning och korrekt underhållna. Den ena reglerar verksamhetsutövaren, den andra det som verksamhetsutövaren köper och använder.

Det är just där de möts. En NIS2-entitets leveranskedjeplikt omfattar allt oftare frågan ”är de produkter och komponenter vi upphandlar CRA-redo?”: hanterar leverantören sårbarheter, levererar den uppdateringar, publicerar den en kanal för röjande och tillhandahåller den en SBOM? Från december 2027 besvarar CE-märkningen en del av detta; fram till dess, och löpande därefter, behöver köpare fortfarande sin egen försäkran om att en leverantörs säkerhet håller i praktiken.

CRA är en förordning av produktsäkerhetstyp, och vissa gränsdragningar (särskilt linjen mellan SaaS och fjärrdatabehandling samt klasserna ”viktiga” och ”kritiska”) kan vara nyanserade. Bekräfta hur den tillämpas på en viss produkt med kvalificerad rådgivning och den officiella texten.

Vad det betyder för dig

Dina skyldigheter beror på din roll i kedjan. En snabb orientering:

En tillverkare av produkter med digitala element

CRA gäller direkt. Bygg upp förmågorna för inbyggd säkerhet, sårbarhetshantering, SBOM, röjande och rapportering nu: rapporteringsplikten gäller från september 2026 och full överensstämmelse krävs senast december 2027.

En importör eller distributör

Du får endast tillhandahålla produkter på EU-marknaden som uppfyller kraven och är CE-märkta, måste kontrollera att tillverkaren uppfyllt sina skyldigheter och måste agera (och informera myndigheterna) när du får veta att en produkt medför en betydande cybersäkerhetsrisk.

En köpare eller verksamhetsutövare (särskilt under NIS2)

CRA reglerar dig inte direkt som köpare, men den omformar vad som räknas som ”bra” vid upphandling. Kräv bevis på sårbarhetshantering, en SBOM, en policy för röjande och en supportperiod, och övervaka om leverantörerna faktiskt levererar.

En ren SaaS-leverantör

I regel utanför CRA (du faller i stället under NIS2): såvida inte din tjänst är en lösning för fjärrdatabehandling som är väsentlig för en reglerad produkt. Oavsett vilket kommer dina kunders due diligence att ställa samma säkerhetsfrågor.

Källor: Förordning (EU) 2024/2847 (Cyber Resilience Act) samt Europeiska kommissionens sidor om Cyber Resilience Act. Datum och tillämpningsområde följer den offentliggjorda förordningen; bekräfta detaljer för dina produkter med kvalificerad rådgivning.

Hur norppa.io hjälper

norppa.io gör inte en produkt CRA-förenlig (det är tillverkarens uppgift) men det ger köpare och verksamhetsutövare det externa belägg som upphandling och NIS2-due diligence nu kräver. De signaler som CRA bygger på är just de vi övervakar löpande: mjukvara vid slutet av sin livscykel och opatchade sårbarheter (svag sårbarhetshantering), en saknad kanal för samordnat röjande samt exponerade eller felkonfigurerade tjänster.

Självbedömningsformulär fångar de delar som ingen extern skanning ser (SBOM-tillgänglighet, den angivna support- och uppdateringsperioden, överensstämmelsestatus) och varje svar ställs bredvid den tekniska profilen i realtid. Resultatet är aktuellt, bekräftat belägg för en leverantörs säkerhetsnivå, redo för din leverantörsakt, i stället för ett engångspåstående.

Belägg för att dina leverantörer faktiskt håller

Se en exempelrapport för en leverantör (fynd, bevis och artikelmappning) på ungefär två minuter.

Visa exempelrapport

Relaterade guider

Så uppfyller du NIS2: en steg-för-steg-färdplan

Stegen till NIS2-efterlevnad i ordning: bekräfta omfattning, registrera dig, ledningens ansvar (art. 20), åtgärderna i art. 21.2, leveranskedjesäkerhet, incidentrapportering (art. 23) och löpande, styrkt säkring.

Vem omfattas av NIS2? Väsentliga och viktiga aktörer, sektorer och storlekströsklar

Avgör om NIS2 gäller dig: de två nivåerna, sektorerna i bilaga I/II, storlekströsklarna, storleksoberoende undantag och hur leveranskedjan drar in dig även utan utpekning.

NIS2 och leveranskedjekravet: vad det innebär i praktiken

NIS2 kräver att viktiga och betydande aktörer bedömer cyberriskerna i sina leveranskedjor. Leverantörstierning, fjärdepartsrisk, Art. 23-anmälan och vad revisorer letar efter.

Leverantörens cyberriskbedömning: vad automatiserad NIS2-övervakning kontrollerar

Alla kontrollkategorier förklaras: ransomware, dark web-läckor, TLS/DNSSEC, cookie-säkerhet, CVE/EPSS, sanktioner, MX-svartlistor och SAQ. Fyndens livscykel och NIS2-artikelmappning.

NIS2 Art. 21(2): säkerhetschecklista för leverantörer

Checklista för inköps- och säkerhetsteam: vad man ska fråga, vilka bevis man ska samla in och hur man reagerar när en leverantör brister. Inkluderar förslag på styrkande dokument.

NIS2-leverantörsenkät (SAQ): vad du ska fråga, hur du poängsätter och en gratis mall

Vad du ska fråga leverantörer enligt art. 21.2 d, hur du poängsätter svar och hanterar brister, varför självdeklaration behöver verifieras, plus en gratis enkätmall.

NIS2-incidentrapportering: 24- och 72-timmarsfristerna förklarade

Vad som är en betydande incident, tidslinjen i artikel 23 (24-timmars tidig varning, 72-timmars anmälan, slutrapport på en månad) och när en leverantörs incident blir din skyldighet.

NIS2 och ledningens ansvar: vad styrelse och ledning måste veta

Vad NIS2 förväntar sig av ledningsorganet: godkännande- och tillsynsplikt, personligt ansvar (art. 20), utbildning, styrelse-KPI:er och sanktionerna enligt art. 34.

ISO 27001 och NIS2: vad ditt LIS redan täcker, och luckorna det inte gör

Om du har ISO 27001: vad som förs över till NIS2 och inte (lagstadgad incidentrapportering, ledningens ansvar, registrering och kontinuerlig leveranskedjesäkring) och hur du täpper till luckan.

NIS2 vs DORA: hur de skiljer sig, var de överlappar och vilken som gäller dig

Hur de två EU-regelverken skiljer sig och överlappar, varför DORA är lex specialis för finansiella enheter, vilken som gäller dig, och vad båda innebär för tredjepartsrisk.

GDPR vs NIS2: överlapp, skillnader och när en incident utlöser båda

Hur GDPR och NIS2 skiljer sig och överlappar, när en incident utlöser båda (GDPR art. 33 72 h till tillsynsmyndigheten vs NIS2 art. 23 24 h/72 h/en månad till CSIRT), art. 35-samarbetet och förbudet mot dubbel sanktion, och vad båda innebär för leverantörsgranskning.

EU:s AI-förordning: risknivåer, tidslinjen och vad tillhandahållare av AI i drift måste göra (artikel 26)

Vad EU:s AI-förordning kräver: risknivåerna, de stegvisa datumen (i kraft 2024, förbjudet feb 2025, GPAI aug 2025, hög risk aug 2026), skyldigheterna i drift enligt art. 26, hur den staplas med NIS2 och GDPR, och vad den betyder för AI-upphandling.