Cyber Resilience Act (CRA): Volledig nalevingsoverzicht voor 2026
Alles wat fabrikanten moeten weten over de EU Cyber Resilience Act — verplichte cybersecurityvereisten, SBOM-plicht, september 2026-deadline, CE-markering en implementatieroadmap voor producten met digitale elementen.
Cyber Resilience Act (CRA): Volledig nalevingsoverzicht voor 2026
De Cyber Resilience Act (Verordening 2024/2847) is 's werelds eerste horizontale verordening die verplichte cybersecurityvereisten stelt voor producten met digitale elementen. Ze vereist security by design, beveiligingsupdates gedurende de levenscyclus en transparant kwetsbaarheidsbeheer voor hardware- en softwareproducten op de EU-markt.
De kritieke deadline nadert snel: vanaf 11 september 2026 gelden kwetsbaarheidsrapportageverplichtingen — ook voor producten die al op de markt zijn.
Als u verbonden producten of software in Europa fabriceert, importeert of distribueert, heeft de CRA direct gevolgen voor u. Dit overzicht behandelt het volledige toepassingsgebied, de vereisten, de actiepunten voor september 2026, en wat de Commissierichtsnoeren van maart 2026 betekenen voor uw nalevingsprogramma.
Wat is de Cyber Resilience Act?
De CRA stelt horizontale cybersecurityvereisten vast voor producten met digitale elementen gedurende hun gehele levenscyclus — van ontwerp en ontwikkeling via marktplaatsing tot het einde van de levensduur. Ze adresseert een fundamentele marktfaling: de overgrote meerderheid van verbonden producten had geen enkel wettelijk cybersecurityvereiste.
Kernprincipes:
- Security by design: Cybersecurity moet vanaf het begin in het product zijn ingebouwd — niet achteraf toegevoegd
- Security by default: Producten moeten worden geleverd met veilige standaardconfiguraties
- Levenscyclusverantwoordelijkheid: Fabrikanten moeten beveiligingsupdates leveren gedurende de verwachte productlevensduur (minimaal 5 jaar)
- Transparantie: Kwetsbaarheden moeten worden gemeld en afgehandeld via gecoördineerde processen
- Markttoegang: Niet-conforme producten mogen de CE-markering niet dragen en mogen niet op de EU-markt worden geplaatst
De CRA werd gepubliceerd in het Publicatieblad op 20 november 2024 en trad in werking op 10 december 2024.
Wie moet voldoen?
De CRA is van toepassing op drie categorieën marktdeelnemers:
Fabrikanten
Elke entiteit die producten met digitale elementen ontwerpt, ontwikkelt of produceert — of laat ontwerpen, ontwikkelen of produceren — en ze onder eigen naam of merk op de markt brengt. Als u software verkoopt onder uw eigen merk (ook al is het gebaseerd op open sourcecomponenten), bent u de fabrikant voor CRA-doeleinden.
Importeurs
Elke in de EU gevestigde entiteit die een product van een fabrikant buiten de EU op de markt plaatst.
Distributeurs
Elke entiteit in de toeleveringsketen (anders dan fabrikant of importeur) die een product op de markt beschikbaar maakt.
Wat telt als een "product met digitale elementen"?
De CRA dekt:
- Hardwareproducten met netwerkconnectiviteit: IoT-apparaten, routers, smart home-apparaten, industriële controllers, automotive-componenten
- Zelfstandige software: Applicaties, besturingssystemen, firmware, middleware, bibliotheken
- Gegevensverwerking op afstand: Cloudcomponenten die essentieel zijn voor de kernfunctie van een product (geen zelfstandige SaaS-diensten)
De Commissierichtsnoeren van maart 2026 verduidelijken dat software als "op de markt gebracht" wordt beschouwd wanneer ze voor het eerst beschikbaar wordt gesteld op de EU-markt — ook via downloadaanbod of toegang op afstand.
Uitzonderingen
- Opensourcesoftware ontwikkeld in een niet-commerciële context (zie Open Source-sectie)
- Producten die al onder sectorspecifieke EU-wetgeving vallen (medische hulpmiddelen onder MDR, automotive onder typegoedkeuringsregelgeving, luchtvaart onder EASA)
- Producten die exclusief zijn ontwikkeld voor nationale veiligheids- of defensiedoeleinden
Productcategorieën en conformiteitsbeoordeling
De CRA categoriseert producten op basis van hun kritiekheid:
Standaardcategorie (meerderheid van producten)
- Conformiteitsbeoordeling: Zelfbeoordeling door de fabrikant
- Voorbeelden: De meeste consumenten-IoT, algemene software
- Procedure: Interne controle (Module A) op basis van Bijlage VIII
Belangrijke producten — Klasse I (Bijlage III)
- Identiteitsbeheer- en authenticatiesoftware
- VPN's, netwerkbeheersystemen
- SIEM-systemen
- Bootmanagers, BIOS-firmware
- Firewalls, IDS/IPS voor niet-industrieel gebruik
- Routers en modems voor internetconnectiviteit
- Microprocessors en microcontrollers met beveiligingsfuncties
- Beoordeling: Zelfbeoordeling met geharmoniseerde normen OF beoordeling door derden
Belangrijke producten — Klasse II (Bijlage III, hoger risico)
- Hypervisors, container-runtimesystemen
- Firewalls en IDS/IPS voor industrieel gebruik
- Manipulatiebestendige microprocessors/microcontrollers
- Beoordeling: Conformiteitsbeoordeling door derden verplicht
Kritieke producten (Bijlage IV)
- Hardwareapparaten met beveiligingsboxen (HSM's, smartcards, beveiligde elementen)
- Slimme metergateways binnen slimme metersystemen
- Beoordeling: Europese cybersecuritycertificering vereist
Status geharmoniseerde normen: ETSI, CEN en CENELEC ontwikkelen op basis van het Commissiemandaat EU-brede geharmoniseerde normen — inclusief verticale normen voor browsers, wachtwoordbeheerders, antivirussoftware, VPN's, SIEM en bootmanagers. De meeste geharmoniseerde normen worden verwacht eind 2026. In Nederland publiceert het NCSC-NL (Nationaal Cyber Security Centrum) regelmatig richtsnoeren over CRA-gereedheid die aansluiten op de nationale cybersecuritystrategie.
Essentiële cybersecurityvereisten (Bijlage I)
Deel I: Productvereisten
- Producten moeten worden ontworpen, ontwikkeld en geproduceerd om een passend niveau van cybersecurity te waarborgen
- Producten moeten worden geleverd zonder bekende exploiteerbare kwetsbaarheden
- Veilige standaardconfiguratie, met de mogelijkheid tot fabrieksreset
- Bescherming tegen ongeautoriseerde toegang door passende controlemechanismen
- Bescherming van vertrouwelijkheid van opgeslagen, verzonden of verwerkte gegevens (versleuteling waar passend)
- Bescherming van gegevensintegriteit
- Verwerking van uitsluitend noodzakelijke gegevens (dataminimalisatie)
- Beschikbaarheidsbescherming, inclusief weerbaarheid tegen denial-of-service-aanvallen
- Minimalisatie van negatieve impact op andere apparaten/netwerken
- Ontwerp met minimaal aanvalsoppervlak
- Beperking van impact door exploitatiemitigatietechnieken
- Registratie en monitoring van beveiligingsrelevante informatie (logging)
- Veilige softwareupdatemechanismen, met gebruikersnotificatie
Deel II: Vereisten voor kwetsbaarheidsbeheer
- Identificeer en documenteer kwetsbaarheden en componenten (inclusief SBOM)
- Verhelp kwetsbaarheden zonder vertraging door beveiligingsupdates
- Pas effectieve en regelmatige tests en reviews toe
- Openbare bekendmaking van opgeloste kwetsbaarheden, inclusief CVE-identificatoren
- Beleid voor gecoördineerde bekendmaking van kwetsbaarheden (CVD)
- Mechanismen voor veilige distributie van beveiligingsupdates
- Gratis beveiligingsupdates gedurende de verwachte productlevensduur (minimaal 5 jaar)
De september 2026-deadline: Wat u nu moet doen
De meest urgente CRA-verplichting is Artikel 14 — die van toepassing wordt op 11 september 2026. Dit is geen voorbereidingsmijlpaal; het is een harde handhavingsdatum. Vanaf die datum is het nalaten van melden een CRA-overtreding.
Belangrijk: bestaande producten zijn inbegrepen
Een cruciaal punt dat veel fabrikanten over het hoofd zien: de rapportageverplichtingen van Artikel 14 gelden voor alle producten met digitale elementen op de EU-markt, inclusief producten die vóór de definitieve deadline van december 2027 op de markt zijn gebracht. Als uw IoT-apparaat, router of software momenteel wordt verkocht en in september 2026 een kwetsbaarheid wordt ontdekt, moet u die melden.
Wat gemeld moet worden
Fabrikanten moeten rapporteren aan ENISA (via het Centraal Rapportageplatform) en hun aangewezen nationale CSIRT:
Actief misbruikte kwetsbaarheden:
- Binnen 24 uur na kennisneming: Vroegtijdige waarschuwing
- Binnen 72 uur: Volledige kwetsbaarheidsmelding met beschikbare corrigerende maatregelen
- Binnen 14 dagen na beschikbaarheid van een corrigerende maatregel: Eindrapport met beschrijving, ernst, impact en herstelmaatregelen
Ernstige incidenten die de beveiliging van het product beïnvloeden:
- Dezelfde 24/72-uur vroegtijdige waarschuwingsstructuur
- Binnen 1 maand: Eindrapport incident
Het Centraal Rapportageplatform (SRP)
ENISA richt het Centraal Rapportageplatform (SRP) in, dat operationeel zal zijn op 11 september 2026. Fabrikanten rapporteren eenmalig via de SRP — meldingen worden gericht aan het CSIRT bij de hoofdvestiging van de fabrikant, met gelijktijdige beschikbaarstelling aan ENISA en relevante EU-CSIRT's. In Nederland is het NCSC-NL aangewezen als nationaal CSIRT; meldingen verlopen via de nationale contactpunten.
Actielijst voor september 2026
- Productinventarisatie: Alle producten met digitale elementen op de EU-markt identificeren
- SBOM opstellen of bijwerken: Elk product heeft een complete softwarenomenclatuur nodig
- CSIRT-contact vastleggen: Het bevoegde nationale CSIRT identificeren (in Nederland: NCSC-NL)
- Registreren bij de SRP: Toegang instellen tot het ENISA Centraal Rapportageplatform
- CVD-beleid publiceren: Beleid voor gecoördineerde bekendmaking van kwetsbaarheden publiceren
- 24/72-uurproces documenteren: Intern escalatieproces voor vroegtijdige waarschuwing documenteren en oefenen
- CVE-monitoring instellen: CVE-databases en beveiligingsadviezen monitoren voor uw productafhankelijkheden
Software Bill of Materials (SBOM): de basis van CRA-naleving
Een van de operationeel meest significante CRA-vereisten is de verplichting voor een Software Bill of Materials (SBOM) — een complete, machineleesbare inventaris van alle softwarecomponenten in een product: bibliotheken, frameworks, open sourcepakketten en hun versies.
Waarom SBOM's cruciaal zijn voor CRA-naleving:
- Kwetsbaarheidsdetectie: Bij de ontdekking van een kritieke kwetsbaarheid in een afhankelijkheid (bijv. een Log4Shell-type event) kunt u met uw SBOM direct identificeren welke producten getroffen zijn
- 24-uurrapportageverplichting: Zonder accurate SBOM is het naleven van de 24-uur vroegtijdige waarschuwingsdeadline operationeel onmogelijk voor producten met complexe afhankelijkheidsbomen
- Conformiteitsbewijs: Markttoezichtautoriteiten (in Nederland: de Rijksinspectie Digitale Infrastructuur en mogelijk het NCSC-NL) kunnen uw SBOM opvragen bij conformiteitsbeoordeling
Minimale SBOM-inhoud per CRA:
- Naam en versie van elk component
- Leverancier/auteur van het component
- Unieke identificator (bijv. Package URL/PURL)
- Afhankelijkheidsrelaties
- Licentie-informatie
Standaardformaten: SPDX (ISO/IEC 5962) en CycloneDX — CycloneDX wordt steeds vaker geprefereerd voor beveiligingstoepassingen vanwege de geïntegreerde kwetsbaarheidstracking.
Secure Development Lifecycle (SDL) voor CRA-naleving
De CRA schrijft geen specifiek SDL-raamwerk voor, maar de essentiële vereisten van Bijlage I beschrijven wat een CRA-conform ontwikkelproces moet opleveren. Beveiliging in elke fase integreren is de enige schaalbare aanpak:
Vereistenfase
- Beveiligingsvereisten vastleggen in productspecificaties vanaf dag één
- Dreigingsmodellering uitvoeren als onderdeel van productplanning
- Verwachte productlevensduur declareren (minimaal 5 jaar voor de supportperiode)
Ontwikkelingsfase
- Veilige codeerstandaarden en systematische codereviews toepassen
- Dependency management-tools gebruiken voor het bijhouden en bijwerken van derde-partijbibliotheken
- Geautomatiseerd statisch applicatiebeveiligingstesten (SAST) implementeren
Testfase
- Penetratietests uitvoeren vóór elke hoofdversie
- Dynamisch applicatiebeveiligingstesten (DAST) toepassen
- Kwetsbaarheidsscanning uitvoeren op alle componenten
Publicatiefase
- SBOM genereren en publiceren voor elke versie
- Veilige standaardconfiguratie verifiëren vóór levering
- Beveiligingsinstellingen documenteren voor gebruikers
Operationele fase
- CVE-databases en beveiligingsadviezen monitoren voor uw afhankelijkheidsgraph
- Patchbeheerproces beheren met gedefinieerde responstijdlijnen
- Formeel Gecoördineerd Kwetsbaarheidsbekendmakingsprogramma (CVD) beheren
Open source en de CRA
De CRA-bepalingen voor open source zijn genuanceerd. De niet-commerciële open source-uitzondering dekt individuele bijdragen en projecten ontwikkeld buiten een commerciële context. Twee scenario's brengen open source-actoren echter wel in het toepassingsgebied:
Open source-stewards
Een rechtspersoon (doorgaans een stichting) die duurzame ondersteuning biedt voor de ontwikkeling van open sourcesoftware bestemd voor commerciële activiteiten, is als open source-steward onderworpen aan de CRA. Dit verlichte regime vereist:
- Het bijhouden van een cybersecuritybeleid voor veilige ontwikkeling en kwetsbaarheidsbeheer
- Samenwerking met markttoezichtautoriteiten
- Het melden van actief misbruikte kwetsbaarheden en ernstige incidenten vanaf september 2026
- Belangrijk: open source-stewards zijn niet onderworpen aan bestuurlijke boetes onder de CRA
Commerciële producten met open sourcecomponenten
Als u een commercieel product distribueert dat open sourcecomponenten bevat, bent u voor CRA-doeleinden de fabrikant — verantwoordelijk voor het volledige product inclusief de open sourceafhankelijkheden. De Commissierichtsnoeren van maart 2026 verduidelijken dat fabrikanten niet verplicht zijn te garanderen dat een voorgestelde oplossing wordt geaccepteerd door het upstream-project (lokale patches zijn toegestaan), maar ze moeten kwetsbaarheden in alle componenten wel bijhouden en melden.
Commissierichtsnoeren maart 2026: Kernverduidelijkingen
De Europese Commissie publiceerde haar ontwerprichtsnoerondocument (Ares(2026)2319816) op 3 maart 2026 — ongeveer 70 pagina's praktische verduidelijkingen open voor feedback van stakeholders tot 31 maart 2026.
Relevante verduidelijkingen voor fabrikanten:
- "Op de markt brengen" omvat het aanbieden van software voor download of toegang op afstand — niet alleen fysieke distributie
- Componenten voor gegevensverwerking op afstand die essentieel zijn voor de kernfunctie van een product vallen binnen het toepassingsgebied
- Definitie van de supportperiode en de wisselwerking met de minimale updateverplichting van 5 jaar
- Upstream-rapportage: Fabrikanten zijn niet verplicht te garanderen dat hun oplossing wordt geaccepteerd door het open sourceproject
- Wisselwerking met andere EU-wetgeving: Hoe CRA-verplichtingen zich verhouden tot de AVG, NIS2 en de AI-verordening
Het definitieve richtsnoerondocument wordt verwacht na sluiting van de consultatie en biedt de gezaghebbende interpretatie vóór de september 2026-deadline.
CRA-tijdlijn
| Datum | Mijlpaal |
|---|---|
| 20 nov 2024 | Gepubliceerd in het Publicatieblad |
| 10 dec 2024 | In werking getreden |
| 3 mrt 2026 | Commissie publiceert ontwerprichtsnoeren (feedback tot 31 maart 2026) |
| 11 jun 2026 | Bepalingen voor conformiteitsbeoordelingsinstanties van toepassing; lidstaten moeten aanmeldende autoriteiten hebben aangewezen |
| 11 sep 2026 | Kwetsbaarheidsrapportageverplichtingen (Artikel 14) — ook voor producten die al op de markt zijn |
| 11 dec 2027 | Volledige toepassing — CE-markering, conformiteitsbeoordeling, technische documentatie |
Sancties
| Overtreding | Maximale boete |
|---|---|
| Niet-naleving van essentiële cybersecurityvereisten (Bijlage I) | €15 miljoen of 2,5% van de wereldwijde jaaromzet |
| Niet-naleving van overige CRA-verplichtingen | €10 miljoen of 2% van de wereldwijde omzet |
| Verstrekken van misleidende informatie aan autoriteiten | €5 miljoen of 1% van de wereldwijde omzet |
Markttoezichtautoriteiten kunnen ook:
- Producten van de markt laten halen
- Corrigerende maatregelen eisen
- Marktbeschikbaarheid verbieden of beperken
- Productterugroepingen gelasten
In Nederland is de Rijksinspectie Digitale Infrastructuur (RDI) aangewezen als markttoezichthouder voor producten met digitale elementen. Het NCSC-NL speelt een belangrijke ondersteunende rol bij kwetsbaarheidscoördinatie en publiceert regelmatig advisories die relevant zijn voor CRA-nalevingsprogramma's. De Autoriteit Persoonsgegevens (AP) blijft verantwoordelijk voor gegevensbeschermingsaspecten die overlappen met AVG-verplichtingen.
Volledige nalevingsroadmap naar december 2027
Naast de rapporteringsdeadline van september 2026 hebben fabrikanten een breder programma nodig om volledige CRA-naleving te bereiken voor december 2027:
Stap 1: Toepassingsgebied vaststellen
Bepaal welke producten onder de CRA vallen en in welke categorie (standaard, Klasse I belangrijk, Klasse II belangrijk of kritiek). Identificeer de passende conformiteitsbeoordelingsprocedure.
Stap 2: Kloofanalyse ten opzichte van Bijlage I
Breng uw huidige productbeveiligingspraktijken in kaart tegenover alle 20 essentiële vereisten. Veelvoorkomende hiaten bij CRA-gereedheidsbeoordelingen:
- Geen formeel SBOM-beheerproces
- Kwetsbaarheidsafhandelingstijdlijnen niet afgestemd op CRA-vereisten (24/72 uur/14 dagen)
- Geen veilig updatemechanisme voor uitgerolde producten
- Geen gepubliceerd CVD-beleid
- Beveiligingstests ad-hoc in plaats van systematisch
Stap 3: Security by Design-integratie
Integreer cybersecurityvereisten in uw productontwikkelingslevenscyclus in alle fasen (zie SDL-sectie). Dit is een culturele en procesmatige verandering, niet alleen een technische.
Stap 4: Kwetsbaarheidsbeheerplatform
- Beleid voor gecoördineerde kwetsbaarheidsbekendmaking publiceren op uw website
- SBOM genereren en bijhouden voor elke productrelease
- CVE-monitoring voor uw afhankelijkheidsgraph
- 24/72-uur/14-dagenworkflow documenteren en oefenen
Stap 5: Technische documentatie
Stel het volledige technische dossier op voor CRA-conformiteit:
- Product- en ontschrijving
- Beveiligingsvereisten en hun implementatie
- Risicoanalyse
- Testresultaten
- SBOM
- EU-conformiteitsverklaring
Stap 6: Conformiteitsbeoordeling en CE-markering
Voer de passende conformiteitsbeoordelingsprocedure uit voor uw productcategorie en breng de CE-markering aan.
Stap 7: Continue levenscyclusnaleving
De CRA creëert doorlopende verplichtingen — geen eenmalige exercitie:
- SBOM bijwerken bij elke release
- Afhankelijkheden monitoren en patchen gedurende de volledige gedeclareerde supportperiode
- Technische documentatie actueel houden
- Rapportageverplichtingen van Artikel 14 continu naleven
Veelgestelde vragen over CRA-implementatie
Is de CRA van toepassing op SaaS-producten?
Zuivere SaaS-diensten die niet als component in een product zijn geïntegreerd, vallen over het algemeen niet onder de CRA — andere regelgeving zoals NIS2 is van toepassing. Maar cloudservices die essentieel zijn voor de kernfunctie van een fysiek product (bijv. een cloudbackend voor een IoT-apparaat) worden beschouwd als onderdeel van het product en moeten voldoen aan de CRA-vereisten voor dat deel.
Vuistregel: Als uw software als een zelfstandig product wordt verkocht of een essentieel onderdeel is van een verbonden product, is de CRA van toepassing. Als het puur als een dienst zonder productintegratie werkt, waarschijnlijk niet.
Hoe lang moeten beveiligingsupdates worden verstrekt?
De CRA vereist beveiligingsupdates gedurende de verwachte productlevensduur, maar minimaal 5 jaar na de laatste marktplaatsing van het product. Fabrikanten moeten:
- Een officiële supportperiode definiëren voor elk product
- Die duidelijk communiceren aan klanten
- Middelen plannen voor patchbeheer gedurende de gehele levensduur
Wat als er een kwetsbaarheid wordt ontdekt in een open sourceafhankelijkheid?
Als fabrikant bent u verantwoordelijk — niet de open sourceauteur. U moet:
- De getroffen producten identificeren via uw SBOM
- Een actief misbruikte kwetsbaarheid binnen 24 uur melden aan ENISA
- Binnen 72 uur een update of tijdelijke oplossing leveren
- Gebruikers informeren
CRA en andere EU-regelgeving
| Regelgeving | Relatie tot CRA |
|---|---|
| NIS2 | CRA behandelt productbeveiliging; NIS2 behandelt organisatiebeveiliging. CRA-conforme producten helpen NIS2-gereguleerde exploitanten te voldoen aan hun toeleveringsketenverplichtingen. |
| AVG | De gegevensbeschermingsvereisten van de CRA (minimalisatie, versleuteling, toegangscontrole) vullen de AVG aan op productniveau. De Autoriteit Persoonsgegevens blijft toezichthouder voor de AVG-dimensie. |
| DORA | Financiële entiteiten die onder DORA vallen, moeten veilige ICT-producten gebruiken — CRA-conforme producten verminderen DORA ICT-risicoblootstelling. |
| AI-verordening | AI-systemen met een hoog risico die producten met digitale elementen zijn, moeten voldoen aan zowel de CRA als de AI-verordening. |
| MDR/IVDR | Medische hulpmiddelen zijn vrijgesteld van de CRA (vallen onder eigen regelgeving). |
| Richtlijn radioapparatuur (RED) | De CRA zal uiteindelijk de cybersecurity-gedelegeerde handelingen van de RED voor betreffende producten vervangen. |
Hoe Orbiq CRA-naleving ondersteunt
CRA-naleving genereert aanzienlijke documentatie- en bewijsvereisten gedurende de gehele productlevenscyclus. Orbiq helpt fabrikanten dit continu te beheren:
- Toeleveringsketendocumentatie: Componenten en afhankelijkheden bijhouden over uw productportfolio — de basis van SBOM-beheer
- Nalevingsbewijs: Beveiligingstestresultaten, kwetsbaarheidsbeoordelingen en conformiteitsdocumentatie centraliseren
- Trust Center: Uw productbeveiligingspositie, CVD-beleid en nalevingsstatus delen met klanten en markttoezichtautoriteiten
- Leveranciersbeheer: De beveiligingsstatus van componenten en derde-partijafhankelijkheden monitoren
- Continue monitoring: CRA-verplichtingen naleven met geautomatiseerde nalevingscontrole over uw volledige productportfolio
Als u nog platforms vergelijkt, legt onze gids voor compliance-automatiseringssoftware uit welke aanbieders het sterkst zijn op continue bewijsverzameling, EU-dataopslag en operationele compliance-workflows.
Verder lezen
- Cyber Resilience Act: Artikelen 13 en 14 in detail
- EU AI-verordening: Complete nalevingsgids 2026 — AI-vereisten die overlappen met de CRA voor AI-gestuurde producten
- NIS2-compliancegids — Organisatorische beveiligingsvereisten
- DORA-compliancegids — Vereisten voor de financiële sector
- De NIS2-richtlijn: Volledig overzicht — Wetgevingskader en nationale implementatie
Bronnen en referenties
- CRA — Officiële tekst (Verordening 2024/2847) — Publicatieblad van de EU, 20 november 2024
- Ontwerprichtsnoeren Commissie CRA — Ares(2026)2319816 — Europese Commissie, 3 maart 2026
- CRA-rapportageverplichtingen — Officiële pagina — Artikel 14 en Centraal Rapportageplatform
- CRA-implementatie — EC-factsheet — Mijlpalen en tijdlijn
- EU CRA: Key 2026 Milestones — Hogan Lovells
- CRA gefaseerde toepassingsstartdata — Bird & Bird, 2026
- Aftellen naar CRA-naleving — Keysight Technologies
- CRA Geharmoniseerde Normen — Keysight, februari 2026
- CRA en open source — Europese Commissie
- DLA Piper CRA-gids — DLA Piper, februari 2026
Dit overzicht wordt onderhouden door het Orbiq-team. Laatst bijgewerkt: maart 2026.