Den 10 december 2024 trädde Europeiska unionens lag om cyberresiliens ( CRA ) i kraft som förordning (EU) 2024/2847. För första gången i historien blev cybersäkerhetskrav för produkter med digitala element rättsligt bindande inom EU:s inre marknad. Det var inte ett frivilligt ramverk, utan ett krav på marknadstillträde som backades upp av böter på upp till 15 miljoner euro eller 2.5 % av den globala årsomsättningen , beroende på vilket som är högst.
Från och med den 11 september 2026 måste tillverkare, importörer och distributörer aktivt rapportera utnyttjade sårbarheter och allvarliga säkerhetsincidenter till ENISA och nationella CSIRT-enheter. För organisationer som designar, tillverkar eller distribuerar uppkopplade enheter omdefinierar CRA vad det innebär att leverera en produkt.
Den här bloggen bryter ner vad CRA specifikt kräver av en kodsigneringsarkitektur , kopplar dessa krav till de tekniska kontroller som behövs för att uppfylla dem och förklarar varför organisationer som ännu inte har åtgärdat sin signeringsinfrastruktur har ont om tid att göra det innan varje efterlevnadsfrist går ut.
Vad lagen om cybermotståndskraft faktiskt kräver
CRA gäller alla ”produkter med digitala element” som släpps ut på EU-marknaden, en kategori som är tillräckligt bred för att omfatta praktiskt taget alla anslutna hårdvaruenheter och den programvara som körs på dem. Routrar, smarta hemenheter, medicinsk utrustning, industriella styrenheter, bärbara datorer, servrar, IoT-sensorer och den firmware som körs på alla dessa omfattas.
Förordningen bygger på en grundläggande princip: säkerhet genom design. Produkter måste utformas, utvecklas och underhållas på sätt som säkerställer deras cybersäkerhet under hela deras förväntade livslängd. Detta är inte en engångscertifiering, det är en kontinuerlig skyldighet som kvarstår under en supportperiod på minst fem år enligt artikel 13(8), eller den förväntade produktens livslängd om den är kortare.
Specifikt för kodsignering fastställer CRA flera skyldigheter som följer direkt av dess kärnkrav:
Programvarans och firmwareintegriteten måste skyddas genom hela leveranskedjan och produktens livslängd. Varje firmware-avbildning som levereras med en produkt och varje uppdatering som levereras till den måste kunna verifieras som autentisk och omodifierad. Detta kräver en kryptografisk signeringsinfrastruktur med påvisbara kontroller över vem som kan signera, vad som kan signeras och vilken revisionslogg som finns.
Säkra uppdateringsmekanismer krävs uttryckligen och enligt artikel 13 krävs det att tillverkare säkerställer att säkerhetsuppdateringar kan tillämpas automatiskt och inkluderar mekanismer för att verifiera uppdateringarnas äkthet. Ett uppdateringssystem utan verifiering av kryptografisk signatur uppfyller inte detta krav.
Samordnad sårbarhetsrapportering enligt artikel 14 innebär att tillverkare måste ha den operativa infrastrukturen för att identifiera vilka produktlinjer som påverkas av en given sårbarhet, meddela ENISA inom 24 timmar efter att ha blivit medvetna om en aktivt utnyttjad sårbarhet och lämna in en fullständig prioriteringsrapport inom 72 timmar.
Maskinläsbar SBOM krävs, som dokumenterar alla programvarukomponenter som ingår i produkten. För signeringsändamål innebär detta att proveniensen för varje firmwarekomponent måste vara spårbar och dokumenterbar.
Kartläggning av CRA-bilaga I till tekniska signeringskontroller
I bilaga I till CRA anges de specifika säkerhetskrav som produkter med digitala element måste uppfylla. För firmware och inbyggd programvara kan dessa krav direkt omsättas i konkreta tekniska kontroller.
| Krav i bilaga I till kreditvärderingsinstitutet | Artikelreferens | Nödvändig teknisk kontroll |
|---|---|---|
| Säkerhet genom design: hantera risker som är lämpliga för avsedd användning | Konst. 1 | Säker startkedja: oföränderliga BootROM/OTP-ankare med enhetsunika nycklar; varje startsteg verifieras kryptografiskt före körning |
| Data- och kodintegritet: skydda integriteten hos lagrade data, överförda data och körbara program | Artikel 2(f) | Firmware-signering: HSM-bundna nycklar signerar varje firmware-artefakt; SUIT/FIT/UEFI-manifest ger bevis på ursprung och manipuleringssäkring |
| Åtkomstkontroll: skydda mot obehörig åtkomst | Artikel 2(d) | M-of-N Signing Quorum: ingen enskild person signerar produktionsfirmware ensam; upprätthålls genom signeringsplattformen RBAC |
| Incidentreducering: minska effekterna av säkerhetsincidenter | Artikel 2(k) | Isolering av nyckel per produkt: ett intrång påverkar en produkt, inte en hel portfölj |
| Inga kända sårbarheter: produkter måste levereras utan kända sårbarheter som kan utnyttjas | Artikel 2(a) | Sårbarhetsskanning före signering: artefakter av firmware skannas mot kända CVE-databaser innan godkännande av signering |
| Minimerad attackyta: begränsa alla externa gränssnitt | Artikel 2(j) | Enhetscertifiering: DICE/TPM/PSA/TEE tillhandahåller körtidsbevis på att endast verifierad, omodifierad kod körs |
Nyckelisoleringsarkitektur
Den mest operativt betydande arkitekturförändringen som CRA kräver av de flesta organisationer är övergången från delad infrastruktur för signeringsnycklar till isolering av nyckel per produkt.
Den delade nyckelmodellen är standard för organisationer som har infört kodsignering utan formell styrning. En enda signeringsnyckel, kanske lagrad på en USB-token eller en byggserver, används för att signera firmware för varje produkt. Den är enkel att hantera och fungerar tekniskt sett. Enligt CRA är det ett strukturellt efterlevnadsbrott.
Här är anledningen till att skillnaden är viktig:
Delad nyckelarkitektur
Alla produktlinjer delar en enda signeringsnyckel. Om nyckeln är komprometterad:
- Varje produkt som signerats med den påverkas samtidigt
- Sprängningsradien täcker hela portföljen
- Artikel 14:s 24-timmars ENISA-anmälan måste omfatta alla berörda produkter samtidigt, utan möjlighet att avgränsa effekterna.
- Svar på efterlevnad: omöjligt inom 24 timmar utan register per produkt
Nyckelarkitektur per produkt
Varje produktlinje har sin egen dedikerade nyckel, genererad inuti och lagrad i en separat HSM- partition. Om en nyckel är komprometterad:
- Endast produkten som är kopplad till den nyckeln påverkas
- Sprängningsradien är begränsad till en enda produktlinje
- Artikel 14:s anmälan omfattar ett definierat område som kan besvaras exakt och snabbt.
- Svar på efterlevnad: revisionsloggen identifierar omedelbart berörda produkter, signeringshändelser och firmwareversioner
För en tillverkare med fyra produktlinjer innebär modellen med delade nyckelringar ett potentiellt förfarande för tillbakadragande från marknaden och åtgärdsskyldigheter för varje produkt samtidigt. Isolering per produkt innebär att en produkt påverkas, tre fortsätter att fungera normalt och att anmälan görs med precision snarare än panik.
Övergången till isolering av nyckel per produkt uppfyller också kreditvärderingsmyndighetens krav på ansvarsskyldighet i leveranskedjan enligt artikel 13 §5. Dokumentation för överensstämmelsebedömning för CE-märkning måste visa att varje produkts signeringsnyckel har sin egen styrning, åtkomstkontroller och revisionslogg.
Leverantörsneutral signering
En av de praktiska utmaningarna för tillverkare som arbetar mot efterlevnad av CRA-krav är mångfalden av kiselarkitekturer i sina produktportföljer. Ett företag som tillverkar både en konsumentrouter (ARM TrustZone), en smart apparat (MCU/IoT), en industriell styrenhet (RISC-V) och en serverprodukt (x86/UEFI) står inför fyra distinkta plattformsekosystem, vart och ett med olika signeringsverktygskedjor, olika firmwareformat (SUIT, FIT, UEFI-manifest) och olika hårdvarumekanismer för förtroende (ROT) (DICE, TPM, PSA, TEE).
Kreditvärderingsinstitutet bryr sig inte om denna komplexitet och kräver konsekventa, granskningsbara kontroller för varje produkt som omfattas. En leverantörsneutral signeringsarkitektur löser detta genom att frikoppla den plattformsspecifika signeringsverktygskedjan från policymotorn som styr den. Istället för att bygga fyra separata signeringsarbetsflöden med fyra separata nyckelhanteringsmetoder och fyra separata revisionsspår, tillämpar en centraliserad policymotor konsekvent styrning för alla plattformstyper, medan plattformsspecifika integrationer hanterar format- och protokolldetaljer för varje produkt.
Arkitekturlagren fungerar enligt följande:
Hårdvarubaserad förtroendenivå: FIPS 140-2-certifierade HSM:er tillhandahåller nyckellagring och signeringsåtgärder för alla plattformar. Stöd för ML-DSA och SLH-DSA säkerställer att kvantresistent signering är tillgänglig från samma infrastruktur som används för klassiska algoritmer.
Centraliserad policymotor: HSM-baserad signeringsstyrning tillämpar konsekventa RBAC, M-of-N-kvorumkrav och godkännandearbetsflöden över alla produktlinjer och alla plattformar. En ändring av signeringspolicyn träder i kraft överallt samtidigt.
CI/CD och revisionslager: Signering, attestering och generering av oföränderliga loggfiler under byggtid sker i pipeline-stadiet, vilket producerar den artefakt-hash, nyckel-ID, godkännaridentitet, pipeline-stadium och tidsstämpel som CRA:s revisionskrav kräver.
Kompatibla utdata: Varje plattform får den signerade firmware i sitt ursprungliga format med lämplig manifesttyp, SUIT för IoT/MCU, FIT för ARM/embedded Linux, UEFI-manifest för x86-serverplattformar och RISC-V-specifik attestering. ENISA-rapporteringsarbetsflödet får strukturerad, SRP-klar utdata som direkt stöder kravet på 24-timmarsavisering.
Denna arkitektur uppfyller CRA:s krav på konsekventa kontroller över produktlinjer utan att kräva ett separat efterlevnadsprogram för varje kiselplattform.
Hur Encryption Consultings CodeSign Secure hjälper
CodeSign Secure är Encryption Consultings plattform för kodsignering i företagsklass, utformad för att tillhandahålla de infrastrukturkontroller som CRA-efterlevnad kräver inom alla dimensioner som behandlas i den här bloggen.
HSM-baserad nyckelhantering: CodeSign Secure lagrar alla privata signeringsnycklar i FIPS 140-2 nivå 3-certifierade hårdvarusäkerhetsmoduler, integrerade med Thales Luna, Entrust nCipher, Utimaco, Securosys och moln-HSM:er från AWS och Azure. Produktspecifik isolering av nyckeln sker på HSM-partitionsnivå: varje produktlinje får sin egen dedikerade nyckel, genererad i hårdvaran och aldrig exporterad. Detta uppfyller direkt CRA:s krav på Hardware Root of Trust enligt artikel 13(1)(c) och kravet på isolering per produkt enligt artikel 13 §5.
M-of-N-signeringskvorum och RBAC: Plattformens rollbaserade åtkomstkontrollmodell tillämpar M-of-N-godkännandekrav för signering av produktionsfirmware. Ingen enskild individ kan initiera och godkänna en signeringsoperation. Signeringsförfrågningar, godkännanden och avslag loggas. Själva RBAC-konfigurationen är granskningsbar och versionskontrollerad, vilket ger den dokumenterade signeringspolicy som CRA-överensstämmelsesbedömningar kräver.
Oföränderlig granskningsloggning: Varje signeringshändelse i CodeSign Secure genererar en oföränderlig loggpost som registrerar artefaktens hash, nyckelidentifieraren, det använda certifikatet, den godkännande identiteten och RFC 3161-tidsstämpeln. Loggarna är centraliserade och lagras separat från signeringsinfrastrukturen.
Stöd för firmwareformat över flera plattformar: CodeSign Secure stöder signering av firmwareartefakter över hela spektrumet av format som en varierad produktportfölj kräver: .bin, .img, .hex, .fw, .dfu och .efi, vilket uppfyller CRA:s krav på konsekventa kontroller över produktlinjer utan att behöva bygga om signeringsinfrastrukturen för varje plattform.
Stöd för postkvantkryptografi: CodeSign Secure v3.02 stöder ML-DSA i produktionsklass (FIPS 204, på säkerhetsnivåerna ML-DSA-44, ML-DSA-65 och ML-DSA-87) och SLH-DSA (FIPS 205) som avtagbara signaturer tillsammans med klassiska algoritmer. För tillverkare som bygger produkter med CRA-supportskyldigheter på över fem år är PQC-signering idag den arkitektur som skyddar mot HNDL-hotet innan en CRQC anländer.
CI/CD-pipelineintegration: CodeSign Secure integreras med Azure DevOps, Jenkins, GitLab CI och andra större pipelineplattformar via API- och kommandoradsgränssnitt. Firmware-signering är ett kontrollerat, policystyrt steg i byggpipelinen, inte ett manuellt steg.
Slutsats
Cyber Resilience Act har flyttat firmware-signering från bästa säkerhetspraxis till en rättslig skyldighet med tänder. Den första milstolpen för verkställighet, artikel 14:s krav på rapportering av incidenter och sårbarheter, träder i kraft den 11 september 2026. Fullständig efterlevnad inklusive CE-märkning krävs senast den 11 december 2027. Och den infrastruktur som behövs för att stödja båda dessa tidsfrister, isolering av produktnyckel, HSM-baserad signering, M-of-N-kvorum, 10-åriga revisionsloggar och sårbarhetsstyrda signeringsarbetsflöden, tar 12 till 18 månader att utforma och implementera korrekt.
De organisationer som är bäst positionerade för efterlevnad av CRA-regler är inte de som kommer att börja bygga sin signeringsarkitektur när december 2027 kommer. Det är de som bygger den nu, innan rapporteringsskyldigheterna från september 2026 avslöjar luckorna i deras nuvarande infrastruktur.
På Encryption Consulting tillhandahåller CodeSign Secure den signeringsinfrastruktur som CRA-efterlevnad kräver, från HSM-baserad nyckelisolering till oföränderliga revisionsspår till postkvantumsignering som åtgärdar HNDL-hotet inom CRA:s supportfönster.
