Cyber Resilience Act
Je CRA-dossier in orde, en het blijft in orde.
De Europese Cyber Resilience Act (CRA) stelt eisen aan de beveiliging van software. CheckMijn.AI meet wat je al op orde hebt, toont wat nog ontbreekt en levert de bewijsstukken voor je dossier. Bij elke release opnieuw.
11 september 2026
Meldplicht
Actief misbruikte kwetsbaarheden en ernstige incidenten moet je melden: binnen 24 uur een eerste waarschuwing, binnen 72 uur een melding. Dit geldt al.
11 december 2027
Alle eisen
Vanaf dan mag je nieuwe producten alleen op de EU-markt brengen als ze aan de eisen voldoen, met technische documentatie, een EU-conformiteitsverklaring en de CE-markering.
Voor wie?
Producten met digitale elementen
Software die je verkoopt, levert of laat installeren, en apparaten met software. Pure SaaS (alleen online) valt er grotendeels buiten; daarvoor zijn NIS2 en de AVG vaak belangrijker.
Wat CheckMijn.AI doet
- Gap-analyse: per CRA-eis zie je wat al in orde is en wat nog ontbreekt.
- Bewijs voor je technisch dossier: het keuringsrapport, de SBOM (lijst van componenten) en het bewijs per check.
- Geen bekende lekken: je componenten worden vergeleken met de nieuwste lijst van lekken, elke dag.
- Doorlopend: de CRA vraagt dat je de eisen blijft halen. Met de versiecheck meet je bij elke release opnieuw.
- Voorbereid op de meldplicht: we kijken of je meldbeleid en je meldproces klaar zijn.
Wat het niet is
- Geen CE-markering of conformiteitsverklaring. Die verklaar en teken je als fabrikant zelf. Wij leveren de onderbouwing.
- Geen aangemelde instantie (notified body). Voor "important"-producten van klasse II en "critical"-producten is een beoordeling door zo'n instantie nodig.
- Geen vermoeden van conformiteit. Dat geeft alleen een geharmoniseerde norm; in oktober 2026 was er nog geen enkele gepubliceerd.
- Geen juridisch advies. Laat je verplichtingen nakijken door een jurist.
Wat je per niveau afdekt
51 van onze 292 checks verwijzen naar een eis uit de CRA. Elk niveau bevat alles van het niveau ervoor.
Niveau 1 · gratis
11 checks, automatisch
Geen bekende lekken, SBOM, bewaking van nieuwe lekken, geen geheimen in de code, versleuteld verkeer, limieten tegen misbruik, je live site.
Niveau 2 · keuring
+12 checks
Veilige standaardinstellingen, inloggen en MFA, logging, versleutelde opslag, een publiek meldbeleid voor kwetsbaarheden, veilige updates en releases.
Niveau 3 · keuring plus
+28 checks
De documentatie en processen van je dossier: risicobeoordeling, ondersteuningsperiode, aanspreekpunt, gebruikersinformatie, meldproces, pentest met hertest.
Welke check welke eis afdekt
"I" is bijlage I van de CRA (de essentiële eisen; deel II gaat over het omgaan met kwetsbaarheden), "art." een artikel. Klik op een check voor de uitleg.
| Check | Wat we controleren | CRA | Vanaf | Hoe |
|---|---|---|---|---|
| A-03 | SBOM in machineleesbaar formaat (SPDX of CycloneDX), automatisch bij de build gemaakt, minstens alle directe afhankelijkheden | bijlage I deel II (1) | niveau 1 | automatisch |
| C-19 | Geen ongebruikte afhankelijkheden: elk pakket in het manifest wordt echt gebruikt (ongebruikte pakketten zijn onnodig aanvalsoppervlak) | bijlage I (2)(j) | niveau 1 | automatisch |
| D-12 | Extern aanvalsoppervlak gescand: alle domeinen, subdomeinen, open poorten en publiek bereikbare diensten van de app in kaart gebracht en getest op bekende zwakheden (externe kwetsbaarheidsscan; geen pentest) | I (2)(j) | niveau 1 | automatisch |
| E-05 | Geen geheimen in code, configuratie of git-geschiedenis; geheimen staan in een kluis of de omgeving | I (2)(e) | niveau 1 | automatisch |
| E-06 | Versleuteling: TLS 1.2 of hoger voor al het verkeer, gevoelige gegevens versleuteld opgeslagen, geen verouderde of zelfgemaakte algoritmen | I (2)(e) | niveau 1 | automatisch |
| F-01 | Geen afhankelijkheden met bekende uitbuitbare kwetsbaarheden (bv. CISA KEV, EU-kwetsbaarhedendatabank) en geen kritieke CVE zonder mitigatie | I deel I (2)(a) | niveau 1 | automatisch |
| F-13 | Indirecte (transitieve) afhankelijkheden worden mee gescand; bij niveau 2 staan ze ook in de SBOM | I deel II (1) | niveau 1 | automatisch |
| G-08 | Doorlopende bewaking van nieuwe kwetsbaarheden in afhankelijkheden via de SBOM | I deel II (1), (3) | niveau 1 | automatisch |
| O-05 | De site zelf is veilig: TLS, beveiligingsheaders, CMS en plugins op een ondersteunde versie, geen beheerpagina's open | I (2)(a) | niveau 1 | automatisch |
| W-06 | Limieten op middelen: time-outs, maximale grootte van verzoeken en uploads, paginering, bescherming tegen trage queries | I (2)(h) | niveau 1 | automatisch |
| Y-02 | Geen onversleutelde protocollen voor gegevens of beheer: geen HTTP behalve doorverwijzing, geen FTP, Telnet, LDAP of MQTT zonder TLS, geen SNMP v1/v2 | I (2)(e) | niveau 1 | automatisch |
| E-01 | Inloggen: geen standaardwachtwoorden; MFA verplicht voor beheerders en beschikbaar voor gebruikers | I (2)(d) | niveau 2 | keurder |
| E-07 | Veilig standaard: debug uit, beheerschermen afgeschermd, terugzetten naar een veilige toestand mogelijk | I (2)(b) | niveau 2 | keurder |
| E-10 | Klein aanvalsoppervlak: geen overbodige poorten, endpoints of functies; geen endpoints buiten de API-specificatie | I (2)(j) | niveau 2 | keurder |
| E-13 | Beveiligingsgebeurtenissen gelogd (inloggen, rechtenwijzigingen, fouten), zonder gevoelige gegevens in de logs, met alarm bij afwijkingen | I (2)(l) | niveau 2 | keurder |
| E-15 | Netwerk: databanken, caches en beheerinterfaces niet publiek bereikbaar; beheer alleen via VPN, bastion of zero-trusttoegang; omgevingen gescheiden | I (2)(j) | niveau 2 | keurder |
| F-12 | Ook de infrastructuur: besturingssysteem, runtime (bv. Java, .NET, Node.js, PHP, Python), webserver, database en CMS op een ondersteunde versie met actuele patches | I (2)(a) | niveau 2 | keurder |
| G-01 | Publiek beleid voor gecoördineerde melding van kwetsbaarheden, met meldadres (bv. security.txt) | I deel II (5), (6) | niveau 2 | keurder |
| G-05 | Updates veilig verspreid (ondertekend, vertrouwd kanaal); bij geïnstalleerde software staan automatische updates standaard aan | I deel I (2)(c) | niveau 2 | keurder |
| R-07 | Elke release getagd, met versienummer (bv. semantisch), releasenotes en een reproduceerbaar artefact | I deel II (4) | niveau 2 | keurder |
| W-02 | Verbindingen met databank en opslag versleuteld; gevoelige velden extra versleuteld waar het risico dat vraagt | I (2)(e) | niveau 2 | keurder |
| W-10 | Databank versleuteld in rust, ook back-ups, replica's en snapshots; sleutels apart beheerd | I (2)(e) | niveau 2 | keurder |
| X-01 | Hostingoverzicht: welke aanbieders en diensten, welke regio's en datacenters, wie beheert wat (gedeelde verantwoordelijkheid) | bijlage VII | niveau 2 | keurder |
| A-01 | Product, versielijn, scope en wat buiten scope valt zijn beschreven; de gekeurde versie is herkenbaar (versienummer in build en app) | bijlage II | niveau 3 | keurder |
| A-02 | Architectuuroverzicht: componenten, datastromen, externe koppelingen, hosting en regio | bijlage VII | niveau 3 | keurder |
| A-06 | Ondersteuningsperiode vastgelegd en publiek: tot wanneer komen er security-updates | art. 13(8), bijlage II | niveau 3 | keurder |
| A-07 | Benoemd aanspreekpunt voor de beveiliging van het product | bijlage II | niveau 3 | keurder |
| D-10 | Handmatige pentest in de laatste 12 maanden door een onafhankelijke, gekwalificeerde tester (bv. CREST of OSCP): web, API's, inloggen, rechten en bedrijfslogica; mobiele apps apart | bijlage I deel II (3) | niveau 3 | keurder |
| D-13 | Hertest na de pentest bevestigt dat kritieke en hoge bevindingen echt opgelost zijn | I deel II (3) | niveau 3 | keurder |
| E-09 | Bescherming tegen misbruik: limieten op inlogpogingen en zware functies; uploads gecontroleerd | I (2)(h) | niveau 3 | keurder |
| E-11 | Integriteit: artefacten en updates ondertekend; geen onveilige deserialisatie | I (2)(f) | niveau 3 | keurder |
| E-14 | Sleutelbeheer: sleutels voor ondertekening, versleuteling en TLS in een sleutelkluis, KMS of HSM, met een vaste levenscyclus (aanmaken, roteren, intrekken, vernietigen); toegang beperkt en gelogd | I (2)(e), (f) | niveau 3 | keurder |
| F-11 | Patchsnelheid: beschikbare security-patches voor kritieke lekken binnen 14 dagen toegepast, voor hoge binnen 30 dagen (voorstel; gemeten over het laatste jaar) | I deel II (2) | niveau 3 | keurder |
| G-02 | Intern proces voor kwetsbaarheden: triage, ernst bepalen, hersteltermijn per ernst | I deel II (2) | niveau 3 | keurder |
| G-04 | Security-updates gratis en waar mogelijk los van functionele updates, met advies aan gebruikers | I deel II (2), (8) | niveau 3 | keurder |
| G-06 | Opgeloste kwetsbaarheden publiek vermeld in releasenotes of advisories | I deel II (4) | niveau 3 | keurder |
| G-07 | Meldproces klaar om actief uitgebuite kwetsbaarheden en ernstige incidenten binnen 24 uur te melden | art. 14 | niveau 3 | keurder |
| I-01 | Overzicht van de gegevens: welke persoonsgegevens, waar opgeslagen, hoe lang en waarvoor | I (2)(g) | niveau 3 | keurder |
| I-02 | Niet meer gegevens dan nodig; privacyvriendelijke standaardinstellingen | I (2)(g) | niveau 3 | keurder |
| I-04 | Gebruikers kunnen hun gegevens exporteren en definitief laten verwijderen | I (2)(m) | niveau 3 | keurder |
| J-01 | Gebruikersinformatie: doel, beoogd gebruik, veilige installatie en configuratie, einddatum van de ondersteuning, contact | bijlage II | niveau 3 | keurder |
| J-03 | Technische documentatie: architectuur, vastgelegde ontwerpkeuzes, datamodel, API-specificatie (bv. OpenAPI) | bijlage VII | niveau 3 | keurder |
| J-06 | Wijzigingslog per release, met de security-fixes apart vermeld | I deel II (4) | niveau 3 | keurder |
| J-07 | Beveiligingsinformatie voor klanten: hoe het product veilig te gebruiken en wat de klant zelf moet doen | bijlage II | niveau 3 | keurder |
| K-09 | Logbeleid: wat wordt gelogd (toegang, beheeracties, fouten, wijzigingen aan gegevens), hoe lang bewaard, wie erbij kan; logs beschermd tegen wijziging | I (2)(l) | niveau 3 | keurder |
| Q-02 | Risicobeoordeling van het product, herzien minstens jaarlijks en bij grote wijzigingen | art. 13(2) | niveau 3 | keurder |
| Q-04 | Releasebeleid: versienummering, releasenotes, welke versies ondersteund worden, einde van ondersteuning tijdig aangekondigd | art. 13(8) | niveau 3 | keurder |
| R-12 | Overzicht van welke versies bij klanten draaien en welke nog updates krijgen; security-fixes ook naar ondersteunde oudere versies | art. 13(8) | niveau 3 | keurder |
| X-08 | Budgetalarmen en limieten, zodat een aanval of fout geen onbeperkte kosten of uitval veroorzaakt | I (2)(h) | niveau 3 | keurder |
| Z-04 | Supportafspraken: reactie- en oplostijden per prioriteit, onderhoudsvensters, ondersteunde versies en kanalen | art. 13 | niveau 3 | keurder |
| Z-23 | Einde levensduur: uitfaseerplan met tijdige aankondiging, teruggave van de gegevens en aantoonbaar veilig wissen | art. 13 | niveau 3 | keurder |
De checks van niveau 3 en 4 zijn een concept (norm 0.2) en worden definitief na de pilots. Zodra er geharmoniseerde CRA-normen zijn, leggen we onze checks daarnaast.
Begin met een gratis scan
Niveau 1 toont in tien minuten waar je staat voor de technische CRA-eisen. Voor je volledige dossier is er de keuring.