Cyber Resilience Act: alle tools en artikelen
Verordening (EU) 2024/2847, bijlage I · ISO/IEC 27001:2022, bijlage A
De essentiële eisen van de CRA, gekoppeld aan ISO 27001
Een fabrikant met een gecertificeerd ISMS stelt eerst één vraag: hoeveel van de technische documentatie heb ik al? Het antwoord heeft drie delen. Voor de 14 eisen van deel I, de eigenschappen van het product, draait het ISMS het proces en levert het product het bewijs. Voor 3 van de 8 eisen aan de behandeling van kwetsbaarheden in deel II is het ISMS-record het bewijs. En voor 4 van de 22 levert niets in bijlage A op wat de verordening vraagt.
Een managementsysteem is geen product
ISO 27001 certificeert hoe een organisatie informatiebeveiliging bestuurt. De Cyber Resilience Act reguleert een product: wat het doet, hoe het wordt gebouwd en hoe zijn kwetsbaarheden gedurende de ondersteuningsperiode worden behandeld. De twee raken elkaar in de ontwikkelingsmaatregelen van bijlage A, die bepalen hoe het product wordt gebouwd, en in de maatregelen voor de behandeling van kwetsbaarheden, die bepalen wat er na de release gebeurt. Ze raken elkaar niet in de eigenschappen van het product zelf: geen ISMS-record laat zien dat een product met een veilige standaardconfiguratie wordt geleverd. De documentatie en de tests van het product laten dat zien.
Drie antwoorden, geen score
- Het ISMS-record is het bewijs
- 3
- Het record dat de beheersmaatregel oplevert, is wat de technische documentatie aanhaalt: het kwetsbaarhedenregister, het herstellogboek, de testrapporten.
- Het ISMS draait het proces, het product levert het bewijs
- 15
- De beheersmaatregel legt de eis, het principe, de codeerregel of de test vast; het bewijs dat het product eraan voldoet, is dat van het product, per versie.
- Niet uit bijlage A
- 4
- Niets in bijlage A publiceert iets, stelt een stuklijst van een product op of verbindt zich tot gratis updates. Dat wordt voor de verordening geschreven.
Deel I: de eigenschappen van het product
Punt 1 is de algemene plicht, op basis van de risicobeoordeling. Punt 2 noemt dertien eigenschappen, elk van toepassing op basis van die beoordeling, zodat een eigenschap die als niet van toepassing wordt beoordeeld met een motivering in de documentatie wordt uitgesloten. Voor alle levert het ISMS het proces: de beveiligingseisen waaraan het product moet voldoen, de principes waarop het is ontworpen, de codeerregels, de tests vóór de release. Het bewijs van elke eigenschap is dat van het product.
I.1 Passend cyberbeveiligingsniveau door ontwerp
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- Hoofdstuk 6.1.2
- A.5.8
- A.8.25
Wat de documentatie nog nodig heeft: Een cyberbeveiligingsrisicobeoordeling voor het product zelf (artikel 13, leden 2 en 3), bewaard in de technische documentatie onder bijlage VII, punt 3. Het ISMS beoordeelt de risico's van de organisatie; die van het product zijn een apart record.
In het pakket technische documentatie: Cybersecurity risk assessment
I.2.a Geen bekende exploiteerbare kwetsbaarheden bij release
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.8
- A.8.29
Wat de documentatie nog nodig heeft: De controle gebeurt per release en per geleverde component, en het resultaat blijft bij die versie. Een scan van de eigen systemen van de organisatie is een ander record.
In het pakket technische documentatie: Standards applied and test evidence
I.2.b Standaard veilige configuratie
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.9
- A.8.26
Wat de documentatie nog nodig heeft: De veilige standaardconfiguratie en het terugzetten ernaar zijn eigenschappen van het product, aangetoond door zijn documentatie en tests, niet door een configuratiebasislijn voor de systemen van de organisatie.
In het pakket technische documentatie: Standards applied and test evidence
I.2.c Beveiligingsupdates
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.8
- A.8.32
Wat de documentatie nog nodig heeft: Een updatemechanisme in het product, standaard automatisch met een mogelijkheid voor de gebruiker om af te zien, en een melding aan gebruikers wanneer een update beschikbaar is: een functie, geen proces.
In het pakket technische documentatie: Standards applied and test evidence
I.2.d Bescherming tegen ongeoorloofde toegang
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.26
- A.8.5
- A.5.15
- A.5.16
- A.5.17
In het pakket technische documentatie: Standards applied and test evidence
I.2.e Vertrouwelijkheid van gegevens
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.26
- A.8.24
In het pakket technische documentatie: Standards applied and test evidence
I.2.f Integriteit van gegevens, opdrachten en configuratie
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.26
- A.8.24
- A.8.9
In het pakket technische documentatie: Standards applied and test evidence
I.2.g Gegevensminimalisatie
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.26
- A.5.34
In het pakket technische documentatie: Standards applied and test evidence
I.2.h Beschikbaarheid van essentiële en basisfuncties
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.26
- A.8.6
- A.8.14
In het pakket technische documentatie: Standards applied and test evidence
I.2.i Geen negatieve gevolgen voor andere apparaten en netwerken
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.27
- A.8.20
In het pakket technische documentatie: Standards applied and test evidence
I.2.j Beperkt aanvalsoppervlak
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.27
- A.8.9
In het pakket technische documentatie: Standards applied and test evidence
I.2.k Beperkte gevolgen van incidenten
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.27
- A.8.28
In het pakket technische documentatie: Standards applied and test evidence
I.2.l Beveiligingslogging en monitoring
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.26
- A.8.15
- A.8.16
In het pakket technische documentatie: Standards applied and test evidence
I.2.m Veilig en eenvoudig verwijderen van gegevens en instellingen
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.26
- A.8.10
In het pakket technische documentatie: Standards applied and test evidence
Deel II: behandeling van kwetsbaarheden gedurende de ondersteuningsperiode
Acht eisen aan de fabrikant, waarvan er geen mag worden uitgesloten. Hier staat een ISMS het dichtst bij de verordening, en hier zitten de concrete hiaten: de stuklijst, de openbare bekendmaking, het beleid, het contactadres en de gratis updates.
II.1 Kwetsbaarheden en componenten identificeren en documenteren, met een SBOM
Het ISMS-record is het bewijs
Het proces, in bijlage A
- A.8.8
- A.5.9
Wat de documentatie nog nodig heeft: Een softwarestuklijst in een gangbaar, machineleesbaar formaat, die ten minste de afhankelijkheden op het hoogste niveau van het product omvat. Geen beheersmaatregel in bijlage A vraagt om een stuklijst van een product.
In het pakket technische documentatie: Software bill of materials procedure
II.2 Kwetsbaarheden onverwijld verhelpen
Het ISMS-record is het bewijs
Het proces, in bijlage A
- A.8.8
- A.8.32
Wat de documentatie nog nodig heeft: Beveiligingsupdates die, waar technisch haalbaar, gescheiden van functionele updates worden geleverd: een releasepraktijk die bijlage A niet noemt.
In het pakket technische documentatie: Security updates and support statement
II.3 Regelmatige tests en beoordelingen
Het ISMS-record is het bewijs
Het proces, in bijlage A
- A.8.29
- A.8.8
- A.5.35
In het pakket technische documentatie: Vulnerability handling process
II.4 Verholpen kwetsbaarheden bekendmaken
Niet uit bijlage A
Wat de documentatie nog nodig heeft: De openbare bekendmaking van elke verholpen kwetsbaarheid zodra de update beschikbaar is: beschrijving, betrokken producten, gevolgen, ernst en hoe gebruikers herstellen. Bijlage A heeft geen beheersmaatregel die iets publiceert.
In het pakket technische documentatie: Vulnerability handling process
II.5 Beleid voor gecoördineerde bekendmaking van kwetsbaarheden
Niet uit bijlage A
Wat de documentatie nog nodig heeft: Een beleid voor gecoördineerde bekendmaking van kwetsbaarheden, ingevoerd en gehandhaafd. Bijlage A vereist een incidentproces, geen gepubliceerd beleid voor externe melders.
In het pakket technische documentatie: Coordinated vulnerability disclosure policy
II.6 Een contactpunt voor het melden van kwetsbaarheden
Niet uit bijlage A
Wat de documentatie nog nodig heeft: Een gepubliceerd contactadres voor meldingen van kwetsbaarheden in het product en in zijn componenten van derden, en een manier om ze te ontvangen.
In het pakket technische documentatie: Coordinated vulnerability disclosure policy
II.7 Veilige en tijdige verspreiding van updates
Het ISMS draait het proces, het product levert het bewijs
Het proces, in bijlage A
- A.8.24
- A.8.32
Wat de documentatie nog nodig heeft: Het verspreidingsmechanisme is dat van het product: updates ondertekend, veilig en op tijd geleverd, automatisch waar van toepassing.
In het pakket technische documentatie: Security updates and support statement
II.8 Gratis beveiligingspatches met adviezen
Niet uit bijlage A
Wat de documentatie nog nodig heeft: Gratis beveiligingsupdates gedurende de ondersteuningsperiode, onverwijld, met een advies aan gebruikers. Een commerciële toezegging en een publicatie, die bijlage A geen van beide noemt.
In het pakket technische documentatie: Security updates and support statement
4 dingen die bijlage A niet oplevert
Uitgeschreven, zodat een gecertificeerde fabrikant weet wat hij moet schrijven, niet alleen wat hij kan aanhalen. Elk van de 4 komt terecht in een van 3 documenten van het pakket technische documentatie, en die documenten worden opgesteld uit het productrecord, niet uit het ISMS.
II.4 Verholpen kwetsbaarheden bekendmaken
De openbare bekendmaking van elke verholpen kwetsbaarheid zodra de update beschikbaar is: beschrijving, betrokken producten, gevolgen, ernst en hoe gebruikers herstellen. Bijlage A heeft geen beheersmaatregel die iets publiceert.
II.5 Beleid voor gecoördineerde bekendmaking van kwetsbaarheden
Een beleid voor gecoördineerde bekendmaking van kwetsbaarheden, ingevoerd en gehandhaafd. Bijlage A vereist een incidentproces, geen gepubliceerd beleid voor externe melders.
II.6 Een contactpunt voor het melden van kwetsbaarheden
Een gepubliceerd contactadres voor meldingen van kwetsbaarheden in het product en in zijn componenten van derden, en een manier om ze te ontvangen.
II.8 Gratis beveiligingspatches met adviezen
Gratis beveiligingsupdates gedurende de ondersteuningsperiode, onverwijld, met een advies aan gebruikers. Een commerciële toezegging en een publicatie, die bijlage A geen van beide noemt.
Wat deze pagina niet is
Geen dekkingsscore. Hier wordt geen percentage berekend en dat zou ook niet moeten. Een eis waarvan het proces in het ISMS zit en het bewijs nog niet in de documentatie, is geen gedeeltelijk gedekt punt; het is een document dat geschreven moet worden.
Geen vermoeden van conformiteit. Alleen een in het Publicatieblad aangehaalde geharmoniseerde norm geeft er een (artikel 27), en ISO 27001 is die norm niet en zal het niet worden. Waar de geharmoniseerde normen staan, en wat hun ontbreken voor elke categorie betekent
Niet de NIS2-koppeling. NIS2 reguleert de organisatie en haar maatregelen zijn geschreven vanuit ISO 27001, waardoor die koppeling dichterbij ligt. De NIS2-uitvoeringsverordening gekoppeld aan ISO 27001
Lees hierna
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.
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.
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.
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.
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.
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.
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.
De 4 hiaten zijn 3 van de 11 documenten van de documentatie
StandardOS houdt de ISMS-records bij die de 23 gekoppelde beheersmaatregelen opleveren, en het pakket technische documentatie stelt de 11 documenten van bijlage VII op uit het productrecord, waaronder het bekendmakingsbeleid, de updateverklaring en de SBOM-procedure. De koppeling op deze pagina is de verbinding tussen beide.
Bijlage I is van toepassing vanaf 11 december 2027. De beheersmaatregelen zijn de 93 van bijlage A van ISO/IEC 27001:2022, aangehaald op referentie; de koppeling is de onze en niet die van ISO of van de Commissie. Dit is geen juridisch advies, en de verordening is de tekst om te lezen: Verordening (EU) 2024/2847.