De Cyber Resilience Act: 11 september 2026 is een echte deadline

De meeste EU-verordeningen geven je een nalevingsdatum en een overgangsperiode waarin iedereen zich rustig organiseert. De Cyber Resilience Act doet iets anders. De eerste harde verplichting is een meldklok van 24 uur, en die start op 11 september 2026.

Een klok van 24 uur kun je niet geleidelijk invoeren. Of het proces bestaat op die dag, of je haalt het niet.

Wat de CRA is

Verordening (EU) 2024/2847 stelt cyberbeveiligingseisen aan producten met digitale elementen die op de EU-markt worden aangeboden. Die term dekt veel meer dan mensen aanvankelijk aannemen: elk software- of hardwareproduct, en de bijbehorende oplossingen voor gegevensverwerking op afstand, waarvan het beoogde of redelijkerwijs te voorziene gebruik een directe of indirecte gegevensverbinding omvat.

Verbonden apparaten vallen eronder. Ook de meeste commerciële software, besturingssystemen, browsers, mobiele apps, firmware en de componenten in andere producten.

De verordening verscheen in november 2024 en geldt gefaseerd:

• 11 juni 2026: verplichtingen voor conformiteitsbeoordelingsinstanties.
• 11 september 2026: meldplicht voor actief misbruikte kwetsbaarheden en ernstige incidenten.
• 11 december 2027: volledige toepassing, inclusief essentiële cyberbeveiligingseisen, CE-markering, technische documentatie en de software bill of materials.

De middelste datum is die om op te plannen, want die komt eerst en hangt af van capaciteiten die je misschien niet hebt.

Wat er gebeurt op 11 september 2026

Vanaf die datum moeten fabrikanten melden:

Actief misbruikte kwetsbaarheden in hun producten met digitale elementen, en

ernstige incidenten die de beveiliging van die producten raken.

Melden gaat via het CRA Single Reporting Platform, beheerd door ENISA, naar het aangewezen CSIRT in de lidstaat van de hoofdvestiging van de fabrikant, dat vervolgens deelt met andere betrokken CSIRT's en met ENISA.

De tijdlijn:

• Binnen 24 uur na kennisname: een vroege waarschuwing.
• Binnen 72 uur: een volledige melding, inclusief genomen corrigerende of mitigerende maatregelen.
• Binnen 14 dagen nadat een corrigerende maatregel beschikbaar is: een eindrapport voor een actief misbruikte kwetsbaarheid.
• Binnen een maand: een eindrapport voor een ernstig incident.

Vierentwintig uur vanaf kennisname, niet vanaf bevestiging, niet vanaf herstel. Wordt een kwetsbaarheid in een component van je product op een zaterdag in het wild misbruikt, dan loopt de klok op zaterdag.

Waarom dit lastiger is dan het lijkt

De meldplicht zelf is een formulier. De moeilijkheid zit in alles wat je op orde moet hebben voordat je dat kunt invullen.

Je moet weten wat er in je product zit

Om te melden dat een kwetsbaarheid in je product actief wordt misbruikt, moet je weten dat de kwetsbare component in je product zit. Voor een moderne applicatie met honderden transitieve afhankelijkheden is dat niets wat een mens uit het hoofd beantwoordt.

Daarom bouwen teams nu pijplijnen voor de software bill of materials, ruim een jaar voor de formele SBOM-eis van december 2027. De SBOM is niet het doel. Het doel is de vraag «worden wij geraakt?» binnen uren kunnen beantwoorden, en de SBOM maakt die vraag beantwoordbaar.

Het vervelende is dat dit ook geldt voor producten die je jaren geleden hebt uitgeleverd. Heb je ondersteunde apparaten in het veld met firmware uit 2022 gebouwd op een afhankelijkheidsboom die niemand vastlegde, dan is reconstrueren echt werk.

Je moet meekijken

Kennisname start de klok, en die kennisname wordt actief verwacht in plaats van toevallig. Dat betekent kwetsbaarheidsfeeds volgen, je abonneren op advisories voor je componenten, catalogi van bekende misbruikte kwetsbaarheden bijhouden, en een kanaal hebben waar beveiligingsonderzoekers je kunnen bereiken en antwoord krijgen.

Je moet een beslispad hebben

Iemand moet op elk uur kunnen beslissen of een incident de drempel haalt en of de klok is gestart. Zonder benoemde rol en escalatiepad gaan de eerste uren op aan uitzoeken wie de beslissing mag nemen.

End-of-life-afhankelijkheden worden een aansprakelijkheid

Krijgt een component in je product geen beveiligingsupdates meer, dan draag je de meldplicht bij misbruik nog steeds, en heb je geen upstream-fix om naar te wijzen. Controleren op end-of-life-afhankelijkheden is een van de nuttiger dingen in de aanloop, want het antwoord dwingt soms een migratie af met een eigen doorlooptijd.

Wat volledige toepassing in december 2027 brengt

De verplichtingen van december 2027 vormen het grotere programma, en die moet je lang van tevoren starten.

Beveiliging door ontwerp en standaard. Producten moeten zo worden ontworpen, ontwikkeld en geproduceerd dat een passend, op risico gebaseerd cyberbeveiligingsniveau wordt geborgd. Geen standaardwachtwoorden. Veilige configuratie uit de doos. Minimalisering van het aanvalsoppervlak. Bescherming van data onderweg en in rust.

Kwetsbaarhedenbeheer. Een gedocumenteerd proces voor identificatie, herstel, testen, distributie en openbaarmaking. Beveiligingsupdates moeten zonder vertraging en kosteloos worden geleverd, voor een ondersteuningsperiode die de verwachte levensduur van het product weerspiegelt, met vijf jaar als gangbare referentie.

Software bill of materials. In een machineleesbaar formaat, dat minimaal de eerstelijnsafhankelijkheden dekt en actueel wordt gehouden.

Technische documentatie en conformiteitsbeoordeling. De meeste producten beoordelen zichzelf. Belangrijke en kritieke categorieën, waaronder bijvoorbeeld wachtwoordmanagers, VPN's, besturingssystemen en industriële besturingssystemen, vereisen betrokkenheid van een derde partij.

CE-markering. Het digitale equivalent van het fysieke merk, waarmee je conformiteit verklaart.

Beleid voor gecoördineerde openbaarmaking van kwetsbaarheden. Gepubliceerd, met een contactpunt dat werkt.

Wie er echt onder valt

Een paar grensgevallen komen steeds terug.

Vrije en opensourcesoftware ontwikkeld buiten een commerciële activiteit valt er grotendeels buiten. De verordening introduceert de figuur van de opensource-softwarebeheerder met lichtere verplichtingen. Maar commercialiseer je opensource, of lever je het mee in een product dat je verkoopt, dan zijn de productverplichtingen van jou.

Software als dienst valt doorgaans buiten de CRA en zit eerder onder NIS2, al worden oplossingen voor gegevensverwerking op afstand die integraal deel uitmaken van een product met digitale elementen erbij getrokken. Hangt je apparaat voor zijn werking af van je cloudbackend, dan reist dat backend mee met het product.

Importeurs en distributeurs dragen ook verplichtingen. Breng je een product van derden op de EU-markt onder je eigen naam of merk, dan word je als fabrikant behandeld.

Producten die elders al gereguleerd zijn, zoals medische hulpmiddelen, voertuigen en luchtvaartuitrusting, worden in hun eigen kaders behandeld.

De reikwijdtevragen zijn echt niet triviaal en dit is een plek waar een uur met je juristen maanden verkeerd gerichte engineering bespaart.

Wat wij zouden doen in de resterende tijd

Val je eronder en begin je nu, dan is dit de volgorde die werkt:

Eerst, stel de productinventaris vast. Wat heb je echt op de EU-markt? Inclusief oude versies die nog in het veld staan, whitelabelvarianten en producten die je voor iemand anders distribueert. Die lijst is meestal langer dan iedereen verwacht.

Vervolgens, bouw SBOM-generatie in CI. Genereer bij elke build een SBOM, in CycloneDX of SPDX, sla die op bij het releaseartefact en houd hem doorzoekbaar. Het punt is dat je kunt vragen «welke van onze uitgeleverde releases bevatten deze bibliotheek?» en binnen minuten antwoord krijgt.

Vervolgens, sluit kwetsbaarheidsmonitoring aan. Voed je SBOM-data in een scanner die advisories en catalogi van bekende misbruikte kwetsbaarheden volgt, en stuur meldingen naar een kanaal dat iemand leest.

Vervolgens, schrijf het incidentrunbook. Wie roept uit, wie beoordeelt, wie meldt, wie communiceert. Benoemde mensen, plaatsvervangers en contacten buiten kantooruren. Oefen het daarna één keer met een nepadvisory. In de oefening ontdek je dat degene met de inloggegevens voor het meldplatform op vakantie is.

Vervolgens, publiceer een beleid voor openbaarmaking van kwetsbaarheden. Een security.txt-bestand, een bewaakt adres en een genoemde reactietijd. Dat is een middag werk en het verschil tussen een probleem horen van een onderzoeker of van een journalist.

Ten slotte, begin aan het werk voor december 2027. Veilige standaardinstellingen, updatemechanismen, beslissingen over de ondersteuningsperiode en documentatie zijn architectuurvragen, geen papierwerk. Producten die je in 2026 ontwerpt staan in 2028 nog op de markt.

De overlap die niemand benut

Er is aanzienlijke duplicatie tussen de CRA en andere regimes, en de meeste bedrijven behandelen ze los, wat verspilling is.

Een SBOM gebouwd voor de CRA beantwoordt de meeste ketenvragen uit NIS2. Het incidentrunbook overlapt met de vroege waarschuwing van 24 uur uit NIS2 en met de datalekmelding van 72 uur uit de AVG. Processen voor kwetsbaarhedenbeheer voeden direct de beveiligingsvragenlijsten van klanten en enterprise-inkoop.

Bouw dit één keer als platformcapaciteit. Het alternatief is drie teams die drie versies van dezelfde assetinventaris bouwen.

Waar je hulp krijgt

Wij bouwen en onderhouden software voor bedrijven die naar de EU verkopen, wat steeds vaker betekent dat we de ketentransparantie en updateinfrastructuur bouwen die de CRA veronderstelt. Zoek je uit of je eronder valt, of staat de septemberdatum in de agenda zonder enige monitoring, neem dan contact op via office@c9group.dev.

Onze dienst voor onderhoud van legacysystemen is vaak het startpunt, want de producten met de slechtste zicht op afhankelijkheden zijn meestal de oudste. Het bredere regelgevende beeld staat in onze gids EU digitale compliance 2026.

Wij zijn ingenieurs, geen juristen. Reikwijdte- en kwalificatiebeslissingen horen bij je juristen, en wij bouwen naar het antwoord dat zij geven.