De eerste deadline van de Cyber Resilience Act (CRA) die productteams raakt, is 11 september 2026, wanneer de meldplicht ingaat. De hoofdverplichtingen volgen op 11 december 2027. Melden hangt af van processen en mensen, en die zijn traag op te bouwen. Daarom komt dit onderdeel vóór alles.
Wat geldt wanneer
De CRA is Verordening (EU) 2024/2847. Volgens de CRA-pagina van de Europese Commissie stelt de verordening verplichte cybersecurityeisen aan fabrikanten, gedurende de planning, het ontwerp, de ontwikkeling en het onderhoud van producten met digitale elementen. Ook moeten fabrikanten kwetsbaarheden gedurende de hele levenscyclus van het product afhandelen.
| Datum | Wat gebeurt er |
|---|---|
| 10 december 2024 | De CRA trad in werking |
| 11 september 2026 | De meldplicht gaat gelden |
| 11 december 2027 | De hoofdverplichtingen gaan gelden |
Conforme producten krijgen de CE-markering en nationale markttoezichtautoriteiten handhaven de regels. Voor sommige producten die voor cybersecurity bijzonder relevant zijn, kan vóór verkoop op de EU-markt een beoordeling door een aangemelde instantie (notified body) nodig zijn. Bepaal vroeg aan welke kant van die grens uw product valt, want het beïnvloedt uw tijdlijn.
De Commissie publiceerde op 27 juli 2026 ook praktische richtsnoeren voor fabrikanten. Lees die voordat u zich vastlegt op een ontwerp voor een van de onderstaande processen.
Bewijs van veilige ontwikkeling
Toezichthouders en klanten zullen vragen wat u hebt gedaan. Bouw daarom documentatie op als bijproduct van het gewone werk, in plaats van die achteraf te reconstrueren. Een erkende structuur helpt daarbij.
Het NIST Secure Software Development Framework, SP 800-218, is een basisset van overkoepelende praktijken die u toevoegt aan de SDLC die u al hanteert. De uitgesproken doelen zijn minder kwetsbaarheden in uitgebrachte software, minder impact van de kwetsbaarheden die overblijven, en het aanpakken van grondoorzaken zodat ze niet terugkeren. Ook biedt het een gemeenschappelijk vocabulaire voor gesprekken met afnemers en leveranciers. Het is een Amerikaans document en geen CRA-checklist, dus gebruik het als steiger.
Bewijs dat het bewaren waard is, per release:
- het threat model of de designreview die de wijziging heeft gedekt
- resultaten van code reviews en tests, inclusief securitytests
- lijsten van dependencies met versies, en wat u hebt besloten over bekende kwetsbaarheden daarin
- de releasegoedkeuring, met een naam en een datum
Het Secure by Design-materiaal van CISA voegt twee praktische punten toe. Eigenaarschap hoort op directieniveau te liggen en standaardinstellingen doen ertoe: MFA, logging en SSO moeten direct beschikbaar zijn, zonder extra kosten. Verkoopt uw product deze functies als betaalde add-ons, verwacht dan vragen daarover. CISA publiceert ook richtlijnen over roadmaps voor memory safety, die het lezen waard zijn als uw code in C of C++ is geschreven.
Kwetsbaarhedenbeheer en melden
Vanaf 11 september 2026 moeten fabrikanten actief uitgebuite kwetsbaarheden melden, samen met de andere onderdelen die op de meldpagina van de Commissie staan. Raadpleeg die pagina voor de exacte reikwijdte en het te gebruiken kanaal. Vertrouw niet op een samenvatting, ook niet op deze.
Wat u intern nodig hebt, wat de uiteindelijke details ook zijn:
- Eén meldpunt. Een bewaakt securitycontact op de productsite en in de documentatie, met een benoemde eigenaar en een vervanger.
- Een triageroutine. Iemand besluit binnen een vaste termijn of een melding geldig is, of de kwetsbaarheid wordt uitgebuit en welke producten en versies erdoor worden geraakt. Een consistente ernstscore maakt dit sneller. Onze CVSS-calculator is handig om in het team tot overeenstemming over scores te komen.
- Een beslispad voor melden. Leg vast wie beslist dat een uitgebuite kwetsbaarheid een melding vereist en wie die indient. Oefen dit één keer met een fictieve casus, buiten kantooruren als dat het moment is waarop het echt zou gebeuren.
- Een register van elk besluit. Ook van meldingen die u buiten scope achtte, met de reden.
Melden werkt niet als u niet weet wat er in uw product zit. Houd voor elke geleverde versie een actuele componentinventaris bij, want uit het hoofd kunt u de blootstelling aan een nieuwe kwetsbaarheid niet beoordelen.
Updateprocessen
De Commissie noemt het ontbreken van tijdige beveiligingsupdates als een van de problemen die de CRA aanpakt. Producten moeten zo worden ontworpen, bijgewerkt en onderhouden dat gebruikers beschermd zijn. In de praktijk betekent dat: test uw updatepad even serieus als uw functionaliteit.
Controleer het volgende voor elke productlijn:
- U kunt een beveiligingsfix los van een featurerelease uitbrengen.
- Klanten kunnen merken dat er een update is, en het installeren ervan vraagt geen telefoontje naar support.
- Oude versies hebben een duidelijke einddatum van ondersteuning, die klanten vóór aankoop kunnen zien.
- Voor hardware: u hebt getest hoe een apparaat dat een jaar offline is geweest wordt bijgewerkt, en hoe u een apparaat herstelt waarbij de update halverwege mislukt.
De veelvoorkomende hindernis is niet de techniek maar het eigenaarschap. Veel teams kunnen in een dag een patch bouwen en zijn daarna drie weken kwijt aan het uitzoeken wie hem mag vrijgeven.
Technische documentatie
De bronnen die ik heb gebruikt noemen de vereiste inhoud van het technisch dossier niet. Haal die dus uit de wettekst en de richtsnoeren van de Commissie. Het praktische punt is dat documentatie continu moet worden samengesteld uit het bovenstaande bewijs, en niet in het laatste kwartaal voor de deadline wordt geschreven.
Geef elk product een documentatiemap of een sectie in de repository, met een eigenaar. Zet daarin het ontwerp en de risicobeoordeling, de componentinventaris, testresultaten, de procedure voor kwetsbaarhedenbeheer en het updatebeleid. Versioneer het samen met het product. Als een auditor of autoriteit om een dossier vraagt, wilt u het kunnen exporteren en niet hoeven laten opstellen.
Valt u ook onder de NIS2-richtlijn, die volgens de Commissie wordt aangevuld door de CRA, hergebruik dan dezelfde incident- en kwetsbaarheidsprocedures in plaats van twee sets te onderhouden.
Waar begint u
- Lees de richtsnoeren van de Commissie van 27 juli 2026 en de meldpagina, en noteer welke van uw producten binnen de scope vallen en of er bij een aangemelde instantie getoetst moet worden.
- Benoem een eigenaar voor het ontvangen van kwetsbaarheidsmeldingen en het melden van uitgebuite kwetsbaarheden, publiceer een securitycontact en houd dit kwartaal één oefening.
- Maak een componentinventaris voor elke ondersteunde release en maak het genereren ervan onderdeel van uw build.
- Leg uw huidige SDLC naast de SSDF-praktijken, leg de hiaten vast en begin per release met het bewaren van review-, test- en goedkeuringsdocumentatie.
- Test uw updatepad van begin tot eind en publiceer per product de einddatum van ondersteuning.
- Maak de documentatiemap per product en vul die met wat u al hebt. Wilt u een externe blik op de hiaten, dan dekken onze adviesdienst en onze dienst voor veilige softwareontwikkeling precies dit.
