De Cyber Resilience Act: uw product, niet uw landschap
De CRA reguleert het product met digitale elementen dat u op de markt brengt — een ander systeem dan de infrastructuur waarop u het draait. Een groot deel van de compliancemarkt vervaagt die grens; deze gids trekt haar. Wat de verordening vraagt, de data die vóór 2027 gaan gelden, het smalle deel dat een externe monitor kan onderbouwen, en de langere lijst die van u blijft, wat u ook koopt.
Geschreven door het SkyQon-engineeringteam · Laatst gecontroleerd op 6 augustus 2026
Wat de CRA reguleert
Verordening (EU) 2024/2847 stelt cyberbeveiligingseisen aan producten met digitale elementen — software en hardware die op de EU-markt worden gebracht, samen met hun oplossingen voor gegevensverwerking op afstand. Het is productwetgeving in de traditie van de CE-markering: conformiteitsbeoordeling onder artikel 32, EU-conformiteitsverklaring onder artikel 28, CE-markering onder artikel 30, markttoezicht onder artikel 52. De naaste verwanten zijn de speelgoed- en machinerichtlijn, niet NIS2.
Die afkomst bepaalt wie de plichten draagt. Ze rusten op de fabrikant — artikel 13 telt er vijfentwintig leden van op — met importeurs en distributeurs die verderop in de keten hun eigen plichten oppakken, en artikel 24 dat beheerders van opensourcesoftware een bewust lichter regime geeft. Er is geen "valt de entiteit eronder"-toets zoals bij NIS2: brengt u een product binnen het toepassingsgebied op de EU-markt, dan valt u eronder.
De inhoud staat in bijlage I. Deel I somt de beveiligingseigenschappen op die het product zelf moet hebben — veilige standaardconfiguratie, bescherming van vertrouwelijkheid en integriteit, beperking van het aanvalsoppervlak, en de rest. Deel II somt de eisen voor kwetsbaarheidsafhandeling op: een SBOM die ten minste de topniveau-afhankelijkheden van het product dekt, het zonder vertraging verhelpen van kwetsbaarheden, een beleid voor gecoördineerde openbaarmaking, en veilige verspreiding van beveiligingsupdates.
Officiële tekst: Regulation (EU) 2024/2847
De data, en welke het eerst komt
De verordening trad op 10 december 2024 in werking en is volledig van toepassing vanaf 11 december 2027. Twee onderdelen komen eerder: hoofdstuk IV, over aangemelde instanties, geldt sinds 11 juni 2026 — en artikel 14, de meldplicht, geldt vanaf 11 september 2026.
Artikel 69, lid 2, verzacht het beeld voor bestaande producten: wat vóór 11 december 2027 op de markt is gebracht, valt er alleen onder bij een latere substantiële wijziging. Vervolgens neemt artikel 69, lid 3, die verzachting terug voor het onderdeel dat het eerst speelt — in afwijking daarvan geldt artikel 14 voor alle producten binnen het toepassingsgebied die al op de markt zijn. De meldplicht is niet uitgesteld tot 2027 en niet beperkt tot nieuwe producten.
De eerste CRA-verplichting die de meeste fabrikanten zullen voelen, is dus een klok: vanaf 11 september 2026 start een actief uitgebuite kwetsbaarheid in een jaren geleden geleverd product een aftelling van 24 uur. Op het moment van schrijven is dat over vijf weken.
Het boeteplafond geeft de data hun gewicht. Artikel 64, lid 2, stelt bestuurlijke boetes tot 15 miljoen euro of 2,5% van de totale wereldwijde jaaromzet, welk bedrag het hoogst is, op niet-naleving van bijlage I of van de artikelen 13 en 14.
Artikel 14 in de praktijk
Twee triggers, één route. Een fabrikant die kennisneemt van een actief uitgebuite kwetsbaarheid in zijn product, of van een ernstig incident met gevolgen voor de beveiliging van het product, meldt dit gelijktijdig aan het als coördinator aangewezen CSIRT en aan ENISA, via het centrale meldplatform van artikel 16.
| Stap | Actief uitgebuite kwetsbaarheid | Ernstig incident |
|---|---|---|
| Vroegtijdige waarschuwing | Binnen 24 uur na kennisneming | Binnen 24 uur na kennisneming |
| Melding | Binnen 72 uur — aard van de exploit, genomen corrigerende of mitigerende maatregelen en wat gebruikers kunnen doen | Binnen 72 uur — aard van het incident, eerste beoordeling, genomen maatregelen en wat gebruikers kunnen doen |
| Eindrapport | Uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is | Binnen één maand na de 72-uursmelding |
De formulering die het gewicht draagt, is "kennisneming". Een fabrikant die op dag één van de uitbuiting hoort en op dag zes begint te schrijven, heeft al twee deadlines gemist. Een 24-uursklok halen is een eigenschap van uw detectie- en escalatieketen, niet van uw juridische afdeling — en daarmee het enige deel van artikel 14 dat u vooraf kunt oefenen.
Artikel 13: de plichten achter de CE-markering
Artikel 13 is de kernverplichtingenset van de fabrikant. Het product moet worden ontworpen, ontwikkeld en geproduceerd volgens de essentiële eisen van bijlage I, op basis van een gedocumenteerde en actueel gehouden cyberbeveiligingsrisicobeoordeling die bepaalt welke eisen van bijlage I van toepassing zijn en hoe ze worden uitgevoerd.
Artikel 13, lid 8, voegt de toezegging met de langste doorlooptijd toe: een ondersteuningsperiode, bepaald door de verwachte gebruiksduur van het product, en — onverminderd die beoordeling — van ten minste vijf jaar, tenzij de verwachte gebruiksduur korter is. Gedurende die hele periode moeten kwetsbaarheden in het product en zijn componenten worden afgehandeld volgens bijlage I, deel II. Een ondersteuningsperiode is een belofte over uw engineeringorganisatie over jaren — die hoort in de productplanning, niet in een compliancemap.
Daaromheen liggen de zorgvuldigheid rond componenten van derden, de technische documentatie, de conformiteitsbeoordelingsroute — zelfbeoordeling voor de standaardklasse, betrokkenheid van een derde partij bij belangrijke en kritieke producten —, de conformiteitsverklaring en de CE-markering. Dat alles is het eigen werk van de fabrikant, en niets ervan is van buitenaf waarneembaar.
De grens die compliancemarketing het vaakst vervaagt
NIS2 reguleert een entiteit. DORA reguleert een financiële entiteit en haar ICT-leveranciers. Beide stellen vragen over een organisatie, en een organisatie laat waarneembare sporen na — certificaten, DNS-records, mailbeleid, TLS-handshakes. Daarom kan een externe monitor eerlijk een deel van het bewijs voor die twee kaders leveren.
De CRA stelt een vraag over het geleverde artefact. Een externe monitor heeft uw product nooit gezien: niet zijn binary, niet zijn updatemechanisme, niet zijn standaardconfiguratie, niet zijn afhankelijkheidsboom. Een organisatie kan een vlekkeloos extern landschap hebben en toch een niet-conform product leveren — en het omgekeerde is net zo goed mogelijk.
De eerlijke consequentie: geen enkel monitoringproduct, het onze inbegrepen, kan dekking van CRA-conformiteit claimen. Wat externe monitoring wél kan, is smaller — een klein aantal eigenschappen van bijlage I aantonen zoals ze op het landschap van de fabrikant zichtbaar zijn, duidelijk gelabeld als landschapsgebonden, plus één werkelijk operationele bijdrage: de detectiesnelheid die de klokken van artikel 14 veronderstellen.
Wat SkyQon bewijst, precies gezegd
Het SkyQon-bewijsrapport bevat een CRA-sectie — geen apart product. De sectie opent met een scopeverklaring die met zoveel woorden zegt dat zij geen verklaring van CRA-conformiteit is en dat SkyQon geen producten beoordeelt. Ze koppelt precies twee eigenschappen van bijlage I, en de mappingtekst hieronder wordt woordelijk uit een geversioneerde regelgevingsmapping in de ondertekende PDF opgenomen.
| Eis uit bijlage I | Geleverd bewijs | Dekking |
|---|---|---|
| Part I, (2)(e) | Vertrouwelijkheid: transportversleutelingshouding over het externe landschap van de fabrikant — TLS-versies, ciphersuites, sleutelsterkte en post-quantumgereedheid, gevolgd in de tijd. | Alleen landschap — niet geclaimd als productconformiteit |
| Part I, (2)(f) | Integriteit: validatie van het vertrouwenspad van certificaten en intrekkingsstatus — of de identiteiten die de fabrikant aan het internet toont naar een vertrouwde root leiden en niet zijn ingetrokken. | Alleen landschap — niet geclaimd als productconformiteit |
Twee regels, met hetzelfde label. Elk draagt in het rapport ook een scopenotitie die zegt wat de eis binnen het product regelt — vertrouwelijkheidsbescherming in het geleverde artefact, secure boot, ondertekende updates — en dat SkyQon daar niets van waarneemt. De tweede helft van de sectie is de lijst verplichtingen die volledig de uwe blijven, opgesomd omdat een leemte die u zelf verklaarde heel anders leest dan een leemte die een beoordelaar vindt.
Buiten het rapport levert doorlopende monitoring één operationele bijdrage aan artikel 14: detectie met tijdstempels. Een waarschuwingsklok van 24 uur wordt haalbaar wanneer de kennisneming uit monitoring komt in plaats van van een klant — en de gedateerde registratie van het moment waarop u het wist, is het eerste artefact waar een toezichthouder om vraagt.
Wat volledig van u blijft
Het rapport benoemt ze omdat fabrikanten vaak aannemen dat een bestaand bedrijfsbeveiligingsprogramma ze al dekt. Dat is doorgaans niet zo — het zijn productverplichtingen, en elk ervan is geciteerd uit of afgeleid van de tekst in het Publicatieblad.
- Een product-SBOM — machineleesbaar, ten minste de topniveau-afhankelijkheden van het product dekkend (bijlage I, deel II, punt 1). Een cryptografische inventaris van uw landschap is nuttige input voor dit werk; het is een ander artefact over een ander systeem, en het kwijt u niet van de plicht.
- Productkwetsbaarheden zonder vertraging verhelpen — inclusief beveiligingsupdates die, waar technisch haalbaar, gescheiden van functionele updates worden geleverd (deel II, punt 2).
- Een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden — ingevoerd en gehandhaafd (deel II, punt 5). Een bestaand bedrijfsbeveiligingsbeleid is dat doorgaans niet.
- Veilige verspreiding van beveiligingsupdates — zonder vertraging en kosteloos verspreid, met adviserende berichten (deel II, punten 7 en 8).
- Veilige standaardconfiguratie en updates standaard aan — ontwerpeigenschappen van het product (deel I, punten 2 b) en 2 c)) die geen externe waarnemer ooit ziet.
- De artikel 14-melding zelf — de meldingen aan het coördinerende CSIRT en aan ENISA zijn aan u; monitoring kan uw klok eerlijk starten, niet voor u indienen.
Een praktische volgorde
- Classificeer eerst uw producten. Wat van wat u levert een product met digitale elementen is, in welke klasse het valt en welke conformiteitsroute daaruit volgt. Al het overige in de CRA wordt door dat antwoord bepaald.
- Oefen de artikel 14-klok vóór september 2026. Doe de oefening: uitgebuite kwetsbaarheid gemeld op een vrijdagavond — wie neemt er wanneer kennis van, en wie heeft de platformcredentials om binnen 24 uur in te dienen. De geïnstalleerde basis valt eronder, dus dit wacht niet op uw volgende release.
- Bouw de SBOM vanuit het buildsysteem, niet vanuit een enquête. Handmatig samengestelde afhankelijkheidslijsten verrotten; bijlage I vraagt iets dat een pipeline bij elke release opnieuw kan genereren.
- Beslis de ondersteuningsperiode als productbeslissing. Vijf jaar kwetsbaarheidsafhandeling is een engineeringtoezegging. Begroot het, bemens het, en schrijf op voor welke componenten u van derden afhangt.
- Publiceer het openbaarmakingsbeleid. Een beleid voor gecoördineerde openbaarmaking is goedkoop om te schrijven, voor iedereen zichtbaar, en een van de eerste dingen die een markttoezichthouder kan controleren zonder u iets te vragen.
- Houd landschapsbewijs en productconformiteit in aparte mappen. Beide zijn echt werk. Ze mengen is hoe overclaims ontstaan — en een overclaim op een CE-gemarkeerd product is een gesprek met een markttoezichthouder.
Veelgestelde vragen
Wanneer is de CRA van toepassing?
Volledig vanaf 11 december 2027. Hoofdstuk IV, over aangemelde instanties, geldt sinds 11 juni 2026, en de meldplichten van artikel 14 gelden vanaf 11 september 2026 — op grond van artikel 69, lid 3, ook voor producten die al op de markt zijn.
Raakt hij producten die we jaren geleden leverden?
Voor de algemene eisen alleen als het product na 11 december 2027 substantieel wordt gewijzigd. Voor de artikel 14-melding wél — de afwijking in artikel 69, lid 3, past haar toe op alle producten binnen het toepassingsgebied die al op de markt zijn.
Valt opensourcesoftware eronder?
Software die in het kader van een commerciële activiteit wordt geleverd wel; artikel 24 geeft beheerders van opensourcesoftware een eigen, lichter regime. De details hangen af van hoe de software wordt gemonetariseerd en geleverd, en zijn het waard in de tekst zelf te lezen in plaats van in een samenvatting.
Hoe lang is de ondersteuningsperiode?
Bepaald door de verwachte gebruiksduur, en ten minste vijf jaar tenzij het product korter dienst zal doen (artikel 13, lid 8). De kwetsbaarheidsafhandeling van bijlage I, deel II, geldt voor de hele periode.
Kan een monitoringtool ons CRA-conform maken?
Nee. Conformiteit is een eigenschap van het product en zijn documentatie, beoordeeld onder artikel 32. Externe monitoring kan landschapsgebonden ondersteunend materiaal en eerlijke detectietijdstempels leveren; een leverancier die meer claimt, beschrijft een systeem dat hij nooit heeft gezien.
Hoe verhoudt de CRA zich tot NIS2?
Ze reguleren verschillende dingen — het product dat u levert en de entiteit die u bent — en kunnen tegelijk op u van toepassing zijn. Bewijs over uw landschap dient NIS2 rechtstreeks; onder de CRA is hetzelfde bewijs alleen ondersteunend materiaal, en zo labelt het rapport het ook.
Bijbehorende gids: NIS2 artikel 21(2) — wat als bewijs telt · DORA — wat als technisch bewijs telt
Zie wat uw landschap vandaag zegt
SkyQon verkoopt u geen CRA-conformiteit — dat kan niemand eerlijk. Wat u krijgt: het landschapsgebonden bewijs, duidelijk gelabeld, in hetzelfde ondertekende rapport als uw NIS2-werk, en de detectiesnelheid die de klokken van artikel 14 veronderstellen. Begin met een gratis controle van uw externe landschap.