Steg-för-steg-guide till efterlevnad av Cyber ​​Resilience Act (CRA)

Publicerad: januari 2026. Uppdaterad: augusti 2026. Granskad av Encryption Consultings Compliance Advisory-team.

Vad kräver lagen om cybermotståndskraft?

Cyber ​​Resilience Act (CRA), tidigare förordning (EU) 2024/2847, är Europeiska unionens första horisontella lag som fastställer obligatoriska cybersäkerhetskrav för produkter med digitala element, hårdvara eller mjukvara, som säljs var som helst på EU-marknaden. Steg för steg-efterlevnaden av Cyber ​​Resilience Act (CRA) beror på en styrande princip som anges i artikel 6 : endast produkter som är säkra genom design och stöds under hela sin livscykel får släppas ut på EU-marknaden.

Den principen delas upp i två pelare.

1. Produkter måste vara säkra genom design och användning (bilaga I, del I)

En produkt är endast kompatibel om den uppfyller de väsentliga cybersäkerhetskraven i bilaga I, del I , och fortsätter att installeras, underhållas och uppdateras korrekt av användaren eller operatören. I praktiken innebär detta att produkten måste levereras säkert och förbli säker under hela sin livslängd, inte bara klara en kontroll på lanseringsdagen.

CRA sorterar produkter i fyra riskkategorier, och den kategori en produkt tillhör avgör hur den bedöms för överensstämmelse:

• Standardkategori: Ungefär 90 procent av produkterna med digitala element, inklusive allmän konsumentelektronik som smarta högtalare, hårddiskar och fotoredigeringsprogram.
• Viktiga produkter Klass I: Produkter med cybersäkerhetsrelevanta funktioner, såsom identitetshanteringssystem, webbläsare, lösenordshanterare, VPN-programvara och smarta säkerhetsenheter för hemmet.
• Viktiga produkter Klass II: Produkter med högre risk såsom brandväggar, industriella system för detektering och förebyggande av intrång, hypervisorer och manipuleringssäkra mikroprocessorer.
• Kritiska produkter: Den högsta risknivån, där viktiga enheter är beroende av produkten, såsom säkra element i smarta kort och smarta mätargateways.

2. Tillverkare måste följa säkra utvecklings- och livscykelprocesser (bilaga I, del II)

Efterlevnad handlar inte bara om den levererade enheten. Enligt bilaga I, del II , måste tillverkare köra en sårbarhetshanteringsprocess, följa säkra utvecklingspraxis under hela produktens livscykel och fortsätta leverera säkerhetsuppdateringar så länge produkten stöds. Efterlevnad av CRA-krav är ett stående operativt program, inte en engångscertifiering.

Vem behöver följa CRA:s regler?

Alla tillverkare i eller utanför EU som säljer produkter med digitala element i Europa omfattas av detta skydd, vilket fördelar sig enligt följande:

• EU-tillverkare baserade inom EU som bygger produkter med programvara eller firmware och säljer dem i EU.
• Tillverkare utanför EU baserade utanför EU, till exempel i USA eller Kina, som säljer direkt till EU-marknaden eller via EU-distributörer och importörer.

Om produkten hamnar på EU-marknaden gäller kreditvärderingsförordningen oavsett var företaget är beläget. Försäljning via en online-marknadsplats skapar inte ett undantag; om EU-kunder kan köpa den omfattas tillverkaren av tillämpningsområdet.

CRA omfattar programvara och firmware som körs på eller levereras med anslutna enheter: enheters operativsystem, inbäddad firmware, mobilappar som styr IoT-produkter, verktyg för skrivbordshantering och molngränssnitt som interagerar med dessa enheter. Typiska kategorier inkluderar IoT- och inbäddade enheter som används i hem, sjukvård och industriella miljöer; industriell styr- och automationsutrustning; och konsumentelektronik såsom bärbara enheter, smarta apparater och anslutna säkerhetsprodukter.

Vad är tidslinjen för efterlevnad av kreditvärderingsregler?

Kreditvärderingsinstitutet fasar in enligt ett fast, EU-bekräftat schema. Det finns ingen respitperiod utöver dessa datum.

1. 10 december 2024 träder CRA i kraft. Förordningen trädde i kraft detta datum. Den kräver inte omedelbar efterlevnad, men den startar nedräkningen; tillverkare, importörer och distributörer bör börja bygga upp de processer, den dokumentation och de tekniska kontroller som de senare tidsfristerna kräver.
2. Från och med den 11 juni 2026 gäller bestämmelser om anmält organ och marknadskontroll. Kapitel IV-bestämmelserna som reglerar organ för bedömning av överensstämmelse och marknadskontrollmyndigheter träder i kraft, vilket ger tillsynsinfrastrukturen tid att etablera sig innan rapporteringsskyldigheterna träder i kraft.
3. 11 september 2026 börjar rapportering av sårbarheter och incidenter. Enligt artikel 14 måste tillverkare rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter till Enisa och nationella CSIRT-enheter inom fastställda tidsramar, och måste redan ha en grundläggande process för hantering och offentliggörande av sårbarheter igång. Detta är den mjuka starten för CRA: transparens och tidig varning, inför fullständig produktöverensstämmelse.
4. 11 december 2027, fullständig efterlevnad krävs. Varje produkt med digitala element som släpps ut på EU-marknaden måste uppfylla CRA:s krav fullt ut: säker genom design och säker genom standardutveckling, skapande och underhåll av SBOM, dokumenterad sårbarhetshantering, fungerande säkerhetsuppdateringsmekanismer och CE-märkning kopplad till överensstämmelse med cybersäkerhetskraven. Icke-kompatibla produkter får inte lagligt säljas i EU efter detta datum.

Produkter som lagligen släppts ut på EU-marknaden före den 11 december 2027 är i allmänhet undantagna från huvudkraven, så länge de inte genomgår en väsentlig modifiering efter det datumet. En väsentlig modifiering gör den modifierande enheten till tillverkare för kreditvärderingsinstitut och omfattar produkten fullt ut. Det enda kravet som gäller för produkter som redan finns på marknaden oavsett detta undantag är artikel 14 om rapportering av sårbarheter och incidenter, som gäller från och med den 11 september 2026 för alla produkter som omfattas av direktivet.

Vilken vägledning ger CRA för kryptografisk och algoritmisk val?

CRA är avsiktligt teknikneutral. Bilaga I, del I, kräver att tillverkare skyddar datasekretessen ”genom att kryptera relevant data i vila eller under överföring med hjälp av toppmoderna mekanismer” (artikel 2 e) och att skydda integriteten hos lagrade och överförda data, kommandon och konfigurationer mot obehörig modifiering (artikel 2 f), men den namnger inte specifika algoritmer. Det valet, och revisionsloggen bakom den, lämnas till tillverkaren, vilket är precis där de flesta överensstämmelsebedömningar hittar luckor.

En försvarbar baslinje för produkter som omfattas av CRA-scope ser ut så här:

• Data i vila och under överföring: AES-256 för symmetrisk kryptering, TLS 1.3 för nätverkskanaler och en dokumenterad anledning när en svagare chiffersvit fortfarande används för äldre interoperabilitet.
• Digitala signaturer för firmware och uppdateringsintegritet: RSA-2048 eller ECDSA P-256 som det klassiska minimumet, och går mot hybridsignering som parar ihop en klassisk algoritm med ett NIST-postkvantschema som ML-DSA (FIPS 204) för generell signering.
• Begränsad och långlivad firmware: NIST SP 800-208 betecknar de tillståndsfulla hashbaserade scheman LMS och XMSS för firmware- och programvarusignering där signaturstorlek och kodens fotavtryck är viktigare än rå dataflöde, vilket är anledningen till att NSA:s CNSA 2.0 för närvarande utser dem till det kortsiktiga valet specifikt för firmware.
• Nyckelinkapsling för sekretess: ML-KEM (FIPS 203) där en produkts förväntade supportlivslängd sträcker sig in på 2030-talet och ett exponeringsfönster för skörd-nu-dekryptera-senare är realistiskt.

Val av algoritm är inte ett engångsbeslut. Det måste dokumenteras som en del av den tekniska fil som ett anmält organ eller en marknadskontrollmyndighet kommer att begära att få se, och det behövs en definierad väg för att ersätta en algoritm utan att omstrukturera produkten, vilket är vad de följande två avsnitten behandlar.

Vilken hotbild antar CRA?

CRA:s väsentliga krav avser en specifik uppsättning angriparfunktioner som förordningen förväntar sig att tillverkare ska försvara sig mot, inte ett generiskt "vara säker"-mandat:

• Leveranskedja och uppdateringsinjektion. En angripare som komprometterar en byggpipeline, en signeringsnyckel eller en distributionskanal försöker skicka obehörig firmware eller programvara till enheter som redan är i fält. Bilaga I, del I 2(c) och 2(f) åtgärdar detta direkt genom att kräva signerade, verifierbara uppdateringar och manipuleringsdetektering för kod och konfiguration.
• Utnyttjande av kända sårbarheter. Bilaga I, del I 2(a) antar att produkter levereras med sårbarheter som upptäcks efter lanseringen och kräver en fungerande information och patchpipeline, inte bara en ren genomsökning vid lanseringen.
• Obehörig åtkomst och attacker mot inloggningsuppgifter. Standard- eller hårdkodade inloggningsuppgifter, exponerade hanteringsgränssnitt och svag autentisering behandlas som ett designfel enligt 2(b) och 2(d), inte ett konfigurationsfel som kunden borde ha upptäckt.
• Harvest-nu-decrypt-senare. CRA nämner inte kvantberäkning som ett hot, men den över femåriga supportskyldigheten enligt artikel 13 innebär att data eller signaturer som idag skyddas av enbart klassiska algoritmer kan behöva förbli konfidentiella eller verifierbara långt efter den punkt då en kryptografiskt relevant kvantdator blir en trovärdig risk, vilket är anledningen till att algoritmisk agilitet hör hemma i hotmodellen även om själva regleringen är algoritmneutral.
• Kompromisser i fysiskt skede och tillverkningsskede. För IoT och inbyggda enheter är en angripare med fysisk åtkomst till en enhet eller ett fotfäste i kontraktstillverkningsprocessen en realistisk aktör, vilket är anledningen till att säker start förankrad i hårdvara och provisionering per enhet är lika viktig som mjukvarukontrollerna ovanför dem.

Vilka är avvägningarna mellan prestanda och interoperabilitet?

Att uppfylla CRA:s kryptografiska krav är inte gratis, och avvägningarna skiljer sig åt beroende på produktklass.

• Signaturstorlek på begränsade enheter. ML-DSA- och SLH-DSA-signaturer är ungefär 2 till 8 gånger större än en ECDSA P-256-signatur, vilket har direkt betydelse för starttid och flashbudget på IoT-enheter i mikrokontrollerklass. Detta är den praktiska anledningen till att NIST SP 800-208:s LMS och XMSS, med sina mindre signaturer, fortfarande är det kortsiktiga valet för firmware trots att de kräver tillståndskänslig, kraschkonsekvent nyckelhantering i en validerad HSM.
• Overheadkostnader för hybridsignering. Signering med både en klassisk och en postkvantalgoritm under övergångsperioden fördubblar ungefär tiden för signaturgenerering och verifiering. För CI/CD-signeringspipelines med hög volym absorberas detta vanligtvis utan problem; för en enhet som verifierar en signatur under en strömbegränsad startsekvens gör det det inte.
• Harmoniserade standarder är fortfarande under arbete. Europeiska kommissionen har gett CEN och CENELEC i uppdrag att utarbeta harmoniserade standarder som ger tillverkare en presumtion om överensstämmelse när de väl har publicerats. Tills dessa standarder är färdigställda bedömer tillverkare överensstämmelsen direkt mot bilaga I-texten, vilket innebär att två revisorer rimligen kan komma fram till olika slutsatser om samma kontroll tills de harmoniserade standarderna kommer ikapp.
• Gränsöverskridande distribution av uppdateringar. En enda uppdateringsmekanism måste fungera i alla EU-medlemsstaters nätverksförhållanden och, för produkter som även säljs utanför EU, måste den samexistera med icke-EU-reglerade krav utan att upprätthålla en separat signeringspipeline per region.

Vilken nyckelhantering är säker uppdateringssignering beroende av?

Kravet på säkra uppdateringar i artikel 13 är bara så starkt som nyckelhanteringen bakom det. En signerad uppdatering som bygger på en dåligt styrd nyckel skiljer sig inte nämnvärt från en osignerad när nyckeln läcker ut. En försvarbar arkitektur skiljer minst tre roller åt:

• Offline-rotnyckel. Används sällan, vanligtvis endast för att utfärda eller förnya certifikatet för online-signeringsnyckeln, genererad och förvarad i en HSM som förblir frånkopplad från alla nätverk och endast är online för schemalagda, bevittnade nyckelceremonier.
• Online-signeringsnyckel. Det som byggpipelinen faktiskt anropar i varje utgåva, HSM-baserat och nåbart via ett autentiserat API så att signering kan automatiseras, men aldrig samma nyckel som offline-roten, så att rotera den berör aldrig det förtroendeankare som redan är inbäddat i distribuerade enheter.
• Tillverkningsidentitet per enhet. Ett unikt nyckelpar som tillhandahålls vid tillverkningstillfället, enligt IEEE 802.1AR-mönstret, som låter en enhet autentisera sig själv till en uppdateringsserver som en äkta, icke-klonad enhet innan den ens tar emot en signerad avbildning.

Utöver den separationen behöver ett fungerande program FIPS 140-3-validerad hårdvara som skyddar varje signeringsnyckel, ett krav på M-of-N-godkännande så att ingen enskild person kan signera och leverera ensidigt, rollback-skydd som blockerar ominstallation av en äldre signerad men sårbar firmwareversion, och en förprovisionerad efterföljande nyckel så att en komprometterad nyckel kan ersättas utan en fältåterkallelse. Organisationer som behöver den djupare mekanismen i detta bör se Etablera ett ramverk för firmwaresignering för CRA-efterlevnad och CRA-efterlevnadsarkitektur för säker kodsignering , som täcker hela nyckelhierarkin och återkallningsarbetsflödet i detalj.

Hur ser CRA-kompatibla implementeringar ut i praktiken?

Samma väsentliga krav gäller olika beroende på produktkategori.

Tillverkare av IoT-enheter (standardkategori). En leverantör som levererade sensorer för smarta hem möttes av det vanliga felmönstret: en enda delad signeringsnyckel som används i varje produktlinje, genererad på en byggserver snarare än i hårdvara. Åtgärden flyttade nyckelgenereringen till en HSM, delade signeringen i nycklar per produkt så att en kompromiss på en produktlinje inte exponerar de andra, lade till flerfaktorsautentisering för signeringsåtkomst och automatiserad signering inuti CI/CD-pipelinen med manipulationssäker granskningsloggning, vilket uppfyller både integritetskravet och den spårbarhet som en överensstämmelsebedömning förväntar sig.

Tillverkare av industriella styrenheter (viktig klass II). En leverantör av programmerbara logiska styrenheter för fabriksautomation behövde säker start förankrad i en oföränderlig hårdvarurot, eftersom dessa enheter körs ute i fält i ett decennium eller mer med sällan fysisk åtkomst för underhåll. Designen separerade startverifieringskedjan, knuten till den sällan roterade offline-roten, från uppdateringsverifieringskedjan, knuten till den mer frekvent roterade online-signeringsnyckeln, så en komprometterad eller åldrande online-nyckel kräver aldrig att den oföränderliga start-ROM:en flashas om.

Tillverkare av medicintekniska produkter (viktig klass I eller kritisk, beroende på funktion). En tillverkare av anslutna diagnostiska produkter behövde förena kreditvärderingsinstitutets SBOM och rapporteringsskyldigheter för sårbarheter med befintliga regelkrav för medicintekniska produkter. Arbetsmetoden behandlade kreditvärderingsinstitutets SBOM som den huvudinventarie som matar både kreditvärderingsinstitutets rapporteringsarbetsflöde enligt artikel 14 och den befintliga processen för medicintekniska övervakning, snarare än att upprätthålla två separata komponentinventarier som kunde glida isär.

Krav från kreditvärderingsinstitut i korthet: Krav, kontroll och var EC hjälper

Tabellen nedan kartlägger de väsentliga cybersäkerhetskrav som en tillverkare måste uppfylla i förhållande till den tekniska kontroll som uppfyller dem och den krypteringskonsulttjänst eller -produkt som byggts för den kontrollen.

Krav på kreditvärderingsinstitut (bilaga I)	Teknisk kontroll	Krypteringskonsulttjänst
Säker genom design (del I.1)	Riskbedömning, säker utvecklingslivscykel, minimering av attackytor	Efterlevnadsrådgivning
Inga kända sårbarheter som kan utnyttjas (2(a))	Sårbarhetsskanning, SBOM-granskning, åtgärd före utgivning	Efterlevnadsrådgivning, CBOM Secure
Säker standardkonfiguration (2(b))	Härdade standardinställningar, stöd för fabriksåterställning, inaktiverade oanvända tjänster	Efterlevnadsrådgivning
Aktuella, verifierbara säkerhetsuppdateringar (2(c))	Signerade uppdateringspaket, HSM-baserade signeringsnycklar, återställningsskydd	CodeSign Secure
Sekretess för lagrade och överförda uppgifter (2(e))	Toppmodern kryptering i vila och under överföring, hanterad nyckellivscykel	PKI-som-en-tjänst, HSM-som-en-tjänst
Integritet hos data, kommandon och konfiguration (2(f))	Digitala signaturer, kontrollsummor, autentiserade kommunikationskanaler	CodeSign Secure, PKI-som-en-tjänst
Övervakning och loggning av säkerhetshändelser (2(l))	Oföränderliga revisionsspår kopplade till varje signerings- och åtkomsthändelse	CodeSign Secure, CBOM Secure
SBOM och komponentspårning (del II.1)	Kryptografisk upptäckt, beroendeinventering, CVE-övervakning	CBOM-säkerhet
Sårbarhetsupplysning och rapportering (del II.4, artikel 14)	Samordnad policy för offentliggörande, Enisas rapporteringsarbetsflöde, dokumenterade tidslinjer	Efterlevnadsrådgivning

Vilka är påföljderna för bristande efterlevnad?

Artikel 64 ger marknadsövervakningsmyndigheterna både befogenhet att utdöma böter och att korrigera verkställigheten: att beordra att produkter dras tillbaka från marknaden, begränsa eller förbjuda ytterligare försäljning och kräva en omdesign innan en produkt kan säljas igen. Böterna nivåeras efter överträdelsens allvarlighetsgrad.

Överträdelse	Högsta böter	Omsättningstak (beroende på vilket som är högst)
Brott mot väsentliga cybersäkerhetskrav (bilaga I), skyldigheter enligt artikel 13 eller 14	15 miljoner euro	2.5 % av den globala årliga omsättningen
Andra skyldigheter: ofullständig teknisk dokumentation, saknad bedömning av överensstämmelse, felaktig CE-märkning, saknad SBOM	10 miljoner euro	2 % av den globala årliga omsättningen
Falsk, vilseledande eller ofullständig information till myndigheter	5 miljoner euro	1 % av den globala årliga omsättningen

Checklista för efterlevnad av kreditvärderingsförklaringar

CRA vill ha bevis på att cybersäkerhet är ägd, styrd och dokumenterad, inte ad hoc. Använd den här checklistan för att bedöma var organisationen står idag.

Riskbedömning

• En formell riskhanteringsprocess identifierar, övervakar och hanterar säkerhetsrisker med dokumenterade riskacceptanskriterier.
• En RACI-matris definierar riskägarskap, eskalering och beslutsfattande.
• Kryptografiska policyer överensstämmer med erkända standarder som NIST och FIPS.

Incidentrespons

• En dokumenterad incidenthanteringsplan definierar procedurer för detektering, inneslutning och återställning, och testas regelbundet.
• Programvaruförteckningar (SBOM) upprätthålls för att stödja snabb incidentprioritering och konsekvensanalys.

Dataskydd

• Kryptering skyddar känslig data i vila och under överföring, med hjälp av algoritmer som dokumenterats mot en aktuell standard.
• Programvaru- och dataintegritetskontroller, inklusive kodsignering, implementeras och granskas oberoende.

Rapporteringsskyldighet

• Tidsfrister, tröskelvärden och ansvarsområden för rapportering av artikel 14-anmälningar till Enisa är tydligt definierade och övade.
• SBOM:er och andra bevis på efterlevnad automatiseras där det är möjligt för att minska svarstid och fel.

Begränsningar

Denna guide är en utgångspunkt, inte en ersättning för en formell bedömning av överensstämmelse eller rättslig granskning. Några gränser är värda att tydligt ange. De harmoniserade standarder som CEN och CENELEC utarbetar kommer så småningom att ge tillverkare en presumtion om överensstämmelse för specifika tekniska kontroller. Tills dessa publiceras lämnar bedömningen mot bilaga I-texten direkt utrymme för olika tolkningar mellan tillverkare och anmälda organ. Produktkategoriexemplen i denna guide är illustrativa, inte en ersättning för den formella klassificeringsprocessen, som avgör vilken väg för bedömning av överensstämmelse som en specifik produkt måste följa. Om en produkt också faller under NIS2, DORA eller en sektorspecifik ordning, såsom medicintekniska förordningar, ersätter CRA inte dessa skyldigheter; den utökar dem, och överlappningen måste avstämmas från fall till fall. Slutligen återspeglar algoritm- och standardreferenser i denna guide det nuvarande NIST- och CA/Browser Forum-landskapet från och med augusti 2026. PQC-standarder och CA/B Forum-omröstningar fortsätter att utvecklas, så ett efterlevnadsprogram behöver en process för att spåra uppdateringar, inte en engångsläsning av denna artikel.

Vad skulle krypteringskonsulter rekommendera?

Börja med en gap-bedömning innan du köper några verktyg. Encryption Consultings Compliance Advisory- tjänst gör en detaljerad bedömning mot de specifika CRA-artiklarna och bilaga I-kraven som gäller för en produktkategori, och identifierar konkreta luckor som föråldrade protokoll, svag nyckelhantering eller felkonfigurerade TLS-inställningar snarare än en generisk mognadspoäng.

Specifikt för kravet på säker uppdatering och firmwaresignering är CodeSign Secure byggt för just denna kontroll: privata signeringsnycklar finns kvar i FIPS 140-2 nivå 3-certifierade HSM:er, M-of-N-godkännande förhindrar ensidig signering, varje signeringshändelse producerar en oföränderlig revisionslogg och hybridsignering stöder både klassiska algoritmer och postkvantumscheman som ML-DSA och LMS från samma signeringsinfrastruktur, så en tillverkare behöver inte bygga om pipelinen igen när de harmoniserade standarderna träder i kraft.

För att uppfylla kraven på konfidentialitet och integritet kring data i vila och under överföring tillhandahåller PKI-as-a-Service det hanterade certifikatet och den nyckelinfrastruktur som backar upp krypterade kanaler och enhetsidentitet utan en intern CA-utbyggnad, vilket är viktigast för tillverkare som behöver detta igång långt före rapporteringsfristen i september 2026, inte efter den.

En organisation som tillverkade IoT-enheter stod inför just denna kombination av brister: en delad signeringsnyckel, ingen spårbarhet mellan certifikat och utgåvor, och ingen återkallningsrutinbok. Integrering av HSM-baserad nyckelskydd, flerfaktorsautentisering för signeringsåtkomst och automatiserad CI/CD-signering täckte bristerna i integritet och åtkomstkontroll, medan manipulationssäker granskningsloggning och definierade procedurer för nyckelåterkallelse omedelbart uppfyllde kreditvärderingsmyndighetens krav på spårbarhet och sårbarhetshantering.

Slutsats

CRA sätter en ny baslinje: cybersäkerhet som ett kontinuerligt, dokumenterat ansvar över en produkts livscykel snarare än en kryssruta på lanseringsdagen. Rapporteringsfristen den 11 september 2026 kommer först och testar om en process för att avslöja sårbarheter faktiskt fungerar under press; fristen den 11 december 2027 testar allt annat, från säker design till noggrannhet i SBOM till signerade, granskningsbara uppdateringar. Tillverkare som behandlar algoritmval, nyckelhantering och uppdateringssignering som infrastruktur att bygga nu, snarare än pappersarbete att montera senare, är de som kommer att klara båda datumen utan krångel.

Vanliga frågor om partihandel med mat och dryck

När träder lagen om cybermotståndskraft egentligen i kraft?

CRA trädde i kraft den 10 december 2024. Skyldigheter att rapportera sårbarheter och incidenter enligt artikel 14 gäller från och med den 11 september 2026. Fullständig efterlevnad, inklusive CE-märkning, krävs senast den 11 december 2027. Det finns ingen ytterligare respitperiod efter dessa datum.

Kräver CRA en specifik krypteringsalgoritm?

Nej. Bilaga I, del I, kräver "största möjliga" kryptering för konfidentialitets- och integritetsskydd för data, kommandon och konfiguration, men den namnger inte specifika algoritmer. Tillverkare väljer och dokumenterar algoritmer som AES-256, TLS 1.3 och signaturscheman som är lämpliga för produktens begränsningar och förväntade livslängd, och det valet blir en del av den tekniska dokumentationen som en överensstämmelsebedömning granskar.

Är några produkter undantagna från CRA?

Produkter som redan lagligen släppts ut på EU-marknaden före den 11 december 2027 är i allmänhet undantagna från huvudkraven, såvida de inte genomgår en väsentlig modifiering efter det datumet. Vissa kategorier, såsom produkter som redan omfattas av sektorspecifika EU-förordningar för medicintekniska produkter, flyg eller fordon, följer separata undantag som definieras i förordningen. Artikel 14 om rapportering av sårbarheter och incidenter gäller fortfarande för produkter som omfattas av tillämpningsområdet oavsett detta undantag, från och med den 11 september 2026.

Hur relaterar CRA till NIS2 och DORA?

NIS2 och DORA styr cybersäkerhetsställningen och den operativa motståndskraften hos organisationer som driver kritisk infrastruktur och finansiella enheter. CRA styr de produkter som dessa och andra organisationer köper och använder. En bank som omfattas av DORA måste till exempel fortfarande bekräfta att de anslutna enheter och programvara som den köper uppfyller CRA-kraven; reglerna kompletterar varandra och är inte överlappande eller ersätter varandra.

Vilket är det största kryptografirelaterade misstaget som tillverkare gör när de förbereder sig inför CRA?

Att använda en enda delad signeringsnyckel för varje produktlinje. Det är den snabbaste vägen till efterlevnad och det värsta resultatet enligt artikel 14: en kompromiss med en enda nyckel tvingar fram en incidentanmälan som täcker hela portföljen på en gång, snarare än en enda produktlinje. Isolering av nyckel per produkt, genererad inuti en HSM, är den lösning som de flesta överensstämmelsesbedömningar ändå kräver.

Referensprojekt

• Europaparlamentets och rådets förordning (EU) 2024/2847, lagen om cyberresiliens, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• Europeiska kommissionen, lagen om cyberresiliens, Att forma Europas digitala framtid: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CRA-bilagorna I till VIII, Väsentliga krav och produktlistor: https://www.cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/
• Lagen om cybermotståndskraft, artikel 71, ikraftträdande och tillämpning: https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_71.html
• NIST SP 800-208, Rekommendation för Stateful Hash-baserade signaturscheman: https://csrc.nist.gov/pubs/sp/800/208/final
• NIST FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), slutförda augusti 2024: https://csrc.nist.gov/pubs/fips/204/final