Hoppa till innehåll

Webinar: Registrera dig för vårt kommande webbinarium

Registrera nu

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

Beskrivning

Cyberresilienslagen (förordning (EU) 2024/2847) är en EU-lag som fastställer cybersäkerhetsregler för produkter som innehåller digitala komponenter, vilka kan vara hårdvara eller mjukvara.

Cyberresilienslagen (CRA) bygger på en princip: Endast säkra produkter bör tillåtas på EU-marknaden.

För att genomföra denna princip, Artikel 6 i förordningen anges två viktiga pelare för efterlevnad:

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

En produkt kan endast anses vara kompatibel om:

Den uppfyller de grundläggande cybersäkerhetskraven som anges i Bilaga I, del I.

  • Den är korrekt installerad, underhållen och uppdaterad av användaren eller operatören.

Med andra ord måste produkten vara i grunden säker och fortsätta att fungera säkert när den används som avsett.

Det finns fyra produktkategorier under CRA enligt följande:

  • StandardkategoriDetta inkluderar de flesta produkter som inte uttryckligen listas i andra kategorier (cirka 90 % av alla produkter med digitala element). Exempel inkluderar allmän konsumentelektronik som smarta högtalare, hårddiskar och grundläggande fotoredigeringsprogram.
  • Viktiga produkter Klass IDessa produkter utför funktioner som är avgörande för cybersäkerhet, såsom identitetshanteringssystem, webbläsare, lösenordshanterare, VPN-programvara och smarta säkerhetsenheter för hemmet (t.ex. smarta lås, kameror).
  • Viktiga produkter Klass IIDenna klass omfattar produkter med högre risk än Klass I, såsom brandväggar, system för intrångsdetektering/förebyggande av intrång för industriellt bruk, hypervisorer och manipuleringssäkra mikroprocessorer.
  • Kritiska produkterDessa är produkterna med högst risk, som anses vara kritiska eftersom viktiga enheter är beroende av dem och deras kompromettering kan orsaka omfattande störningar. Exempel inkluderar säkra element i smartkort 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 slutliga enheten; det handlar om hur den är tillverkad och har support. Enligt Bilaga I, del II, måste tillverkarna:

  • Ha en process för hantering av sårbarheter, inklusive att ta emot, bedöma och åtgärda säkerhetsproblem.
  • Följ säkra utvecklingspraxis under hela produktens livscykel.
  • Tillhandahålla uppdateringar och underhålla produktens säkerhet över tid.

CRA går utöver att bara kontrollera en produkt en gång innan den kommer ut på marknaden. Det kräver kontinuerlig säkerhet under hela produktens livslängd. Därför måste produkten vara säkert byggd, och tillverkaren måste fortsätta att stödja den med säkerhetsuppdateringar, övervakning och förbättringar.

Så efterlevnad av CRA-regler är inte något man bara sätter igång och glömmer, utan ett långsiktigt, strategiskt och taktiskt initiativ för att säkerställa att säkerhet är inbyggd i både produkten och processerna bakom den.

Vem behöver följa CRA?

När det står ”alla tillverkare inom eller utanför EU som säljer produkter med digitala element i Europa” menar det:

  • EU-tillverkare

    Företag baserade inom EU som tillverkar produkter med programvara/firmware och säljer dem i EU.

  • Tillverkare utanför EU

    Företag baserade utanför EU (till exempel i USA, Kina etc.) som:

    • sälja direkt på EU-marknaden, eller
    • sälja via EU-distributörer/importörer.

Om produkten hamnar på EU-marknaden gäller kreditvärderingsföretaget, oavsett var företaget är beläget. Så du kan inte undvika kreditvärderingsföretaget bara för att ditt huvudkontor ligger utanför EU, eller för att du säljer via online-marknadsplatser; om EU-kunder kan köpa den omfattas du av avtalet.

Typer av produkter som omfattas

CRA omfattar programvara och firmware som körs på eller levereras med anslutna enheter. Detta inkluderar enheters operativsystem, inbäddad firmware, mobilappar som används för att styra IoT-produkter, verktyg för skrivbordshantering och molnbaserade gränssnitt som interagerar med dessa enheter. Om programvaran är en del av produktens funktionalitet eller påverkar dess säkerhet, omfattas den av CRA:s krav.

CRA inkluderar IoT och inbyggda enheter, vilka är produkter som innehåller programvara eller firmware och vanligtvis används i hem, hälso- och sjukvårdsmiljöer och industriella miljöer.

Det gäller även industriell styr- och automationsutrustning, som spelar en avgörande roll i fabriker och kritisk infrastruktur.

En annan viktig kategori är konsumentelektronik, som inkluderar smarta enheter för vardagsbruk som bärbara datorer, smarta apparater, hemunderhållningssystem och uppkopplade säkerhetslösningar.

Klockan tickar för tillverkarna

Eftersom CRA tillämpas enligt en strikt tidsram måste tillverkare och leverantörer se till att de är uppdaterade. Nedan följer en kort översikt över de viktigaste milstolparna.

10 december 2024, CRA träder i kraft

Detta datum trädde CRA officiellt i kraft. Detta gör inte innebär att alla krav måste uppfyllas omedelbart, men det markerar början på nedräkningen. Från och med denna tidpunkt förväntas tillverkare, importörer och distributörer börja förbereda sina processer, dokumentation och system för efterlevnad.

Skräddarsydda rådgivningstjänster

Vi utvärderar, strategiserar och implementerar krypteringsstrategier och lösningar anpassade efter era behov.

11 september 2026, Skyldigheten att rapportera sårbarheter börjar gälla

Nästan två år senare träder de första obligatoriska skyldigheterna i kraft:

  • Tillverkare måste börja rapportera aktivt utnyttjade sårbarheter och incidenter till EU-myndigheter inom de angivna tidsramarna.
  • De måste redan ha en grundläggande process för hantering och rapportering av sårbarheter på plats.
  • Denna fas fokuserar på transparens och tidig varning, redan innan fullständig produktöverensstämmelse krävs.

Detta är i huvudsak den "mjuka starten" för CRA, där organisationer måste visa att de kan hantera och kommunicera säkerhetsproblem på rätt sätt.

11 december 2027, Fullständig efterlevnad krävs

Detta är den stora deadline. Senast detta datum måste alla produkter med digitala element som släpps ut på EU-marknaden helt uppfylla kreditvärderingsmyndighetens krav, inklusive:

  • Säker genom design och säker genom standardutveckling
  • Skapande och underhåll av SBOM
  • Korrekta processer för sårbarhetshantering
  • Mekanismer för säkerhetsuppdateringar
  • Dokumentation och CE-märkning relaterad till cybersäkerhet

Från och med detta datum får produkter som inte uppfyller kraven inte lagligt säljas i EU.

Produkter med digitala element som lagligen har släppts ut på EU-marknaden före den 11 december 2027 är i allmänhet undantagna från de huvudsakliga kraven i CRA. Detta undantag gäller endast så länge produkten inte genomgår en "väsentlig modifiering" efter den 11 december 2027. Om en produkt väsentligt modifieras efter detta datum måste den uppfylla alla CRA-krav, och den enhet som gör modifieringen blir tillverkare i CRA-syfte.

Ett viktigt undantag från det allmänna undantaget är att skyldigheterna gällande rapportering av sårbarheter och incidenter (artikel 14) do gäller alla produkter som omfattas av förordningens tillämpningsområde, inklusive de som släpptes ut på marknaden före den 11 december 2027. Dessa rapporteringsskyldigheter blir obligatoriska från och med den 11 september 2026. 

Nu ska vi förstå CRA-kraven i detalj:

Krav för kreditvärderingsinstitut förklarade

CRA definierar specifika säkerhetsförväntningar för produkter med digitala element. Dessa är indelade i två huvuddelar:

Del I – Cybersäkerhetskrav avseende egenskaper hos produkter med digitala element

KravKrav förklaratHur man uppnår kravet
Del I.1 – Säker genom designProdukter måste designas och byggas med säkerhet som är lämplig i förhållande till deras risker, med början från tidig utveckling.Genomför riskbedömningar, tillämpa säker utvecklingslivscykel (SDL), minimera attackytan, använd säkra kodningsrutiner och inkludera säkerhetskontroller för hårdvara/mjukvara.
Del I.2(a) – Inga kända sårbarheter som kan utnyttjasProdukter får inte släppas med sårbarheter som redan är allmänt kända eller internt kända.Utför sårbarhetsskanning, penetrationstester, statisk/dynamisk kodanalys, SBOM-granskning och åtgärda problem före lansering.
Del I.2(b) – Säker standardkonfigurationProdukter måste levereras med säkerhetsinställningar aktiverade som standard och tillåta fabriksåterställning.Inaktivera onödiga tjänster, tillämpa starka standardinloggningsuppgifter eller inga alls, använd säkra protokoll, säkerställ återställning till fabriksinställningar och förstärk systemkonfigurationer.
Del I.2(c) – Säkerhetsuppdateringar i rätt tidProdukter måste ha stöd för säkerhetsuppdateringar, helst automatiska, med alternativ för avanmälan, aviseringar och uppskjutning.Implementera starka uppdateringsmekanismer, säker uppdateringsleverans, uppdateringssignering, användarmeddelanden och automatiserad sårbarhetsövervakning.
Del I.2(d) – Skydd mot obehörig åtkomstEnheter måste förhindra obehörig åtkomst och upptäcka/rapportera försök.Använd stark autentisering, identitets- och åtkomsthantering, rollbaserad åtkomstkontroll, loggning och säker lagring av autentiseringsuppgifter.
Del I.2(e) – DatasekretessEnheter måste skydda lagrade och överförda data, ofta med hjälp av krypteringImplementera kryptering för data under överföring och data i vila, säker nyckelhantering och tillämpa moderna kryptografiska standarder.
Del I.2(f) – Data- och kommandointegritetEnheter måste skydda data, kommandon och konfiguration från obehöriga ändringar och upptäcka korruption.Använda digitala signaturer, kontrollsummor, signerade uppdateringar, autentiserad kommunikation och övervakning av dataintegritet.
Del I.2(g) – DataminimeringEnheter får endast samla in den lägsta mängd data som krävs för sitt avsedda ändamål.Granska dataflöden från ingångspunkten till utgångspunkten, ta bort redundans och dokumentera begränsningar för syftet.
Del I.2(h) – Tillgänglighet av väsentliga funktionerKritiska funktioner måste förbli funktionella även efter en incident, inklusive motståndskraft mot överbelastning.Implementera redundans, felsäkra lägen, hastighetsbegränsning, DoS-skydd och definiera återställningsåtgärder efter incidenter.
Del I.2(i) – Minimera negativ påverkan på nätverkEnheter får inte försämra eller skada tillgängligheten för andra nätverksanslutna system.Implementera bandbreddskontroller, resursisolering, beteendeövervakning och säkra kommunikationspraxis.
Del I.2(j) – Minskning av attackytanEnheter måste minimera externa gränssnitt för att minska möjliga inträdespunkter för angripare.Ta bort oanvända portar/tjänster, använd modulär design, begränsa API:er och tillämpa säkra standardinställningar för konfiguration.
Del I.2(k) – Mildrande åtgärder mot incidenters påverkanEnheter måste innefatta åtgärder som begränsar skador orsakade av säkerhetsincidenter.Genomför konsekvensbedömningar och omedelbara åtgärdsmekanismer för incidenter.
Del I.2(l) – Övervakning av säkerhetshändelserEnheter måste registrera viktiga säkerhetshändelser och tillåta övervakning, med alternativ för användare att välja bort.Implementera loggning, revisionsloggar, händelserapportering, säker logglagring och övervakning.
Del I.2(m) – Säker dataradering och överföringAnvändare måste kunna radera data säkert och permanent, och all dataöverföring måste ske på ett säkert sätt.Tillhandahåll krypterad lagringsradering, skyddade arbetsflöden för dataexport och tydliga användarkontroller.

Del II – Krav för hantering av sårbarheter

KravKrav förklaratHur man uppnår kravet
Del II.1 – SBOM och komponentspårningTillverkare måste identifiera och dokumentera alla programvarukomponenter och sårbarheter i sina produkter, inklusive att generera en programvaruförteckning (SBOM).Utför kryptografisk identifiering och underhåll detaljerad inventering, utför sårbarhetsskanningar, håll komponentinventarier uppdaterade och övervaka tredjepartsbibliotek för nya CVE:er.
Del II.2 – Snabb åtgärd av sårbarheter  Tillverkare måste åtgärda sårbarheter snabbt och tillhandahålla säkerhetsuppdateringar i tid. Säkerhetsfixar bör vara separata från funktionsuppdateringar när det är möjligt.Upprätta ett program för sårbarhetsbedömning, prioritera åtgärder baserat på risk, släpp snabba säkerhetsuppdateringar, använd CI / CD för snabb leverans och separera säkerhetsuppdateringar från funktionsuppdateringar.
Del II.3 – Regelbunden säkerhetstestningTillverkare måste utföra kontinuerliga säkerhetstester och säkerhetsgranskningar under hela produktens livscykel.Genomför regelbundna penetrationstester, statisk/dynamisk analys, fuzzing, kodgranskningar och kontinuerliga säkerhetsbedömningar före och efter produktlansering.
Del II.4 – Offentliggörande av sårbarhetNär en patch blir tillgänglig måste tillverkare offentliggöra tydlig information om de åtgärdade sårbarheterna, såvida det inte finns en berättigad säkerhetsskäl att fördröja offentliggörandet.För tillverkare - Meddela användare om patchar, ange allvarlighetsgrad, beskriv effekter och dokumentera åtgärdssteg.
Del II.5 – Samordnad policy för sårbarhetsrapportering (CVD)Tillverkare måste upprätta och tillämpa en formell policy som vägleder hur externa forskare kan rapportera sårbarheter.För tillverkning - Skapa en offentlig policy för hjärt-kärlsjukdomar, definiera intagsprocesser, sätt tidslinjer för triage, bekräfta rapporter och samordna kommunikationen mellan forskare och interna team.
Del II.6 – Dela information om potentiell sårbarhetTillverkare måste göra det enkelt att rapportera sårbarheter och dela information om potentiella svagheter i både sin egen programvara och tredjepartskomponenter.Före Tillverkare – Tillhandahåll en dedikerad säkerhetskontakt eller e-postadress, använd plattformar för insamling av sårbarheter, dela råd med partners, övervaka säkerhetskanaler från tredje part och uppmuntra till ansvarsfullt avslöjande.
Del II.7 – Säker distribution av uppdateringarTillverkare måste distribuera uppdateringar på ett säkert sätt som säkerställer att sårbarheter kan åtgärdas snabbt och säkert, inklusive stöd för automatiska uppdateringar där så är lämpligt.För tillverkare – Använd signerade uppdateringar, krypterade leveranskanaler, säkra OTA-mekanismer (over-the-air), integritetskontroller av uppdateringar och automatiserade distributionspipelines.
Del II.8 – Säkerhetsuppdateringar i tid och utan kostnadSäkerhetsuppdateringar måste levereras snabbt och utan extra kostnad (förutom vid anpassade affärsavtal). Uppdateringar måste innehålla tydliga rådgivande meddelanden.Publicera uppdateringar snabbt, meddela användarna omedelbart, tillhandahåll kostnadsfria säkerhetsfixar, inkludera dokumentation som förklarar effekter och rekommenderade åtgärder och säkerställ enkel installation.

Insats för bristande efterlevnad

Att inte uppfylla CRA:s krav får allvarliga konsekvenser för tillverkare och alla som släpper ut produkter med digitala element på EU-marknaden. Produkter som inte uppfyller kraven kan tas bort från försäljning, företag kan bli skyldiga att omdesigna eller åtgärda sina enheter, och den skada som drabbar deras anseende kan bli allvarlig. Eftersom cybersäkerhetsincidenter kan äventyra individer, branscher och kritisk infrastruktur, behandlar CRA efterlevnad som en högprioriterad skyldighet.

Utöver att förlora marknadstillträde riskerar företag betydande ekonomiska påföljder. CRA-lagen inkluderar ett strikt verkställighetssystem som är utformat för att motivera organisationer att prioritera cybersäkerhet, produktsäkerhet och livscykelhantering.

Artikel 64 i CRA ger myndigheter både administrativa böter och korrigerande verkställighetsbefogenheter. Marknadsövervakningsmyndigheterna kan inte bara utfärda böter utan också:

  • beordra att produkter ska dras tillbaka från marknaden,
  • begränsa eller förbjuda ytterligare försäljning, och
  • kräva att tillverkare reparerar eller omdesignar en produkt innan den kan säljas igen.

Dessa befogenheter gäller när en produkt utgör säkerhetsrisker eller inte uppfyller kreditvärderingsinstitutets väsentliga krav.

Maximala finnivåer

Skatteverket använder ett system med nivåer för böter, där böterna beror på:

  • vem som begått överträdelsen (tillverkare, importör, distributör etc.), och
  • hur allvarlig överträdelsen är (säkerhetsrelaterad kontra administrativ).

Nedan följer de tre huvudsakliga böteskategorierna.

Upp till 15 miljoner euro eller 2.5 % av den globala omsättningen

Detta är den högsta straffnivån och gäller främst tillverkare, de som ytterst ansvarar för produktsäkerheten. Ett företag kan få böter om det inte följer något av följande:

  • Grundläggande krav på cybersäkerhet (krav i bilaga I)
  • Skyldigheter att anmäla incidenter
  • Skyldigheter för rapportering av sårbarheter
  • Andra kärnansvar definieras i CRA

Eftersom dessa fel direkt påverkar användarsäkerhet och cybersäkerhetsrisker, medför de de strängaste sanktionerna.

Upp till 10 miljoner euro eller upp till 2 % av den globala årsomsättningen (beroende på vilket som är högst) 

Denna kategori gäller när företag inte uppfyller procedur- eller efterlevnadsskyldigheter, även om produkten i sig inte är aktivt osäker. Vanliga fel som leder till denna påföljd är: 

  • Saknad eller ofullständig teknisk dokumentation 
  • Underlåtenhet att utföra eller dokumentera överensstämmelsesbedömningar 
  • Felaktig eller saknad CE-märkning 
  • Att inte underhålla nödvändig programvaruförteckning (SBOM) 
  • Svaga interna processer för efterlevnadsövervakning 

EU förlitar sig på dokumentation och bevis på överensstämmelse att upprätthålla cybersäkerhet i stor skala. Om revisorer inte kan verifiera efterlevnaden blir verkställighet omöjlig. 

Upp till 5 miljoner euro eller 1 % av den globala årsomsättningen (beroende på vilket som är högst) 

Detta är den lägsta nivån av straff och den gäller när en organisation gör följande: 

  • Ger falsk, vilseledande eller ofullständig information 
  • Undanhåller begärda uppgifter från marknadsövervakningsmyndigheter 
  • Felaktigt framställer cybersäkerhetskontroller eller testresultat 

Detta inkluderar avsiktligt vilseledande ELLER oaktsamma felaktigheter. 

Checklista för efterlevnad av kreditvärderingsregler på hög nivå

CRA vill inte bara att "säkerhetsarbete ska ske". Det vill ha bevis på att cybersäkerhet är ägd, styrd och detaljerad, inte ad hoc. Om ingen är tydligt ansvarig kan tillverkaren inte på ett tillförlitligt sätt "genomföra en bedömning" under hela livscykeln. Nedan följer en checklista för att säkerställa en snabb självbedömning för att säkerställa var din organisation står för närvarande:

Riskbedömning

  • Säkerställ att en riskbedömning för dataskydd har genomförts, inklusive riskidentifiering, analys och prioritering av risker.
  • Säkerställ att det finns en formell riskhanteringsprocess för att identifiera, övervaka och hantera säkerhetsrisker.
  • Säkerställ att risker prioriteras baserat på sannolikhet och påverkan, med dokumenterade kriterier för riskacceptans.
  • Se till att en RACI-matris är definierad för riskägarskap, eskalering och beslutsfattande.
  • Säkerställ att policyer och rutiner för säkerhetsriskhantering är dokumenterade, uppdaterade och godkända.
  • Säkerställ att kryptografiska policyer är i linje med tillämpliga regulatoriska och branschledande standarder, såsom NIST, FIPS, GDPREtc.
  • Säkerställ att kontinuerliga övervakningsprocesser finns på plats för kritiska IKT-system och tjänster.

Incidentrespons

  • Säkerställ att en incidenthanteringsplan och en kontinuitetsplan är formellt dokumenterade och godkända.
  • Säkerställ att det finns fördefinierade procedurer för att upptäcka, reagera på, begränsa och återhämta sig från cyberincidenter.
  • Se till att roller och ansvar för incidenthantering är tydligt definierade.
  • Se till att incidenthanteringsplanen testas regelbundet.
  • Säkerställ att lärdomar från incidenttester eller verkliga incidenter dokumenteras och åtgärdas.
  • Se till Programvaruförteckningar (SBOM) samlas in och underhålls för att stödja snabb incidentprioritering och konsekvensanalys.

Dataskydd

  • Säkerställ att känsliga och personuppgifter, såsom PII, PHI och PCI-data, klassificeras enligt sekretess- och myndighetskrav.
  • Säkerställ att kontroller finns på plats för att skydda datakonfidentialitet, integritet och tillgänglighet (CIA).
  • Se till att kryptering används för känslig data i vila och under överföring.
  • Säkerställ att det finns mekanismer för att upptäcka, reagera på och begränsa dataintrång.
  • Säkerställ att programvaru- och dataintegritetskontroller implementeras (t.ex. kontrollsummor, kodsignering).
  • Säkerställ att regelbundna säkerhetsrevisioner och bedömningar genomförs för att validera efterlevnaden av interna policyer och branschstandarder.

Rapporteringsskyldighet

  • Säkerställ att åtkomstkontroller tillämpar principerna för lägsta behörighet med hjälp av RBAC eller IAM.
  • Säkerställ att alla programvaru- och cybersäkerhetsincidenter dokumenteras konsekvent.
  • Säkerställ att incidenter rapporteras i enlighet med lagstadgade och regelmässiga krav.
  • Se till att tidslinjer, tröskelvärden och ansvarsområden för rapportering är tydligt definierade.
  • Säkerställ att SBOM:er och andra efterlevnadsdokument framställs och underhålls.
  • Säkerställ att rapportering och bevisgenerering automatiseras där det är möjligt för att minska svarstid och fel.

Hur krypteringskonsulting kan hjälpa

Krypteringskonsulttjänster erbjuder skräddarsydda rådgivningstjänster för att hjälpa ditt företag att effektivt och säkert uppfylla specifika efterlevnadskrav från kreditvärderingsinstitut. Genom detaljerade bedömningar baserade på krav och relevanta artiklar om kreditvärderingsinstitutsstandarder identifierar vi svagheter som föråldrade protokoll, svag nyckelhantering eller felkonfigurerade SSL/TLS-inställningar. Att åtgärda dessa problem stärker din krypteringsarkitektur och stöder kontinuerlig efterlevnad. 

Krypteringskonsulttjänster CodeSign Secure, en omfattande kodsigneringslösning i företagsklass, utformad för att hjälpa organisationer att uppfylla strikta cybersäkerhetskrav som de som föreskrivs av EU:s kreditvärderingsmyndighet. 

CodeSign Secure adresserar viktiga utmaningar inom efterlevnad av kreditvärderingsregler genom att tillhandahålla: 

  • HSM-baserad nyckelskyddPrivata signeringsnycklar förvaras säkert i FIPS 140-2 nivå 3-certifierade HSM:er, vilket säkerställer noll risk för nyckelexponering eller stöld, helt i linje med branschkrav och bästa praxis som är avgörande för efterlevnad av kreditvärderingsregler. 
  • Automatisering och CI/CD-integrationLösningen integreras sömlöst med populära DevOps-pipelines och automatiserade byggarbetsflöden, vilket säkerställer att säkerhet aldrig hindrar utvecklingshastighet eller innovation. 
  • Policytillämpning och detaljerad åtkomstkontrollOrganisationer kan definiera och tillämpa detaljerade säkerhetspolicyer, automatisera signeringsbehörigheter och kontrollera hanteringen av signeringslivscykeln i olika team, vilket stöder CRA:s revisions- och ansvarskrav. 
  • Omfattande revisionsspårDetaljerad händelseloggning, godkännanden på flera nivåer och kvorumkontroller säkerställer att varje signeringsåtgärd spåras, valideras och uppfyller kraven, vilket förenklar kreditvärderingsinstitutens överensstämmelsebedömningar. 
  • Skalbara distributionsmodellerEncryption Consulting stöder moln-, hybrid- och lokala implementeringar, vilket gör det möjligt för organisationer av alla storlekar att implementera robust kodsignering utan onödiga infrastrukturkostnader. 
  • Stöd för hybridsigneringsalgoritmer (traditionella och PQC): Vi möjliggör användning av både traditionella kryptografiska algoritmer som RSA och ECC (ECDSA) och postkvantkryptering (PQC) algoritmer som ML-KEM, ML-DSA, LMSoch mer i hybridsigneringsarbetsflöden. Detta säkerställer långsiktig motståndskraft för digitala signaturer mot framväxande kvanthot. 

Skräddarsydda rådgivningstjänster

Vi utvärderar, strategiserar och implementerar krypteringsstrategier och lösningar anpassade efter era behov.

En organisation som tillverkade IoT-enheter stod inför utmaningar med efterlevnad av CRA-regler, särskilt när det gällde att säkert hantera kodsigneringsnycklar och visa spårbarhet för varje release. Vi åtgärdade dessa problem genom att integrera HSM i deras miljö för nyckelskydd, vilket möjliggör flerfaktorsautentisering för åtkomst och automatiserar kodsignering i deras CI/CD-pipeline. Manipulationssäker revisionsloggning aktiverades också för att uppfylla CRA:s strikta spårbarhets- och dokumentationskrav. Samtidigt säkerställde starka nyckelåterkallningsprocedurer att alla komprometterade nycklar snabbt kunde ogiltigförklaras, vilket var avgörande för CRA:s sårbarhetshantering och incidenter. 

Slutsats

CRA sätter en ny baslinje för säkerhet och kräver att tillverkare behandlar cybersäkerhet som ett kontinuerligt ansvar under hela en produkts livscykel. Genom att anamma säker design, proaktiv sårbarhetshantering och transparent rapportering kan organisationer skydda användare samtidigt som de bibehåller tillgången till EU-marknaden.

Referens - http://cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/