Stapsgewijze handleiding voor naleving van de Cyber ​​Resilience Act (CRA).

Gepubliceerd: januari 2026. Bijgewerkt: augustus 2026. Beoordeeld door het Compliance Advisory-team van Encryption Consulting.

Wat vereist de Cyber ​​Resilience Act?

De Cyber ​​Resilience Act (CRA), formeel Verordening (EU) 2024/2847, is de eerste horizontale wetgeving van de Europese Unie die verplichte cybersecurity-eisen stelt voor producten met digitale elementen, hardware of software, die overal op de EU-markt worden verkocht. De naleving van de Cyber ​​Resilience Act (CRA) komt stap voor stap neer op één leidend principe, vastgelegd in artikel 6 : alleen producten die van meet af aan veilig zijn ontworpen en gedurende hun volledige levenscyclus worden ondersteund, mogen op de EU-markt worden gebracht.

Dat principe is opgebouwd uit twee pijlers.

1. Producten moeten door ontwerp en gebruik veilig zijn (Bijlage I, Deel I)

Een product voldoet alleen aan de eisen als het voldoet aan de essentiële cybersecurity-eisen in Bijlage I, Deel I , en als het door de gebruiker of exploitant correct wordt geïnstalleerd, onderhouden en bijgewerkt. In de praktijk betekent dit dat het product veilig moet zijn bij levering en veilig moet blijven gedurende de gehele ondersteunde levensduur, en niet alleen een controle op de lanceringsdag moet doorstaan.

De CRA deelt producten in vier risicocategorieën in, en de categorie waarin een product valt, bepaalt hoe het op conformiteit wordt beoordeeld:

• Standaardcategorie: Ongeveer 90 procent van de producten met digitale elementen, waaronder algemene consumentenelektronica zoals slimme luidsprekers, harde schijven en fotobewerkingssoftware.
• Belangrijke producten Klasse I: Producten met cybersecurity-relevante functies, zoals identiteitsbeheersystemen, webbrowsers, wachtwoordmanagers, VPN-software en slimme huisbeveiligingsapparaten.
• Belangrijke producten Klasse II: Producten met een hoger risico, zoals firewalls, industriële inbraakdetectie- en preventiesystemen, hypervisors en fraudebestendige microprocessoren.
• Essentiële producten: De hoogste risicocategorie, waarbij essentiële entiteiten afhankelijk zijn van het product, zoals beveiligde elementen in smartcards en gateways voor slimme meters.

2. Fabrikanten moeten veilige ontwikkelings- en levenscyclusprocessen volgen (Bijlage I, deel II)

Compliance gaat niet alleen over het geleverde apparaat. Volgens Bijlage I, Deel II , moeten fabrikanten een proces voor kwetsbaarheidsbeheer uitvoeren, veilige ontwikkelingspraktijken volgen gedurende de gehele productlevenscyclus en beveiligingsupdates blijven leveren zolang het product wordt ondersteund. CRA-compliance is een permanent operationeel programma, geen eenmalige certificering.

Wie moet voldoen aan de eisen van de CRA?

Elke fabrikant, zowel binnen als buiten de EU, die producten met digitale elementen in Europa verkoopt, valt onder de volgende reikwijdte:

• EU-fabrikanten bedrijven die binnen de EU gevestigd zijn en producten ontwikkelen met software of firmware, en deze vervolgens in de EU verkopen.
• Fabrikanten buiten de EU bedrijven die buiten de EU gevestigd zijn, bijvoorbeeld in de VS of China, en die rechtstreeks aan de EU-markt verkopen of via EU-distributeurs en -importeurs.

Als het product op de EU-markt terechtkomt, is de Canadese belastingdienst (CRA) van toepassing, ongeacht waar het bedrijf gevestigd is. Verkoop via een online marktplaats vormt geen uitzondering; als EU-klanten het product kunnen kopen, valt de fabrikant onder de reikwijdte van de belastingdienst.

De CRA (Common Recognition Act) omvat software en firmware die draait op of wordt meegeleverd met verbonden apparaten: besturingssystemen voor apparaten, ingebouwde firmware, mobiele apps voor de besturing van IoT-producten, beheertools voor desktops en cloudinterfaces die met die apparaten communiceren. Typische categorieën zijn IoT- en ingebouwde apparaten die worden gebruikt in huizen, de gezondheidszorg en industriële omgevingen; industriële besturings- en automatiseringsapparatuur; en consumentenelektronica zoals wearables, slimme apparaten en verbonden beveiligingsproducten.

Wat is de tijdlijn voor naleving van de CRA-voorschriften?

De CRA wordt gefaseerd ingevoerd volgens een vast, door de EU bevestigd schema. Er is geen overgangsperiode na deze data.

1. De CRA treedt in werking op 10 december 2024. De regelgeving is op deze datum van kracht geworden. Er is geen onmiddellijke naleving vereist, maar het aftellen is begonnen; fabrikanten, importeurs en distributeurs moeten beginnen met het opzetten van de processen, documentatie en technische controles die de latere deadlines vereisen.
2. Vanaf 11 juni 2026 zijn de bepalingen inzake aangemelde instanties en markttoezicht van toepassing. De bepalingen van hoofdstuk IV met betrekking tot conformiteitsbeoordelingsinstanties en markttoezichtautoriteiten treden in werking, waardoor de handhavingsinfrastructuur de tijd krijgt om op te zetten voordat de rapportageverplichtingen ingaan.
3. Op 11 september 2026 begint de meldingsplicht voor kwetsbaarheden en incidenten. Volgens artikel 14 moeten fabrikanten actief misbruikte kwetsbaarheden en ernstige incidenten binnen vastgestelde termijnen melden aan ENISA en nationale CSIRT's, en moeten ze al een basisproces voor kwetsbaarheidsbeheer en -melding hebben. Dit is de eerste stap in de CRA: transparantie en vroegtijdige waarschuwing, voorafgaand aan volledige productconformiteit.
4. 11 december 2027, volledige naleving vereist. Elk product met digitale elementen dat op de EU-markt wordt gebracht, moet volledig voldoen aan de eisen van de CRA: ontwikkeling met beveiliging door ontwerp en beveiliging door standaardinstellingen, het aanmaken en onderhouden van een SBOM (Safety by Objective Management), gedocumenteerd kwetsbaarheidsbeheer, werkende mechanismen voor beveiligingsupdates en een CE-markering die is gekoppeld aan de conformiteit op het gebied van cyberbeveiliging. Producten die niet aan deze eisen voldoen, mogen na deze datum niet legaal in de EU worden verkocht.

Producten die vóór 11 december 2027 rechtmatig op de EU-markt zijn gebracht, zijn over het algemeen vrijgesteld van de belangrijkste vereisten, zolang ze na die datum geen substantiële wijziging ondergaan; een substantiële wijziging maakt de wijzigende entiteit voor CRA-doeleinden tot fabrikant en zorgt ervoor dat het product volledig onder de reikwijdte van de regelgeving valt. De enige vereiste die van toepassing is op producten die al op de markt zijn, ongeacht deze vrijstelling, is artikel 14 betreffende de melding van kwetsbaarheden en incidenten, dat vanaf 11 september 2026 van toepassing is op elk product dat onder de regelgeving valt.

Welke richtlijnen geeft de CRA voor de selectie van cryptografie en algoritmen?

De CRA is bewust technologie-neutraal. Bijlage I, deel I vereist dat fabrikanten de vertrouwelijkheid van gegevens beschermen “door relevante gegevens in rust of tijdens transport te versleutelen met behulp van de modernste mechanismen” (artikel 2(e)) en de integriteit van opgeslagen en verzonden gegevens, commando's en configuratie te beschermen tegen ongeoorloofde wijziging (artikel 2(f)), maar er worden geen specifieke algoritmen genoemd. Die keuze, en het bijbehorende controletraject, wordt aan de fabrikant overgelaten, en dat is precies waar de meeste conformiteitsbeoordelingen tekortkomingen aan het licht brengen.

Een verdedigbare basislijn voor producten die onder de CRA-scope vallen, ziet er als volgt uit:

• Gegevens in rust en tijdens transport: AES-256 voor symmetrische encryptie, TLS 1.3 voor netwerkkanalen, en een gedocumenteerde reden wanneer een zwakkere cipher suite nog steeds in gebruik is voor interoperabiliteit met oudere systemen.
• Digitale handtekeningen voor de integriteit van firmware en updates: RSA-2048 of ECDSA P-256 als klassiek minimum, met een verschuiving naar hybride ondertekening die een klassiek algoritme combineert met een NIST post-kwantumschema zoals ML-DSA (FIPS 204) voor algemene ondertekening.
• Beperkte en langlevende firmware: NIST SP 800-208 wijst de stateful hash-gebaseerde schema's LMS en XMSS aan voor het ondertekenen van firmware en software, waarbij de grootte van de handtekening en de omvang van de code belangrijker zijn dan de pure doorvoer. Daarom noemt NSA's CNSA 2.0 deze schema's momenteel specifiek als de voorkeursmethode voor firmware op korte termijn.
• Sleutelafscherming voor vertrouwelijkheid: ML-KEM (FIPS 203) waarbij de verwachte ondersteuningsduur van een product zich uitstrekt tot in de jaren 2030 en een blootstellingsperiode van 'nu oogsten, later decoderen' realistisch is.

De keuze voor een algoritme is geen eenmalige beslissing. Het moet worden gedocumenteerd in het technisch dossier dat een aangemelde instantie of markttoezichthouder zal opvragen, en er moet een duidelijk omschreven procedure zijn voor het vervangen van een algoritme zonder de architectuur van het product te hoeven aanpassen. Dit wordt in de volgende twee paragrafen behandeld.

Welk dreigingsmodel hanteert de CRA?

De essentiële vereisten van de CRA zijn gekoppeld aan een specifieke reeks aanvalsmogelijkheden waartegen fabrikanten zich volgens de regelgeving moeten verdedigen, en niet aan een algemene "wees veilig"-richtlijn:

• Toeleveringsketen en update-injectie. Een aanvaller die een build-pipeline, een ondertekeningssleutel of een distributiekanaal compromitteert, probeert ongeautoriseerde firmware of software naar apparaten te pushen die al in gebruik zijn. Bijlage I, deel I 2(c) en 2(f) behandelen dit direct door te vereisen dat updates ondertekend en verifieerbaar zijn en dat er manipulatiedetectie is voor code en configuratie.
• Misbruik van bekende kwetsbaarheden. Bijlage I, deel I 2(a) gaat ervan uit dat producten worden geleverd met kwetsbaarheden die na de release worden ontdekt en vereist een werkend proces voor openbaarmaking en patching, en niet alleen een schone scan bij de lancering.
• Ongeautoriseerde toegang en aanvallen op inloggegevens. Standaard of vastgelegde inloggegevens, blootgestelde beheerinterfaces en zwakke authenticatie worden beschouwd als een ontwerpfout onder 2(b) en 2(d), en niet als een configuratiefout die de klant had moeten opmerken.
• Oogst nu, decodeer later. De CRA noemt kwantumcomputing niet expliciet als een bedreiging, maar de verplichting tot ondersteuning gedurende meer dan vijf jaar onder artikel 13 betekent dat gegevens of handtekeningen die momenteel alleen door klassieke algoritmen worden beschermd, mogelijk vertrouwelijk of verifieerbaar moeten blijven, ook nadat een cryptografisch relevante kwantumcomputer geen geloofwaardig risico meer vormt. Daarom hoort algoritmeflexibiliteit thuis in het dreigingsmodel, ook al is de regelgeving zelf algoritme-neutraal.
• Compromis in zowel de fysieke als de productiefase. Voor IoT- en embedded apparaten is een aanvaller met fysieke toegang tot een apparaat of een ingang in het productieproces een reële bedreiging. Daarom zijn beveiligde opstartprocedures, verankerd in hardware en per-apparaat-provisioning, net zo belangrijk als de softwarematige beveiligingsmaatregelen.

Wat zijn de afwegingen tussen prestaties en interoperabiliteit?

Het voldoen aan de cryptografische eisen van de CRA is niet gratis, en de afwegingen verschillen per productcategorie.

• Grootte van de handtekening op apparaten met beperkte mogelijkheden. ML-DSA- en SLH-DSA-handtekeningen zijn ongeveer 2 tot 8 keer groter dan een ECDSA P-256-handtekening, wat direct van belang is voor de opstarttijd en het flashgeheugen van IoT-apparaten met microcontrollers. Dit is de praktische reden waarom de LMS- en XMSS-handtekeningen van NIST SP 800-208, met hun kleinere handtekeningen, op korte termijn de voorkeur genieten voor firmware, ondanks dat ze stateful, crash-consistent sleutelbeheer vereisen binnen een gevalideerde HSM.
• Hybride ondertekeningskosten. Het gebruik van zowel een klassiek als een post-kwantumalgoritme tijdens de overgangsperiode verdubbelt ruwweg de tijd die nodig is voor het genereren en verifiëren van handtekeningen. Voor CI/CD-pipelines met een hoog volume is dit doorgaans geen probleem; voor een apparaat dat een handtekening verifieert tijdens een opstartsequentie met beperkte energievoorziening is dit echter wel het geval.
• Geharmoniseerde normen zijn nog in ontwikkeling. De Europese Commissie heeft CEN en CENELEC de opdracht gegeven geharmoniseerde normen op te stellen die fabrikanten, zodra ze gepubliceerd zijn, een vermoeden van conformiteit zullen geven. Totdat deze normen definitief zijn, beoordelen fabrikanten de conformiteit rechtstreeks aan de hand van de tekst in bijlage I. Dit betekent dat twee auditors redelijkerwijs tot verschillende conclusies kunnen komen over dezelfde controle, totdat de geharmoniseerde normen zijn ingevoerd.
• Grensoverschrijdende distributie van updates. Er moet één enkel update-mechanisme werken onder de netwerkomstandigheden van alle EU-lidstaten en, voor producten die ook buiten de EU worden verkocht, moet het naast de wettelijke vereisten van niet-EU-landen bestaan ​​zonder dat er per regio een afzonderlijk ondertekeningsproces nodig is.

Op welke sleutelbeheerprincipes is het veilig ondertekenen van updates gebaseerd?

De vereiste van artikel 13 voor veilige updates is slechts zo sterk als het sleutelbeheer erachter. Een ondertekende update die gebaseerd is op een slecht beheerde sleutel, verschilt in wezen niet van een niet-ondertekende update zodra die sleutel uitlekt. Een verdedigbare architectuur scheidt ten minste drie rollen:

• Offline root-sleutel. Wordt zelden gebruikt, doorgaans alleen voor het uitgeven of vernieuwen van het certificaat voor de online ondertekeningssleutel, die wordt gegenereerd en bewaard in een HSM die losgekoppeld blijft van elk netwerk en alleen online wordt gebracht voor geplande, gecontroleerde sleutelceremonies.
• Online ondertekeningssleutel. Wat de build-pipeline daadwerkelijk aanroept bij elke release, is HSM-ondersteund en bereikbaar via een geauthenticeerde API, zodat ondertekening geautomatiseerd kan worden. De sleutel is echter nooit dezelfde als die van de offline root, waardoor het roteren ervan de vertrouwensanker die al in de geïmplementeerde apparaten is ingebed, niet aantast.
• Productie-identificatie per apparaat. Een uniek sleutelpaar dat tijdens de fabricage wordt aangemaakt volgens het IEEE 802.1AR-patroon, waarmee een apparaat zich bij een updateserver kan authenticeren als een authentiek, niet-gekloond apparaat voordat het een ondertekende image ontvangt.

Naast deze scheiding vereist een werkend programma FIPS 140-3-gevalideerde hardware ter bescherming van elke ondertekeningssleutel, een M-van-N-goedkeuringsvereiste zodat niemand eenzijdig kan ondertekenen en verzenden, rollback-bescherming die herinstallatie van een oudere, ondertekende maar kwetsbare firmwareversie blokkeert, en een vooraf geconfigureerde opvolgersleutel zodat een gecompromitteerde sleutel kan worden vervangen zonder dat er een terugroepactie nodig is. Organisaties die de diepere mechanismen hiervan willen begrijpen, kunnen de documenten " Establishing a Firmware Signing Framework for CRA Compliance" en "CRA Compliance Architecture for Secure Code Signing" raadplegen , waarin de volledige sleutelhiërarchie en de intrekkingsworkflow gedetailleerd worden beschreven.

Hoe zien CRA-conforme implementaties er in de praktijk uit?

Dezelfde essentiële eisen verschillen per productcategorie.

Fabrikant van IoT-apparaten (standaardcategorie). Een leverancier van slimme huissensoren stuitte op een veelvoorkomend probleem: één gedeelde ondertekeningssleutel die voor alle productlijnen werd gebruikt en die op een buildserver werd gegenereerd in plaats van in de hardware. De oplossing verplaatste de sleutelgeneratie naar een HSM, splitste de ondertekening op in sleutels per product (zodat een inbreuk op één productlijn de andere niet blootlegt), voegde multifactorauthenticatie toe voor toegang tot de ondertekening en automatiseerde de ondertekening binnen de CI/CD-pipeline met fraudebestendige auditlogboekregistratie. Hiermee werd voldaan aan zowel de integriteitsvereiste als de traceerbaarheid die een conformiteitsbeoordeling vereist.

Fabrikant van industriële controllers (Belangrijke Klasse II). Een leverancier van programmeerbare logische controllers voor fabrieksautomatisering had een beveiligde opstartprocedure nodig, verankerd in een onveranderlijke hardware-root, aangezien deze apparaten tien jaar of langer in gebruik zijn en zelden fysiek worden bezocht voor onderhoud. Het ontwerp scheidde de opstartverificatieketen, gekoppeld aan de zelden gewijzigde offline root, van de updateverificatieketen, gekoppeld aan de vaker gewijzigde online ondertekeningssleutel. Hierdoor hoeft de onveranderlijke opstart-ROM nooit opnieuw te worden geflasht als de online sleutel gecompromitteerd of verouderd is.

Fabrikant van medische hulpmiddelen (belangrijk, klasse I of kritiek, afhankelijk van de functie). Een fabrikant van verbonden diagnostische apparaten moest de SBOM- en kwetsbaarheidsrapportageverplichtingen van de CRA afstemmen op de bestaande wettelijke voorschriften voor medische hulpmiddelen. De gekozen werkwijze behandelde de SBOM van de CRA als de hoofdinventaris die zowel de rapportageworkflow van de CRA volgens artikel 14 als het bestaande bewakingsproces voor medische hulpmiddelen voedde, in plaats van twee afzonderlijke componentinventarissen bij te houden die uit elkaar zouden kunnen lopen.

Overzicht van de CRA-vereisten: vereisten, controle en waar EC van pas komt.

De onderstaande tabel koppelt de essentiële cybersecurityvereisten waaraan een fabrikant moet voldoen aan de technische beheersmaatregelen die daaraan voldoen en de encryptieconsultingdienst of het product dat voor die beheersmaatregelen is ontwikkeld.

CRA-vereiste (Bijlage I)	Technische controle	Encryptie-adviesdienst
Veilig door ontwerp (Deel I.1)	Risicobeoordeling, veilige ontwikkelingslevenscyclus, minimalisering van het aanvalsoppervlak	Compliance Advies
Geen bekende exploiteerbare kwetsbaarheden (2(a))	Kwetsbaarheidsscanning, SBOM-beoordeling, herstelwerkzaamheden vóór de release.	Compliance-advies, CBOM Secure
Beveiligde standaardconfiguratie (2(b))	Verstevigde standaardinstellingen, ondersteuning voor fabrieksreset, ongebruikte services uitgeschakeld.	Compliance Advies
Tijdige, verifieerbare beveiligingsupdates (2(c))	Ondertekende updatepakketten, HSM-ondersteunde ondertekeningssleutels, terugdraaibeveiliging	CodeSign Secure
Vertrouwelijkheid van opgeslagen en verzonden gegevens (2(e))	Geavanceerde encryptie voor gegevens in rust en tijdens transport, beheerde sleutellevenscyclus	PKI-as-a-Service, HSM-as-a-Service
Integriteit van gegevens, commando's en configuratie (2(f))	Digitale handtekeningen, checksums, geauthenticeerde communicatiekanalen	CodeSign Secure, PKI-as-a-Service
Beveiligingsgebeurtenissen bewaken en registreren (2(l))	Onveranderlijke auditlogboeken gekoppeld aan elke ondertekening en toegangsgebeurtenis.	CodeSign Secure, CBOM Secure
SBOM en componenttracering (Deel II.1)	Cryptografische ontdekking, inventarisatie van afhankelijkheden, CVE-monitoring	CBOM Secure
Openbaarmaking en melding van kwetsbaarheden (Deel II.4, Artikel 14)	Gecoördineerd openbaarmakingsbeleid, ENISA-rapportageworkflow, gedocumenteerde tijdlijnen	Compliance Advies

Wat zijn de sancties bij niet-naleving?

Artikel 64 geeft de markttoezichtautoriteiten zowel de bevoegdheid om boetes op te leggen als om corrigerende maatregelen te nemen: ze kunnen bevelen dat producten van de markt worden gehaald, verdere verkoop beperken of verbieden, en een herontwerp eisen voordat een product opnieuw mag worden verkocht. De hoogte van de boetes is afhankelijk van de ernst van de overtreding.

schending	Maximale boete	Omzetlimiet (de hoogste van de twee)
Schending van essentiële cyberbeveiligingsvereisten (bijlage I), verplichtingen uit artikel 13 of 14	15 miljoen euro	2.5% van de wereldwijde jaaromzet
Overige verplichtingen: onvolledige technische documentatie, ontbrekende conformiteitsbeoordeling, onjuiste CE-markering, ontbrekende SBOM	10 miljoen euro	2% van de wereldwijde jaaromzet
Onjuiste, misleidende of onvolledige informatie aan de autoriteiten	5 miljoen euro	1% van de wereldwijde jaaromzet

Checklist voor naleving van de CRA-wetgeving

De CRA wil bewijs dat cybersecurity een eigen, beheerd en gedocumenteerd systeem is, en niet een ad-hoc aanpak. Gebruik deze checklist om te bepalen waar de organisatie momenteel staat.

Risicobeoordeling

• Een formeel risicobeheerproces identificeert, bewaakt en beheert beveiligingsrisico's met behulp van gedocumenteerde risicoacceptatiecriteria.
• Een RACI-matrix definieert risico-eigendom, escalatie en besluitvorming.
• Cryptografische beleidsregels zijn afgestemd op erkende standaarden zoals NIST en FIPS.

Reactie op incidenten

• Een gedocumenteerd incidentresponsplan beschrijft de procedures voor detectie, beheersing en herstel, en wordt regelmatig getest.
• Software stuklijsten (SBOM's) worden onderhouden om snelle incidenttriage en impactanalyse te ondersteunen.

Data Protection

• Versleuteling beschermt gevoelige gegevens, zowel in rust als tijdens transport, met behulp van algoritmen die zijn gedocumenteerd volgens een actuele standaard.
• Controlemaatregelen voor de integriteit van software en gegevens, waaronder code ondertekeningworden geïmplementeerd en onafhankelijk gecontroleerd.

Rapportageverplichtingen

• De rapportagetermijnen, drempelwaarden en verantwoordelijkheden voor meldingen op grond van artikel 14 aan ENISA zijn duidelijk gedefinieerd en geoefend.
• SBOM's en ander bewijsmateriaal met betrekking tot naleving worden waar mogelijk geautomatiseerd om de reactietijd en fouten te verminderen.

Beperkingen

Deze handleiding is een uitgangspunt en geen vervanging voor een formele conformiteitsbeoordeling of juridische toetsing. Enkele beperkingen moeten duidelijk worden vermeld. De geharmoniseerde normen waaraan CEN en CENELEC werken, zullen fabrikanten uiteindelijk een vermoeden van conformiteit geven voor specifieke technische controles; tot die normen zijn gepubliceerd, laat een beoordeling op basis van de tekst van Bijlage I ruimte voor verschillende interpretaties tussen fabrikanten en aangemelde instanties. De productcategorievoorbeelden in deze handleiding zijn illustratief en geen vervanging voor het formele classificatieproces, dat de conformiteitsbeoordelingsroute bepaalt die een specifiek product moet volgen. Wanneer een product ook onder NIS2, DORA of een sectorspecifiek regime valt, zoals de regelgeving voor medische hulpmiddelen, vervangt de CRA die verplichtingen niet; ze vult ze aan en de overlapping moet per geval worden afgestemd. Tot slot weerspiegelen de verwijzingen naar algoritmen en normen in deze handleiding de huidige situatie van NIST en het CA/Browser Forum zoals die gold in augustus 2026; PQC-normen en CA/B Forum-stemmingen blijven zich ontwikkelen, dus een complianceprogramma heeft een proces nodig om updates bij te houden, en niet een eenmalige lezing van dit artikel.

Wat zou Encryption Consulting aanbevelen?

Begin met een gap-analyse voordat u tools aanschaft. De Compliance Advisory- service van Encryption Consulting voert een gedetailleerde beoordeling uit op basis van de specifieke CRA-artikelen en de vereisten van Bijlage I die van toepassing zijn op de productcategorie. Hierbij worden concrete tekortkomingen geïdentificeerd, zoals verouderde protocollen, zwak sleutelbeheer of verkeerd geconfigureerde TLS-instellingen, in plaats van een algemene volwassenheidsscore.

CodeSign Secure is specifiek ontworpen voor de vereisten voor veilige updates en firmware-ondertekening : privésleutels voor ondertekening blijven binnen FIPS 140-2 Level 3 gecertificeerde HSM's, M-of-N-goedkeuring voorkomt eenzijdige ondertekening, elke ondertekeningsgebeurtenis genereert een onveranderlijk auditlogboek en hybride ondertekening ondersteunt zowel klassieke algoritmen als post-kwantumschema's zoals ML-DSA en LMS vanuit dezelfde infrastructuur voor ondertekening. Hierdoor hoeft een fabrikant de pipeline niet opnieuw op te bouwen wanneer de geharmoniseerde standaarden worden ingevoerd.

Voor de vertrouwelijkheids- en integriteitsvereisten rondom data in rust en tijdens transport, biedt PKI-as-a-Service de beheerde certificaat- en sleutelinfrastructuur die versleutelde kanalen en apparaatidentificatie ondersteunt zonder dat er een eigen CA hoeft te worden opgezet. Dit is vooral belangrijk voor fabrikanten die dit ruim vóór de rapportagedeadline van september 2026 operationeel willen hebben, en niet erna.

Een organisatie die IoT-apparaten produceert, stuitte op precies deze combinatie van tekortkomingen: een gedeelde ondertekeningssleutel, geen traceerbaarheid tussen certificaten en releases, en geen draaiboek voor intrekking. Door HSM-ondersteunde sleutelbescherming, multifactorauthenticatie voor ondertekeningstoegang en geautomatiseerde CI/CD-ondertekening werden de integriteits- en toegangscontroleproblemen opgelost, terwijl fraudebestendige auditregistratie en gedefinieerde procedures voor sleutelintrekking tegelijkertijd voldeden aan de traceerbaarheids- en kwetsbaarheidsafhandelingsvereisten van de CRA.

Conclusie

De CRA stelt een nieuwe norm vast: cybersecurity als een continue, aantoonbare verantwoordelijkheid gedurende de gehele levenscyclus van een product, in plaats van een afvinklijstje op de lanceringsdag. De rapportagedeadline van 11 september 2026 is de eerste en test of een proces voor het melden van kwetsbaarheden daadwerkelijk onder druk werkt; de deadline van 11 december 2027 test al het andere, van 'secure by design'-engineering tot de nauwkeurigheid van SBOM's en ondertekende, controleerbare updates. Fabrikanten die algoritmeselectie, sleutelbeheer en het ondertekenen van updates beschouwen als infrastructuur die nu moet worden opgebouwd, in plaats van als papierwerk dat later moet worden verzameld, zullen beide deadlines zonder problemen halen.

Veelgestelde Vragen / FAQ

Wanneer treedt de Cyber ​​Resilience Act daadwerkelijk in werking?

De CRA is op 10 december 2024 in werking getreden. De meldingsplicht voor kwetsbaarheden en incidenten op grond van artikel 14 geldt vanaf 11 september 2026. Volledige naleving, inclusief CE-markering, is vereist vóór 11 december 2027. Na deze data is er geen extra overgangsperiode.

Vereist de CRA een specifiek encryptiealgoritme?

Nee. Bijlage I, deel I vereist "state of the art"-encryptie voor de bescherming van de vertrouwelijkheid en integriteit van gegevens, commando's en configuratie, maar noemt geen specifieke algoritmen. Fabrikanten kiezen en documenteren algoritmen zoals AES-256, TLS 1.3 en ondertekeningsschema's die geschikt zijn voor de beperkingen en de verwachte levensduur van het product, en die keuze wordt onderdeel van de technische documentatie die tijdens een conformiteitsbeoordeling wordt gecontroleerd.

Zijn er producten die zijn vrijgesteld van de CRA?

Producten die vóór 11 december 2027 al rechtmatig op de EU-markt zijn gebracht, zijn over het algemeen vrijgesteld van de belangrijkste vereisten, tenzij ze na die datum een ​​substantiële wijziging ondergaan. Voor bepaalde categorieën, zoals producten die al onder sectorspecifieke EU-regelgeving voor medische hulpmiddelen, de luchtvaart of voertuigen vallen, gelden aparte uitzonderingen die in de verordening zijn vastgelegd. De meldingsplicht van artikel 14 inzake kwetsbaarheden en incidenten blijft van toepassing op producten die onder de verordening vallen, ongeacht deze uitzondering, vanaf 11 september 2026.

Wat is de relatie tussen de CRA, NIS2 en DORA?

NIS2 en DORA reguleren de cybersecurity en operationele weerbaarheid van organisaties die kritieke infrastructuur beheren en financiële instellingen. De CRA regelt de producten die deze en andere organisaties kopen en gebruiken. Een bank die onder DORA valt, moet bijvoorbeeld nog steeds controleren of de aangesloten apparaten en software die zij aanschaft voldoen aan de CRA-vereisten; de regelgeving is complementair en vervangt elkaar niet.

Wat is de grootste fout die fabrikanten maken bij de voorbereiding op de CRA op het gebied van cryptografie?

Het gebruik van één gedeelde ondertekeningssleutel voor alle productlijnen is de snelste weg naar naleving, maar ook de slechtste uitkomst onder artikel 14: een compromis met één sleutel leidt tot een incidentmelding voor de gehele portfolio in één keer, in plaats van slechts één productlijn. Isolatie van sleutels per product, gegenereerd binnen een HSM, is uiteindelijk de oplossing die de meeste conformiteitsbeoordelingen vereisen.

Referenties

• Verordening (EU) 2024/2847 van het Europees Parlement en de Raad, Cyber ​​Resilience Act, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• Europese Commissie, Cyber ​​Resilience Act, Vormgeving van de digitale toekomst van Europa: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CRA-bijlagen I tot en met VIII, essentiële vereisten en productlijsten: https://www.cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/
• Wet inzake cyberweerbaarheid, artikel 71, inwerkingtreding en toepassing: https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_71.html
• NIST SP 800-208, Aanbeveling voor stateful hash-gebaseerde handtekeningschema's: https://csrc.nist.gov/pubs/sp/800/208/final
• NIST FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA), definitief vastgesteld in augustus 2024: https://csrc.nist.gov/pubs/fips/204/final