Op 10 december 2024 is de Europese Unie-verordening inzake cyberveiligheid (Cyber ​​Resilience Act, CRA ) in werking getreden als Verordening (EU) 2024/2847. Voor het eerst in de geschiedenis zijn de cybersecurity-eisen voor producten met digitale elementen wettelijk bindend geworden voor de gehele interne markt van de EU. Het betreft geen vrijwillig kader meer, maar een markttoegangseis die kan leiden tot boetes van maximaal 15 miljoen euro of 2.5% van de wereldwijde jaaromzet , afhankelijk van welk bedrag hoger is.
Vanaf 11 september 2026 moeten fabrikanten, importeurs en distributeurs actief melding maken van misbruikte kwetsbaarheden en ernstige beveiligingsincidenten aan ENISA en nationale CSIRT's. Voor organisaties die verbonden apparaten ontwerpen, produceren of distribueren, herdefinieert de CRA wat het betekent om een ​​product te verzenden.
Deze blog beschrijft de specifieke eisen van de CRA (Canada Revenue Agency) aan een architectuur voor codeondertekening , koppelt deze eisen aan de technische beheersmaatregelen die nodig zijn om eraan te voldoen, en legt uit waarom organisaties die hun infrastructuur voor codeondertekening nog niet op orde hebben, steeds minder tijd hebben om dit te doen vóór elke nieuwe deadline voor naleving.
Wat de Cyber ​​Resilience Act daadwerkelijk vereist
De CRA is van toepassing op elk "product met digitale elementen" dat op de EU-markt wordt gebracht, een categorie die breed genoeg is om vrijwel elk verbonden hardwareapparaat en de daarop draaiende software te omvatten. Routers, slimme apparaten voor thuisgebruik, medische apparatuur, industriële controllers, laptops, servers, IoT-sensoren en de firmware die op al deze apparaten draait, vallen onder de CRA.
De regelgeving is gebaseerd op een fundamenteel principe: beveiliging door ontwerp. Producten moeten zodanig worden ontworpen, ontwikkeld en onderhouden dat hun cyberbeveiliging gedurende hun verwachte levensduur gewaarborgd is. Dit is geen eenmalige certificering, maar een doorlopende verplichting die van kracht blijft gedurende een minimale ondersteuningsperiode van vijf jaar volgens artikel 13(8), of gedurende de verwachte levensduur van het product indien deze korter is.
Wat betreft het ondertekenen van codes, legt de CRA specifiek een aantal verplichtingen op die rechtstreeks voortvloeien uit de kernvereisten:
De integriteit van software en firmware moet gedurende de gehele toeleveringsketen en de operationele levensduur van het product worden beschermd. Elke firmware-image die met een product wordt meegeleverd en elke update die ervoor wordt geleverd, moet aantoonbaar authentiek en ongewijzigd zijn. Dit vereist een infrastructuur voor cryptografische ondertekening met aantoonbare controle over wie mag ondertekenen, wat er ondertekend mag worden en welk auditspoor er bestaat.
Er zijn expliciet veilige update-mechanismen vereist en volgens artikel 13 zijn fabrikanten verplicht ervoor te zorgen dat beveiligingsupdates automatisch kunnen worden toegepast en dat er mechanismen zijn om de authenticiteit van de update te verifiëren. Een updatesysteem zonder cryptografische handtekeningverificatie voldoet niet aan deze eis.
Gecoördineerde openbaarmaking van kwetsbaarheden onder artikel 14 betekent dat fabrikanten over de operationele infrastructuur moeten beschikken om te identificeren welke productlijnen door een bepaalde kwetsbaarheid worden getroffen, ENISA binnen 24 uur op de hoogte moeten stellen van een actief misbruikte kwetsbaarheid en binnen 72 uur een volledig triagerapport moeten indienen.
Een machineleesbare SBOM is vereist, waarin alle softwarecomponenten van het product zijn gedocumenteerd. Voor ondertekeningsdoeleinden betekent dit dat de herkomst van elke firmwarecomponent traceerbaar en documenteerbaar moet zijn.
Het in kaart brengen van CRA Bijlage I naar technische ondertekeningscontroles
Bijlage I van de CRA beschrijft de specifieke beveiligingsvereisten waaraan producten met digitale elementen moeten voldoen. Voor firmware en embedded software vertalen deze vereisten zich direct in concrete technische controles.
| CRA Bijlage I Vereiste | Artikelreferentie | Vereiste technische controle |
|---|---|---|
| Beveiliging door ontwerp: pak risico's aan die passen bij het beoogde gebruik. | Art 1 | Beveiligde opstartketen: onveranderlijke BootROM/OTP-ankers met apparaatspecifieke sleutels; elke opstartfase wordt cryptografisch geverifieerd vóór uitvoering. |
| Integriteit van gegevens en code: bescherm de integriteit van opgeslagen gegevens, verzonden gegevens en uitvoerbare programma's. | Art. 2(f) | Firmwareondertekening: HSM-gebonden sleutels ondertekenen elk firmware-artefact; SUIT/FIT/UEFI-manifesten leveren bewijs van herkomst en bewijs van manipulatie. |
| Toegangscontrole: bescherming tegen ongeautoriseerde toegang | Art. 2(d) | M-of-N ondertekeningsquorum: niemand ondertekent de productiefirmware alleen; dit wordt afgedwongen via RBAC (Role-Based Access Control) van het ondertekeningsplatform. |
| Incidentbeperking: de impact van beveiligingsincidenten verminderen. | Art. 2(k) | Sleutelisolatie per product: één inbreuk treft één product, niet het hele portfolio. |
| Geen bekende kwetsbaarheden: producten moeten worden geleverd zonder bekende exploiteerbare kwetsbaarheden. | Art. 2(a) | Kwetsbaarheidsscan voorafgaand aan ondertekening: firmware-artefacten worden gescand aan de hand van bekende CVE-databases voordat goedkeuring voor ondertekening wordt verleend. |
| Minimaliseer het aanvalsoppervlak: beperk alle externe interfaces. | Art. 2(j) | Apparaatattestatie: DICE/TPM/PSA/TEE leveren runtimebewijs dat alleen geverifieerde, ongewijzigde code wordt uitgevoerd. |
Sleutelisolatiearchitectuur
De meest operationele architectonische verandering die de CRA van de meeste organisaties eist, is de overgang van een gedeelde infrastructuur voor ondertekeningssleutels naar sleutelisolatie per product.
Het model met gedeelde sleutels is de standaard voor organisaties die codeondertekening hebben ingevoerd zonder formele governance. Eén enkele ondertekeningssleutel, bijvoorbeeld opgeslagen op een USB-token of een buildserver, wordt gebruikt om de firmware van elk product te ondertekenen. Het is eenvoudig te beheren en werkt technisch gezien. Onder de CRA (Code Recognition Act) is het echter een structurele tekortkoming op het gebied van compliance.
Dit is waarom het onderscheid ertoe doet:
Architectuur met gedeelde sleutels
Alle productlijnen delen één enkele ondertekeningssleutel. Als die sleutel gecompromitteerd raakt:
- Elk product dat ermee is gesignaleerd, wordt tegelijkertijd beïnvloed.
- De impact van de explosie omvat de gehele portefeuille.
- De 24-uurs ENISA-melding volgens artikel 14 moet alle getroffen producten tegelijk omvatten, zonder de mogelijkheid om de omvang van de impact te bepalen.
- Antwoord van de compliance-afdeling: onmogelijk binnen 24 uur zonder productspecifieke gegevens.
Sleutelarchitectuur per product
Elke productlijn heeft een eigen, specifieke sleutel, die intern wordt gegenereerd en opgeslagen in een aparte HSM- partitie. Als één sleutel wordt gecompromitteerd:
- Alleen het product dat aan die sleutel is gekoppeld, wordt beïnvloed.
- De explosie blijft beperkt tot één productlijn.
- De kennisgeving in artikel 14 heeft betrekking op een afgebakend gebied waarop nauwkeurig en snel een antwoord kan worden gegeven.
- Antwoord met betrekking tot compliance: het auditspoor identificeert direct de getroffen producten, ondertekeningsgebeurtenissen en firmwareversies.
Voor een fabrikant met vier productlijnen betekent het gedeelde sleutelmodel een mogelijke marktonttrekking en herstelverplichtingen voor elk product tegelijk. Isolatie per product betekent dat één product wordt getroffen, drie normaal blijven functioneren en de melding nauwkeurig in plaats van in paniek wordt ingediend.
De overgang naar productspecifieke sleutelisolatie voldoet ook aan de eisen van de CRA inzake verantwoordingsplicht in de toeleveringsketen, zoals vastgelegd in artikel 13 §5. Documentatie voor conformiteitsbeoordeling ten behoeve van CE-markering moet aantonen dat de ondertekeningssleutel van elk product een eigen beheer, toegangscontrole en auditspoor heeft.
Leveranciersneutrale ondertekening
Een van de praktische uitdagingen voor fabrikanten die zich voorbereiden op CRA-conformiteit is de diversiteit aan siliciumarchitecturen in hun productportfolio's. Een bedrijf dat zowel een consumentenrouter (ARM TrustZone), een slim apparaat (MCU/IoT), een industriële controller (RISC-V) als een serverproduct (x86/UEFI) produceert, wordt geconfronteerd met vier verschillende platformecosystemen, elk met verschillende ondertekeningstoolchains, verschillende firmwareformaten (SUIT, FIT, UEFI-manifesten) en verschillende hardwarematige root-of-trust-mechanismen (DICE, TPM, PSA, TEE).
De CRA hecht geen waarde aan deze complexiteit en vereist consistente, controleerbare controles voor elk product dat onder de scope valt. Een leveranciersneutrale ondertekeningsarchitectuur lost dit op door de platformspecifieke ondertekeningstoolchain los te koppelen van de beleidsengine die deze beheert. In plaats van vier afzonderlijke ondertekeningsworkflows te bouwen met vier afzonderlijke sleutelbeheerpraktijken en vier afzonderlijke audit trails, past een gecentraliseerde beleidsengine consistente governance toe op alle platformtypen, terwijl platformspecifieke integraties de formaat- en protocoldetails voor elk platform afhandelen.
De architectuurlagen werken als volgt:
Hardware Root of Trust-laag: FIPS 140-2-gecertificeerde HSM's verzorgen de sleutelopslag en ondertekeningsbewerkingen voor alle platforms. Ondersteuning voor ML-DSA en SLH-DSA garandeert dat kwantumresistente ondertekening beschikbaar is vanuit dezelfde infrastructuur die wordt gebruikt voor klassieke algoritmen.
Gecentraliseerde beleidsengine: HSM-ondertekeningsbeheer past consistente RBAC-, M-van-N-quorumvereisten en goedkeuringsworkflows toe op alle productlijnen en alle platforms. Een wijziging in het ondertekeningsbeleid wordt overal gelijktijdig van kracht.
CI/CD- en auditlaag: Ondertekening, attestatie en het genereren van onveranderlijke logboeken vinden plaats tijdens de buildfase in de pipeline. Hierbij worden de hash van het artefact, de sleutel-ID, de identiteit van de goedkeurder, de pipelinefase en het tijdstempel gegenereerd die de auditvereisten van CRA vereisen.
Conforme output: Elk platform ontvangt de ondertekende firmware in het eigen formaat met het juiste manifesttype: SUIT voor IoT/MCU, FIT voor ARM/embedded Linux, UEFI-manifest voor x86-serverplatforms en RISC-V-specifieke attestatie. De ENISA-rapportageworkflow ontvangt gestructureerde, SRP-compatibele output die direct voldoet aan de 24-uurs notificatievereiste.
Deze architectuur voldoet aan de CRA-vereiste voor consistente controles over productlijnen heen, zonder dat er voor elk siliciumplatform een ​​afzonderlijk nalevingsprogramma nodig is.
Hoe CodeSign Secure van Encryption Consulting helpt
CodeSign Secure is het codeondertekeningsbeheerplatform van Encryption Consulting voor grote ondernemingen. Het is ontworpen om de infrastructuurcontroles te bieden die CRA-compliance vereist op alle vlakken die in deze blog worden behandeld.
HSM-ondersteund sleutelbeheer: CodeSign Secure slaat alle privésleutels voor ondertekening op in FIPS 140-2 Level 3 gecertificeerde hardwarebeveiligingsmodules (HSM's), die integreren met Thales Luna, Entrust nCipher, Utimaco, Securosys en cloud-HSM's van AWS en Azure. Sleutelisolatie per product wordt afgedwongen op het niveau van de HSM-partitie: elke productlijn ontvangt een eigen, specifieke sleutel die in de hardware wordt gegenereerd en nooit wordt geëxporteerd. Dit voldoet direct aan de CRA-vereiste voor een hardware-root of trust onder artikel 13(1)(c) en de vereiste voor isolatie per product onder artikel 13 §5.
M-van-N ondertekeningsquorum en RBAC: Het op rollen gebaseerde toegangscontrolemodel van het platform dwingt M-van-N goedkeuringsvereisten af ​​voor het ondertekenen van productiefirmware. Geen enkele persoon kan een ondertekeningsbewerking initiëren en goedkeuren. Ondertekeningsverzoeken, goedkeuringen en afwijzingen worden allemaal geregistreerd. De RBAC-configuratie zelf is controleerbaar en versiebeheerd, waardoor het gedocumenteerde ondertekeningsbeleid wordt geboden dat CRA-conformiteitsbeoordelingen vereisen.
Onveranderlijke auditlogboekregistratie: Elke ondertekeningsgebeurtenis in CodeSign Secure genereert een onveranderlijk logboekitem met de hash van het artefact, de sleutelidentificatie, het gebruikte certificaat, de goedkeurende identiteit en de RFC 3161-tijdstempel. De logboeken worden centraal opgeslagen, los van de infrastructuur voor ondertekening.
Ondersteuning voor platformonafhankelijke firmwareformaten: CodeSign Secure ondersteunt het ondertekenen van firmware-artefacten in alle formaten die een divers productportfolio vereist: .bin, .img, .hex, .fw, .dfu en .efi. Hiermee wordt voldaan aan de CRA-vereiste voor consistente controles over productlijnen heen, zonder dat de ondertekeningsinfrastructuur voor elk platform opnieuw hoeft te worden opgebouwd.
Ondersteuning voor post-kwantumcryptografie: CodeSign Secure v3.02 ondersteunt ML-DSA (FIPS 204, op beveiligingsniveaus ML-DSA-44, ML-DSA-65 en ML-DSA-87) en SLH-DSA (FIPS 205) van productiekwaliteit als afneembare handtekeningen naast klassieke algoritmen. Voor fabrikanten die producten bouwen met een CRA-ondersteuningsverplichting van vijf jaar of langer, is post-kwantumcryptografie (PQC) vandaag de dag de architectuur die bescherming biedt tegen de HNDL-dreiging voordat een CRQC-garantie wordt afgegeven.
CI/CD-pipeline-integratie: CodeSign Secure integreert met Azure DevOps, Jenkins, GitLab CI en andere belangrijke pipelineplatformen via API's en commandoregelinterfaces. Het ondertekenen van firmware is een gecontroleerde, door beleid afgedwongen fase in de buildpipeline, geen handmatige stap.
Conclusie
De Cyber ​​Resilience Act heeft het ondertekenen van firmware verheven van een best practice op het gebied van beveiliging tot een wettelijke verplichting met bindende gevolgen. De eerste handhavingsmijlpaal, de meldingsplicht voor incidenten en kwetsbaarheden in artikel 14, treedt in werking op 11 september 2026. Volledige naleving, inclusief CE-markering, is vereist vóór 11 december 2027. De infrastructuur die nodig is om beide deadlines te halen – productspecifieke sleutelisolatie, HSM-ondertekening, M-van-N-quorumvereisten, audit trails van 10 jaar en workflows voor ondertekening op basis van kwetsbaarheden – vergt 12 tot 18 maanden om te ontwerpen en correct te implementeren.
De organisaties die het best gepositioneerd zijn voor naleving van de CRA-regelgeving zijn niet de organisaties die pas in december 2027 beginnen met het opzetten van hun ondertekeningsarchitectuur. Dat zijn de organisaties die er nu al mee beginnen, voordat de rapportageverplichtingen van september 2026 de tekortkomingen in hun huidige infrastructuur aan het licht brengen.
Bij Encryption Consulting levert CodeSign Secure de infrastructuur voor digitale handtekeningen die voldoet aan de eisen van de CRA (Common Reporting Act), van HSM-ondersteunde sleutelisolatie tot onveranderlijke audit trails en post-quantum ondertekening die de HNDL-dreiging (Highly Not Data Locked) binnen de ondersteuningsperiode van de CRA aanpakt.
