Er is iets gebeurd. Wanneer werd u zich ervan bewust?

De Cyber Resilience Act voor een kleine softwarefabrikant, in twaalf stappen

Alles wat een bedrijf van tien mensen dat geïnstalleerde software of een apparaat levert onder de CRA moet doen, in de volgorde om het te doen: de scopebepaling, de trede, het CSIRT en de handhaver, de meldprocedure die sinds 11 september 2026 geldt, daarna het technische dossier, de 22 eisen, de SBOM, de ondersteuningsperiode, de CE-markering en de verklaring, verschuldigd op 11 december 2027. Elke stap met zijn artikel en het stuk dat het uitlegt.

Aan welk CSIRT meldt u onder CRA artikel 14? Alle 27 coördinatoren, zoals ENISA ze vermeldt

Elke gids over de meldplicht van de Cyber Resilience Act zegt 'meld bij uw nationale CSIRT' en stopt daar. Sinds 10 september 2026 publiceert ENISA het als coördinator aangewezen CSIRT voor elk van de 27 lidstaten. Hier is die lijst, de regel die de staat bepaalt, en de twee staten waar de coördinator niet het nationale CSIRT is.

Hoe u een CRA-melding indient op het centrale meldplatform van ENISA, uit de eigen handleiding

Het platform ging op 11 september 2026 open op portal.cra-srp.enisa.europa.eu. Wie kan inloggen, welke coördinator u kiest, wat elk van de drie indieningen vraagt, wat de eigen teller van het platform verkeerd doet, en wanneer u om uitgestelde verspreiding mag vragen. Gelezen in de handleiding, FAQ, woordenlijst en gebruiksvoorwaarden van ENISA, niet in een samenvatting daarvan.

Wanneer begint de 24-uursklok van de CRA? 'Kennis krijgen', uit de richtsnoeren van de Commissie

De 24 en 72 uur lopen vanaf het moment waarop de fabrikant 'kennis krijgt', en de verordening zegt nergens wat dat betekent. De richtsnoeren van de Commissie van 27 juli 2026 doen dat wel, in de punten 211 tot 218: een redelijke mate van zekerheid, na een eerste beoordeling, woordelijk overgenomen uit de NIS2-uitvoeringsverordening en de AVG-richtsnoeren over datalekken. Wat dat maakt van een e-mail van een klant, een scannermelding, een gelijste CVE in een component, een bugbounty-zero-day en een kwetsbaarheid die u al vóór 11 september kende.

De klok voor het CRA-eindverslag begint niet wanneer u kennis krijgt

De meeste uitleg van artikel 14 van de Cyber Resilience Act geeft drie termijnen vanaf één startpunt: 24 uur, 72 uur, 14 dagen. De eerste twee lopen vanaf kennisname. De derde niet, en voor een kwetsbaarheid is het ankerpunt een datum die misschien nog niet bestaat. Hier staat wat de verordening zegt, lid voor lid.

Valt uw product onder de Cyber Resilience Act? Waar SaaS staat

De meestgestelde CRA-vraag is niet hoe u meldt, maar of de verordening überhaupt op u van toepassing is. Pure software as a service valt erbuiten en onder NIS2; geïnstalleerde en downloadbare software valt erbinnen; verwerking op afstand waarzonder een product niet werkt, valt er weer binnen. De bepaling is aan u om te maken en vast te leggen. Hier staat de tekst die haar beslist.

Wanneer is software onder de CRA 'in de handel gebracht', en welke van uw builds is een product? De regel van de richtsnoeren voor zelfstandige software

Alles in de CRA hangt aan een datum en een zelfstandig naamwoord: de datum waarop een product in de handel wordt gebracht, en de vraag of wat u uitlevert überhaupt een product is. Voor zelfstandige software beantwoorden de richtsnoeren van de Commissie van 27 juli 2026 beide in de punten 13 tot 21: een versie wordt eenmaal in de handel gebracht, bij het eerste aanbod, en elke latere download telt vanaf die dag; builds per besturingssysteem en functiebundels zijn aparte producten; een webapp in een browser is geen product, een browserextensie of een geïnstalleerde client wel. Wat dat betekent voor 11 december 2027, voor bèta's en voor oude versies die u online laat.

Welke delen van uw backend vallen onder de CRA? Gegevensverwerking op afstand, uit de richtsnoeren van de Commissie

Een product met digitale elementen omvat zijn oplossingen voor gegevensverwerking op afstand, en de verordening definieert die in één zin. De richtsnoeren van de Commissie van 27 juli 2026 maken van die zin twee cumulatieve toetsen, een afbakeningsregel, een lijst van wat er nooit onder valt (CI/CD, HR, CRM, telemetrie, websites), de gevallen SaaS, PaaS en IaaS, en een uitgewerkt voorbeeld van mobiel bankieren. Voor een softwarebedrijf met een app en een cloud is dit de grens.

Wie handhaaft de Cyber Resilience Act in uw lidstaat? 7 van de 27 hebben het gezegd

De CRA wordt nationaal gehandhaafd, door een markttoezichtautoriteit die elke lidstaat aanwijst en bij de Commissie registreert. Op 11 september 2026, de dag waarop de meldplicht inging, hadden zeven lidstaten er een geregistreerd. Hier is het register, lidstaat voor lidstaat, inclusief de twintig die dat niet hebben gedaan, en wat dat betekent voor een kleine fabrikant die vraagt wie er komt aankloppen.

Is uw product belangrijk of kritiek onder de Cyber Resilience Act? Bijlage III en IV volledig

Zodra een product binnen de reikwijdte van de CRA valt, is het standaard, belangrijk (klasse I of II) of kritiek, en de trede bepaalt of u zelf mag beoordelen of een aangemelde instantie nodig heeft. Hier staan de 19, 4 en 3 categorieën letterlijk uit het Publicatieblad, wat elke trede verandert onder artikel 32, en het ene dat de trede niet verandert.

Standaard, belangrijk of kritiek: de 26 technische beschrijvingen van Uitvoeringsverordening 2025/2392, en de kernfunctionaliteitstoets

Bijlage III en IV van de CRA noemen 26 productcategorieën in elk één regel. Uitvoeringsverordening (EU) 2025/2392 van de Commissie, van kracht sinds 21 december 2025, beschrijft elk ervan technisch, en de richtsnoeren van de Commissie van 27 juli 2026 zeggen hoe u ertegen indeelt: naar de kernfunctionaliteit van het product, niet naar wat het ook doet of wat het integreert. Alle 26 beschrijvingen woordelijk, de zes regels van de richtsnoeren met hun voorbeelden (een SOAR is geen SIEM, een logviewer is geen SIEM, een router met firewall is een router), en wat de indeling verandert.

CRA bijlage I: de 22 essentiële eisen, als checklist

Bijlage I van de Cyber Resilience Act is waaraan uw product vanaf 11 december 2027 moet voldoen en wat het technische dossier moet aantonen. Deel I zijn 14 producteisen, waarvan 13 \"waar van toepassing\" op basis van uw risicobeoordeling; deel II zijn 8 eisen voor kwetsbaarheidsbeheer die altijd gelden. Hier staan ze in één tabel, met wat elke eis vraagt en of u haar mag uitsluiten.

Wat in het technische dossier van de CRA hoort: bijlage VII, punt voor punt

Vanaf 11 december 2027 heeft elk product met digitale elementen dat op de EU-markt wordt gebracht vóór het in de handel brengen technische documentatie nodig, te bewaren gedurende tien jaar of de ondersteuningsperiode, wat langer is. Bijlage VII zegt in acht punten wat erin staat. Hier zijn ze, wat elk punt werkelijk vraagt, de vier documenten die deel II van bijlage I veronderstelt, en hoe lang u het bewaart.

Vereist de CRA een SBOM? Ja, en dit is precies wat hij zegt

Bijlage I, deel II, punt 1 van de Cyber Resilience Act vereist een softwarestuklijst in een gangbaar, machineleesbaar formaat die ten minste de afhankelijkheden op het hoogste niveau dekt. Ze hoort in het technische dossier, wordt niet gepubliceerd, en een markttoezichtautoriteit kan er op gemotiveerd verzoek om vragen. De drie zinnen die het beslissen, en wat ze openlaten.

Wat de CRA van u vraagt voor uw afhankelijkheden: zorgvuldigheid, stroomopwaarts melden en bekende uitbuitbare kwetsbaarheden, uit de richtsnoeren van de Commissie

Een softwareproduct bestaat vooral uit andermans code. De CRA maakt de fabrikant verantwoordelijk voor het product als geheel en geeft hem drie plichten jegens de componenten erin: zorgvuldigheid onder artikel 13(5), kwetsbaarheden stroomopwaarts melden en fixes delen onder artikel 13(6), en het product in de handel brengen zonder bekende uitbuitbare kwetsbaarheden. De richtsnoeren van de Commissie van 27 juli 2026, delen 3.4, 7.3 en 9.2, zeggen wat elk vergt en wat niet: geen dubbele meldingen, geen plicht om uw fix gemerged te krijgen, en een definitie van 'bekend' die de CVE-databank en het nieuws omvat.

CRA of NIS2: welke geldt voor een softwarebedrijf, en kan het allebei zijn?

De Cyber Resilience Act reguleert producten die in de handel worden gebracht; NIS2 reguleert entiteiten die diensten verlenen. Een softwarebedrijf kan onder de ene, de andere, beide of geen van beide vallen, en het antwoord hangt af van twee vragen: brengt u een product in de handel, en bent u een middelgrote of grotere entiteit in een genoemde sector. De datums, de meldklokken, de boetes en de beslistabel, uit de twee teksten.

NIS2 of CRA: welke incidentklok loopt voor een softwarebedrijf, en wat maakt een incident 'significant'

Beide wetten geven u 24 uur, 72 uur en een maand, en beide starten de klok wanneer u 'kennis krijgt'. Bijna al het andere verschilt: wat de klok start, wie de melding ontvangt, op welk platform, en wat meetelt. NIS2 artikel 23 en Uitvoeringsverordening 2024/2690 voor het bedrijf dat een clouddienst exploiteert; CRA artikel 14 voor het bedrijf dat een product levert; beide voor het bedrijf dat beide doet. De drempels, criterium voor criterium, en één procedure die aan beide voldoet.

Heeft software een CE-markering nodig onder de CRA? Ja, en artikel 30 zegt waar die komt

Vanaf 11 december 2027 is een CE-markering vereist op elk product met digitale elementen dat op de EU-markt wordt gebracht, software inbegrepen. Voor software komt de markering op de EU-conformiteitsverklaring of op de website die het product begeleidt, vóór het in de handel brengen. Wat de markering beweert, wie haar mag aanbrengen, wanneer het nummer van een aangemelde instantie erbij komt, en wat de verklaring erachter moet bevatten.

De EU-conformiteitsverklaring onder de CRA: bijlage V punt voor punt, de vereenvoudigde vorm en een uitgewerkt voorbeeld

Artikel 28 verplicht de fabrikant vóór het in de handel brengen een EU-conformiteitsverklaring op te stellen volgens het model van bijlage V, en artikel 28(4) maakt het ondertekenen tot de handeling waarmee de fabrikant de verantwoordelijkheid voor het product op zich neemt. De acht punten van bijlage V, de vereenvoudigde vorm van één zin in bijlage VI, de regels eromheen (talen, de enkele verklaring, productfamilies, 10 jaar bewaren), een uitgewerkt voorbeeld, en wat een ontbrekende of onjuiste verklaring kost onder artikel 58 en artikel 64.

Zelfbeoordeling onder de CRA: wat module A werkelijk vereist, uit bijlage VIII en de FAQ van de Commissie

De meeste softwareproducten zullen nooit een aangemelde instantie zien. Zij gebruiken module A, de interne controleprocedure van bijlage VIII, en 'zelfbeoordeling' is het woord dat iedereen ervoor gebruikt zonder te zeggen wat het inhoudt. Bijlage VIII, deel I, telt vijf punten; de FAQ van de Commissie voegt de lijst van activiteiten toe, het feit dat geen testmethodologie is voorgeschreven, waar een softwareproduct zijn CE-markering draagt, de twee vormen van de conformiteitsverklaring, en het tijdschema van de geharmoniseerde normen dat bepaalt wanneer zelfbeoordeling niet langer 'rechtstreeks tegen bijlage I' betekent.

Geharmoniseerde normen voor de CRA: wat normalisatieverzoek M/606 vraagt, wanneer, en wat een fabrikant vandaag heeft

Artikel 27 geeft een vermoeden van conformiteit aan producten die geharmoniseerde normen volgen die in het Publicatieblad zijn bekendgemaakt. Op 3 februari 2025 vroeg de Commissie CEN, CENELEC en ETSI om 41 ervan, met termijnen van 30 augustus 2026 tot 30 oktober 2027; de drie aanvaardden op 3 april 2025. Op 12 september 2026 heeft de index van geharmoniseerde normen van de Commissie nog geen vermelding voor de verordening, wat voor een product van klasse I betekent: geen route van zelfbeoordeling onder artikel 32(2). Wat is gevraagd, de data, en waartegen intussen te bouwen.

Hoe lang is de ondersteuningsperiode van de CRA? Ten minste vijf jaar, en drie andere klokken die eraan hangen

Artikel 13, lid 8, van de Cyber Resilience Act vereist een ondersteuningsperiode van ten minste vijf jaar, of de verwachte gebruiksduur als die korter is, waarin kwetsbaarheden worden beheerd. De einddatum moet bij aankoop worden getoond, ten minste maand en jaar. Beveiligingsupdates moeten tien jaar of de ondersteuningsperiode beschikbaar blijven. En het technische dossier, de verklaring en de gebruikersinformatie worden even lang bewaard. De vier klokken, uit de tekst.

Welke update brengt uw bestaande software onder de CRA? Substantiële wijzigingen, uit de richtsnoeren van de Commissie

Software die vóór 11 december 2027 in de handel is gebracht, blijft buiten de ontwerp- en conformiteitsplichten van de CRA totdat zij substantieel wordt gewijzigd. De richtsnoeren van de Commissie van 27 juli 2026 zeggen in de punten 103 tot 113 en 122 tot 124 wat dat voor een software-update betekent, met elf uitgewerkte voorbeelden: een risico dat niet in uw risicobeoordeling staat, niet de omvang van de diff. Beveiligingsupdates vallen er doorgaans buiten; een vakje 'onthoud mij' kan eronder vallen. Wat in elke release moet staan, en wat de eerste substantiële wijziging wel en niet in gang zet.

Wat u onder de CRA moet melden: de twee triggers, zoals de verordening ze definieert

Artikel 14 heeft twee triggers en beide zijn in de tekst gedefinieerd. Een actief uitgebuite kwetsbaarheid is er een waarvoor betrouwbaar bewijs bestaat dat een kwaadwillende actor die zonder toestemming van de eigenaar in een systeem heeft uitgebuit (artikel 3, punt 42). Een ernstig incident is er een dat het vermogen van het product om gevoelige gegevens of functies te beschermen aantast of kan aantasten, of dat leidt of kan leiden tot kwaadaardige code in het product of in de systemen van een gebruiker (artikel 14, lid 5). Wat erbinnen valt, wat erbuiten, en de plicht om gebruikers te informeren die bij beide hoort.

Geldt de CRA voor opensourcesoftware? Drie gevallen, en het lichte regime voor beheerders

De Cyber Resilience Act reikt tot vrije en opensourcesoftware alleen wanneer die in het kader van een commerciële activiteit wordt geleverd. Een niet te gelde gemaakt project valt erbuiten. Een bedrijf dat een op opensourcecomponenten gebouwd product levert, is fabrikant van dat product. En stichtingen en bedrijven die opensourceproducten voor commercieel gebruik in stand houden, zijn 'beheerders van opensourcesoftware' onder artikel 24: een cyberbeveiligingsbeleid, samenwerking met autoriteiten en een beperkte meldplicht, zonder CE-markering en zonder technisch dossier. De overwegingen en het artikel, geciteerd.

Is uw opensourceproject 'commercieel' onder de CRA? De zeven toetsen van de Commissie, met haar voorbeelden

De CRA raakt vrije en opensourcesoftware alleen waar zij in het kader van een commerciële activiteit wordt geleverd, en de verordening laat 'commercieel' over aan twee overwegingen. De richtsnoeren van de Commissie van 27 juli 2026, deel 3, maken daar zeven toetsen van: een prijs, een betaalde editie of open core, het te gelde maken van andere diensten of persoonsgegevens, ondersteuningsdiensten, donaties, sponsoring en de status zonder winstoogmerk, met 22 voorbeelden. Waar een maintainer, een open-corebedrijf en een stichting elk belanden, en wat een pull request van u maakt.

Wat de CRA van importeurs en distributeurs vraagt, en wanneer hij hen tot fabrikant maakt

Als u software of apparaten de EU in doorverkoopt in plaats van ze te bouwen, geven de artikelen 19 en 20 van de Cyber Resilience Act u een checklist om te doorlopen voordat het product in de verkoop gaat, een plicht om kwetsbaarheden aan de fabrikant door te geven, een plicht om autoriteiten over significante risico's te informeren, en tien jaar administratie. Artikel 21 maakt u tot fabrikant zodra u onder eigen merk verkoopt of het product substantieel wijzigt. De verplichtingen, uit de tekst.

De eigen CRA-machinerie van de EU, op de dag dat de plicht inging: 0 aangemelde instanties, 0 geharmoniseerde normen, 7 van de 27 handhavers

De Cyber Resilience Act vraagt fabrikanten klaar te zijn. Hier is hoe klaar de instellingen waarvan hij afhangt op 11 en 12 september 2026 waren, gelezen uit de eigen registers van de Commissie: geen conformiteitsbeoordelingsinstantie aangemeld onder de CRA, geen geharmoniseerde norm bekendgemaakt in het Publicatieblad, zeven lidstaten met een geregistreerde markttoezichtautoriteit, dertien met een aanmeldende autoriteit, en de lijst van coördinerende CSIRT's de dag ervoor gepubliceerd, waarbij twee staten een andere instantie dan hun nationale CSIRT noemen. Wat dat betekent voor een fabrikant met een product van klasse I, en wat vast te leggen.

De CRA-cyberbeveiligingsrisicobeoordeling: wat artikel 13 werkelijk vereist, en het ene resultaat dat zij moet opleveren

Artikel 13, leden 2 tot en met 4, van de Cyber Resilience Act maken de risicobeoordeling tot het document waaraan elke andere CRA-verplichting hangt. Zij moet risico's analyseren op basis van het beoogde doel, het voorzienbare gebruik en de gebruiksomstandigheden over de verwachte gebruiksduur; zeggen of en hoe elke eis van deel I, punt 2, van toepassing is; zeggen hoe deel I, punt 1, en deel II worden toegepast; gedocumenteerd zijn, actueel gehouden over de ondersteuningsperiode en opgenomen in het technische dossier, met een duidelijke onderbouwing voor elke weggelaten eis. De vier leden, en een structuur van één pagina die eraan voldoet.

Het beleid voor gecoördineerde openbaarmaking van kwetsbaarheden dat de CRA vereist: drie bepalingen, en een beleid van één pagina dat eraan voldoet

Bijlage I, deel II, punt 5, van de Cyber Resilience Act vereist van elke fabrikant binnen de reikwijdte dat hij een beleid voor gecoördineerde openbaarmaking van kwetsbaarheden invoert en handhaaft. Artikel 13, lid 17, vereist één contactpunt voor meldingen dat makkelijk te vinden is en niet beperkt tot geautomatiseerde middelen; bijlage II, punt 2, vereist het contactpunt en de vindplaats van het beleid in de gebruikersinformatie; bijlage VII, punt 2, onder b), zet beide in het technische dossier. Wat elke bepaling vraagt, wat een beleid moet zeggen, en wat het niet mag beloven.