De Cyber Resilience Act — CRA, Verordening (EU) 2024/2847 — is op 10 december 2024 in werking getreden. De wet introduceert verplichte cybersecurityeisen voor alle producten met digitale elementen die op de EU-markt worden aangeboden. Dat klinkt abstract, maar het is concreet: van consumentenapparaten tot industriële software, van embedded firmware tot standalone applicaties. Dit is geen vrijwillige best practice meer. Het zijn afdwingbare wettelijke eisen voor fabrikanten, importeurs en distributeurs.

Voor wie geldt de CRA?

De wet geldt voor elk product met digitale elementen dat op de EU-markt wordt aangeboden. Software — standalone of embedded — valt eronder. Hardware met connectiviteitsfuncties valt eronder. Componenten die in andere producten worden geïntegreerd vallen eronder. Uitzonderingen bestaan voor producten die onder een sectorspecifieke wet vallen met gelijkwaardige eisen, zoals bepaalde medische hulpmiddelen en motorvoertuigen.

Open source software vallend buiten commerciële exploitatie is in beginsel vrijgesteld. Maar softwareleveranciers die open source componenten inbouwen in hun commerciële producten vallen wél onder de CRA voor die producten als geheel. De vrijstelling is smaller dan ze op het eerste gezicht lijkt.

Drie cruciale tijdmomenten

De wet kent drie relevante mijlpalen. December 2024 was de datum van inwerkingtreding. September 2026 is wanneer de meldplicht voor actief uitgebuite kwetsbaarheden en significante incidenten actief wordt. Fabrikanten moeten dan melden bij ENISA binnen 24 uur na bewustemaking — een aanzienlijk kortere termijn dan de 72 uur die NIS2 hanteert. December 2027 is de deadline waarvoor alle producten met digitale elementen moeten voldoen vóór ze op de markt komen.

De combinatie van september 2026 en een operationeel PSIRT betekent dat organisaties die producten ontwikkelen al vóór die datum een kwetsbaarheidsbeheersproces en monitoringcapaciteit operationeel moeten hebben.

SBOM als compliance-grondslag

Een Software Bill of Materials is de gestructureerde inventarisatie van alle componenten in een softwareproduct: open source bibliotheken, third-party code, afhankelijkheden en versienummers. De CRA vereist geen specifiek SBOM-formaat maar verplicht wel dat fabrikanten alle componenten en hun kwetsbaarheden identificeren, aantoonbaar monitoren op bekende kwetsbaarheden en afnemers informeren over kwetsbaarheden in producten die zij hebben gekocht.

In de praktijk werkt een SBOM-pipeline als een geautomatiseerde stap in de build-pipeline: het systeem genereert de SBOM bij elke build, verrijkt het automatisch met CVE-data uit de National Vulnerability Database of een vergelijkbare bron, valideert op kritieke kwetsbaarheden vóór een release en stelt het resultaat beschikbaar aan afnemers in een machine-leesbaar formaat.

PSIRT: de organisatorische kant van kwetsbaarheidsbeheer

Artikel 13 van de CRA vereist dat fabrikanten een procedure voor kwetsbaarheidsbeheer opzetten. In de praktijk is dat een PSIRT-functie: een Product Security Incident Response Team dat kwetsbaarheidsrapportages ontvangt, triaget, verifieert en oplost.

Een minimale PSIRT-capaciteit heeft een beveiligd kanaal voor externe kwetsbaarheidsrapportages via een security.txt of een dedicated e-mailadres met PGP-encryptie. Elk inkomend rapport krijgt binnen drie tot vijf werkdagen een bevestiging. De ernst wordt beoordeeld op basis van CVSS-scoring en de impact op productgebruikers wordt vastgesteld. Patchontwikkelingstijden zijn gecategoriseerd naar ernst.

Bij actieve exploitatie geldt de 24-uurs meldtermijn aan ENISA. Na beschikbaarheid van een patch of op de responsible disclosure deadline wordt een volledig security advisory gepubliceerd.

Secure update pipeline en NIS2-koppeling

De wet vereist ook dat producten beveiligingsupdates kunnen ontvangen gedurende de verwachte levensduur. Alle updatepakketten moeten worden ondertekend met een sleutel die is opgeslagen in een hardware security module. Het apparaat of de software verifieert de handtekening vóór installatie. Rollback-bescherming voorkomt dat een bijgewerkt systeem terugkeert naar een kwetsbare versie zonder expliciete autorisatie.

De CRA en NIS2 overlappen en versterken elkaar. Fabrikanten die tegelijkertijd onder NIS2 vallen als essentiële of belangrijke entiteit moeten aan beide voldoen. Als inkoper van software kun je de CRA ook gebruiken als lever bij leverancierseisen: vraag om het actuele SBOM, de vulnerability disclosure policy en het PSIRT-contactadres.

Standpunt

De CRA is in mijn ogen een van de meest concrete stappen die de EU heeft gezet op het gebied van digitale veiligheid. Niet omdat de wet perfect is — er zijn genoeg discussies over de vrijstellingen en de uitvoeringsdetails — maar omdat ze een principieel punt maakt: producten die verbonden zijn met het internet of andere systemen moeten veilig zijn by design, en als dat niet zo is, is de fabrikant aansprakelijk.

Dat is een omslag die ik toejuich. De afgelopen decennia is de markt overspoeld met producten waarvan de beveiliging een bijzaak was. Goedkope IoT-apparaten met standaardwachtwoorden die nooit worden geüpdate. Software die kwetsbaarheden pas patcht na publieke druk. De CRA legt de verantwoordelijkheid terug where it belongs: bij de maker van het product.

Voor CyberSecurity AD heeft de CRA ook relevantie. We bouwen software die wordt ingezet in een juridische context. Onze klanten vertrouwen erop dat onze componenten up-to-date en veilig zijn. SBOM-transparantie en een PSIRT-functie zijn voor ons dan ook geen CRA-compliance-exercitie; het zijn de normale uitdrukking van professionele verantwoordelijkheid.

Ik wil ook iets zeggen over de SBOM-discussie specifiek. Er zijn partijen die het SBOM zien als een last — een verplichting om transparant te zijn over de innards van hun software. Ik zie het anders. Een SBOM is het bewijs dat je weet wat er in je product zit. Als je dat niet weet, heb je een ander probleem. Transparantie over de componentenlijst is een gezondheidscheck voor je eigen ontwikkelproces.