Status per 11 augustus 2026. De EU Cyber Resilience Act (Verordening (EU) 2024/2847) stelt cybersecurity-eisen voor producten met digitale elementen die op de Uniemarkt worden gebracht. Praktische richtlijnen van de Commissie zijn gepubliceerd op 27 juli 2026. Meldingsgerelateerde verplichtingen gelden vanaf 11 september 2026; de hoofdset productverplichtingen geldt vanaf 11 december 2027. Deze gids is bedoeld voor software-ingenieurs van producten die mogelijk binnen de scope vallen, niet voor conformiteitsbeoordelingsjuristen.
Eerlijkheid over de scope eerst: CRA is geen vervanging voor SOC 2, ISO 27001 of de GDPR. Het is geen "nog een compliance-bot-vinkje." Veel CRA-verplichtingen betreffen de fabrikant, documentatie en postmarktprocessen. Alleen een deel kan in een normale applicatie-pull request aan het licht komen: afhankelijkheidsinventaris en SBOM-actualiteit, kwetsbaarheidsmeldingsroutes en beveiligingscontroles die als dode code zijn verwijderd. Als je juridische of productteam niet heeft bevestigd dat CRA van toepassing is op wat je levert, stop dan hier en vraag het hen.
Wat wanneer van kracht is (ontwikkelaarskalender)
Vanaf 11 september 2026 beginnen de meldingsverplichtingen die verbonden zijn aan het kwetsbaarheids- en incidentmeldingsregime van de Act te gelden, volgens de tijdlijn die de Verordening en de richtlijnen van de Commissie voor fabrikanten vaststellen. Vanaf 11 december 2027 gelden de belangrijkste productcybersecurity-eisen (inclusief secure-by-design-verwachtingen, kwetsbaarheidsbeheerprocessen en SBOM-gerelateerde transparantie voor producten met digitale elementen) breder. De exacte classificatie van je product (standaard, belangrijk, kritiek) is een juridische en productvraag, niet iets wat een code review beslist.
Behandel die data als planningsankers. Als correcties in het Publicatieblad of verdere richtlijnen deze data wijzigen, valideer dan deze pagina opnieuw (zie het datumsversheidsregister).
Wat daadwerkelijk in een pull request kan opduiken
Afhankelijkheids- en SBOM-actualiteit: een wijziging pakt een verouderde component vast, verwijdert de generatie van een software bill of materials uit CI, of stopt met publiceren van de componenteninventaris waar je kwetsbaarheidsproces van afhankelijk is. Kwetsbaarheidsbeheerpad: een wijziging verwijdert of hardcodeert een beveiligingscontact, adviesfeed of interne kwetsbaarheidstriage-webhook die je CRA-conforme proces veronderstelt te bestaan. Secure-by-design-erosie: een "opruim"-PR verwijdert authenticatie op een admin-poort, schakelt updatecontroles uit of schakelt integriteitsverificatie op updatepakketten uit omdat ze te veel lawaai maakten.
Dit zijn technische vormen. Ze vormen geen volledige CRA-conformiteitsdossier, CE-markeringverhaal of beoordeling door een aangemelde instantie.
Uitgewerkt voorbeeld: CI stopt met het genereren van de componenteninventaris
Een platformteam verkort CI met twee minuten door een taak te verwijderen die syft (of equivalent) uitvoerde en een SBOM-artefact uploadde bij elke releasetag. De Dockerfile en app bouwen nog steeds. Tests blijven groen. Reviewopmerkingen gaan over pipelinekosten. Weken later kan het beveiligingsteam niet beantwoorden "welke versies zijn geleverd in 1.8.3" zonder reconstructie uit lagen.
Als je product binnen de CRA-scope valt en je proces afhankelijk is van die inventaris voor kwetsbaarheidsbeheer en transparantie, is de verwijderde taak geen neutrale hygiëne. Een compliance-bewuste review markeert het verlies van de inventarisstap in de PR, zodat product en beveiliging het risico formeel kunnen accepteren of de taak kunnen herstellen. heygrc die hier een framework-controle citeert, is een signaal, geen bevestiging dat het product niet-conform is.
Expliciete niet-doelen
Deze gids behandelt niet: conformiteitsbeoordelingsmodules, CE-markering, fabrikantregistratie, het opstellen van een EU-conformiteitsverklaring of of je product "belangrijk" of "kritiek" is onder de Act. Het beweert niet dat heygrc een product CRA-conform maakt. Het vervangt niet je PSIRT, juridische review of markttoezichtsresponsplan.
Als je alleen SOC 2 of ISO 27001 voor klanten nodig had, kan CRA nog steeds irrelevant zijn. Forceer het niet.
Waar heygrc past, en de eerlijkheidsgrens
heygrc is gebouwd om controle-relevante pull request-wijzigingen te tonen tegen de frameworks die je inschakelt. Voor CRA-gerelateerde engineeringhygiëne is de nuttige overlap dezelfde klasse bevindingen als veilige ontwikkeling en kwetsbaarheidsbeheer onder andere frameworks (bijvoorbeeld NIS 2 Art. 21 software-eisen, ISO 27001 veilige ontwikkelingscontroles): verwijderde update-integriteitscontroles, verzwakte authenticatie, verwijderde inventaristaken. Map voorzichtig; verzin geen CRA-artikelnummers voor bevindingen tenzij je ingeschakelde kennisbank deze bevat.
Houd SAST, afhankelijkheidsscanners en je code-reviewer aan. CRA-productwetgeving bevindt zich grotendeels buiten de diff. De diff detecteert alleen het deel dat stilletjes verwijdert wat die programma's veronderstellen nog te draaien.