Het lijkt alsof de CRA verplichting Nine Eleven als een vliegende bom zal inslaan. We hoorden op veel bestuursvergaderingen afgelopen maanden verhitte discussies alwaar de kost van een CRA opzet hun naar de rand van de faling leek te duwen. Gelukzalige gezichten als de legal besloot. Voor ons geen CRA! Tot ik plots de luis in de pels werd en de advocaat van de duivel. Hadden ze ook wel overwogen dat de EU Data Act de balans naar CRA registratie kon doen overslaan. De vraag die ik stelde was: En hoe zit het met de EU DATA ACT ?? De vraag van de legal: Wat is de EU DATA ACT? , deed de voorhoofden terug fronsen.
De Europese Data Act lijkt dus in veel cybersecuritydiscussies wat naar de achtergrond verdwenen. De aandacht gaat vandaag vooral naar NIS2, de Cyber Resilience Act en de almaar naderende deadlines rond productbeveiliging en kwetsbaarheidsmeldingen. Toch kan net de implementatie van de Data Act onverwacht bepalen welke bedrijven straks wel onder de CRA vallen.
Die trigger zit minder in de wet zelf dan in de manier waarop organisaties haar technisch uitvoeren.
Fabrikanten van verbonden producten moeten hun klanten toegang geven tot gegevens die door het gebruik van die producten worden gegenereerd. In de praktijk leidt dat al snel tot nieuwe klantenportalen, mobiele applicaties, API’s, databanken en cloudcomponenten. Precies daar ontstaat een juridisch interessante verschuiving. Een onderneming die bij een klassieke CRA-scopeanalyse misschien buiten beeld bleef, kan door de ontwikkeling van zo’n digitale toegangsdienst plots wél een “product with digital elements” op de markt brengen.
Met andere woorden: een API die wordt gebouwd om aan de Data Act te voldoen, kan tegelijk de deur naar de Cyber Resilience Act openen.
Dat maakt de komende periode bijzonder relevant. De Data Act is al van toepassing, nieuwe connected products krijgen vanaf september 2026 aanvullende “access by design”-verplichtingen en ook de eerste operationele CRA-verplichtingen komen nu in beeld. Wie beide regelgevingen afzonderlijk implementeert, riskeert daardoor een belangrijk kruisverband te missen.
In dit artikel bekijken we welke bedrijven met de Data Act rekening moeten houden, welke gegevens daadwerkelijk beschikbaar moeten worden gemaakt en vooral hoe een ogenschijnlijk eenvoudige Data Act-oplossing — een app, API of klantenportaal — de CRA-scope van een onderneming fundamenteel kan veranderen.
De Data Act is onterecht wat uit de nieuwsflow verdwenen, maar implementatietechnisch is hij juist deze maand bijzonder actueel. Vandaag is het 5 september 2026: op 11 september 2026 begint de eerste operationele CRA-verplichting — de meldplicht van art. 14 — en onmiddellijk daarna komt bij de Data Act de belangrijke “access by design”-mijlpaal voor verbonden producten die na 12 september 2026 op de markt worden gebracht.
Mijn vraag over de koppeling Data Act → API/app → CRA was dus terecht. Er bestaat geen juridische bepaling die zegt “Data Act-compliance maakt je automatisch CRA-plichtig”, maar technisch kan precies dát resultaat ontstaan.
Een belangrijk onderscheid: een connected product dat vóór de Data Act-cut-off is uitgebracht hoeft niet achteraf volledig volgens art. 3(1) te worden herontworpen. Maar de toegangsverplichtingen uit art. 4 gelden sinds 12 september 2025 wel. Daardoor kan een fabrikant van een bestaand product alsnog besluiten een portaal, API of app te ontwikkelen om aan art. 4 te voldoen. Dáár ontstaat de interessante CRA-koppeling.
Welke bedrijven moeten rekening houden met de Data Act?
De scope is behoorlijk breder dan alleen klassieke IoT-fabrikanten.
| Bedrijf/rol | Waarom relevant |
|---|---|
| Fabrikanten van connected products | Producten die data over gebruik/omgeving verkrijgen, genereren of verzamelen en die data kunnen communiceren. De Commissie noemt onder meer connected cars, health devices, smart-homeproducten, vliegtuigen, robots en industriële machines. |
| Aanbieders van related services | Software/digitale diensten die nodig zijn om een productfunctie te laten werken of later functies toevoegen, aanpassen of updaten. |
| Verkopers, verhuurders en leasingmaatschappijen | Zij moeten vóór contractsluiting informatie verschaffen over type, formaat en volume van data, realtimegeneratie, opslag/bewaartermijn en wijze van toegang/opvragen/wissen. |
| Data holders | Wie eenvoudig beschikbare product-/dienstdata bezit of kan verkrijgen, moet gebruikers en onder voorwaarden hun gekozen derden toegang geven. |
| Cloud- en andere data-processing providers | Hebben eigen switching-, contract- en interoperabiliteitsverplichtingen, ongeacht waar zij gevestigd zijn wanneer zij klanten in de EU bedienen. |
| B2B-bedrijven die data contractueel delen/gebruiken | De Data Act bevat ook regels tegen eenzijdig opgelegde oneerlijke databedingen. |
De territoriale werking is belangrijk: fabrikanten van connected products en aanbieders van related services kunnen onder de Data Act vallen ongeacht hun vestigingsplaats wanneer het product in de EU op de markt wordt gebracht; hetzelfde geldt voor aanbieders van dataverwerkingsdiensten die EU-klanten bedienen.
Er is wel een relevante uitzondering voor micro- en kleine ondernemingen voor hoofdstuk II, mits ze onder andere niet via een grotere partner/verbonden onderneming alsnog in een grotere groep zitten en niet als onderaannemer voor een grotere partij het product/de dienst maken. Voor pas middelgrote ondernemingen bestaat een beperkte overgang. Dat is echter géén algemene vrijstelling van de hele Data Act.
Eerst die “verplichte logs” nuanceren
De Data Act zegt niet: “alle logs moeten worden bijgehouden en aan de klant worden verstrekt.”
Het uitgangspunt is product data en related-service data die eenvoudig beschikbaar zijn, inclusief metadata die nodig zijn om die gegevens te interpreteren en te gebruiken. De Commissie omschrijft hoofdstuk II vooral als ruwe en voorverwerkte data die uit het gebruik van een connected product of related service voortkomen en zonder onevenredige inspanning voor de datahouder beschikbaar zijn.
Diagnostische events, operationele gegevens, sensorwaarden, foutcodes, usage records en timestamps kunnen dus onder de Data Act vallen wanneer ze aan die criteria beantwoorden. Maar er bestaat geen algemene plicht om nieuwe telemetrie of nieuwe logs te creëren enkel om ze vervolgens te delen.
Sterker nog: voor logging van de Data Act-toegang zelf zegt art. 4(5) dat de datahouder niet meer informatie — uitdrukkelijk inclusief loggegevens — mag bewaren dan nodig voor het uitvoeren van het toegangsverzoek en voor security en onderhoud van de data-infrastructuur.
Dan de interessante vraag: hoe kan een Data Act-oplossing CRA-scope creëren?
Hier zit volgens mij de instinker. De CRA kijkt niet naar de reden waarom je software hebt ontwikkeld. Hij kijkt naar wat je op de markt brengt en hoe die software technisch functioneert. Een product with digital elements is volgens art. 3 CRA een hardware- of softwareproduct plus zijn remote data-processing solutions. De CRA geldt wanneer zo’n product op de EU-markt wordt aangeboden en het direct of indirect logisch of fysiek verbonden is met een apparaat of netwerk.
Daaruit volgen verschillende situaties:
| Data Act-implementatie | Mogelijk CRA-gevolg |
|---|---|
| Data rechtstreeks uit het device exporteren, bijvoorbeeld lokaal bestand/on-device interface | Hiermee creëer je niet noodzakelijk een nieuw afzonderlijk digitaal product. De CRA-status van het fysieke product moet uiteraard nog steeds afzonderlijk worden onderzocht. |
| Alleen een browserportal waar een klant zijn gegevens kan downloaden | Een website/webdienst is niet automatisch zelf een CRA-product. Als hij echter functioneel noodzakelijk wordt voor een ander CRA-product, kan de backend als remote data processing solution binnen de productgrens komen. Recital 12 maakt dit onderscheid expliciet voor websites en cloudservices. |
| Een server-side API om Data Act-data op te vragen | Een API-endpoint is niet simpelweg door het woord “API” automatisch een afzonderlijk CRA-product. Maar de software achter de API kan een remote data processing solution zijn wanneer zij onder verantwoordelijkheid van de fabrikant is ontwikkeld én zonder die verwerking een functie van het digitale product niet kan werken. |
| Downloadbare mobiele app, desktop-app, connector of agent voor toegang tot de data | Dit is veel scherper: software die aan klanten wordt geleverd kan zelf een product with digital elements zijn. De Commissie noemt mobile applications expliciet als voorbeelden van producten die onder de CRA kunnen vallen. |
| Die app gebruikt vervolgens jouw eigen API/backend | Dan kan de app het CRA-product zijn én kan jouw API/backend de bijbehorende remote data-processing solution worden. Dit voorbeeld staat vrijwel letterlijk in overweging 11 van de CRA. |
| App is gratis voor bestaande klanten | “Gratis” redt je niet automatisch. Making available on the market omvat levering in het kader van een commerciële activiteit, zowel tegen betaling als gratis. |
Dit is eigenlijk de kernconstructie
Connected product → Data Act verplicht data-access → fabrikant bouwt customer app → app is zelfstandig softwareproduct → app gebruikt eigen API → API is noodzakelijk voor appfunctie → app + remote backend kunnen in CRA-scope terechtkomen.
En opmerkelijk genoeg beschrijft overweging 11 CRA precies zo’n situatie: een mobiele applicatie die voor haar werking toegang nodig heeft tot een API of database die via een door de fabrikant ontwikkelde dienst wordt aangeboden. De CRA zegt vervolgens expliciet dat die service binnen scope valt als remote data processing solution.
Dat maakt jouw hypothese dus méér dan theoretisch.
De ongemakkelijke situatie: de onderneming dacht terecht buiten CRA te vallen
Denk bijvoorbeeld aan een onderneming waarvan het fysieke product onder een sectorspecifieke CRA-uitzondering valt. Art. 2 sluit onder andere bepaalde producten onder de Medical Devices Regulation, IVDR en de EU-regels voor motorvoertuigen uit; daarnaast zijn bepaalde EASA-gecertificeerde luchtvaartproducten en marine equipment uitgesloten.
Nu bouwt diezelfde fabrikant voor de Data Act een apart customer data application. Hier zou ik beslist niet zeggen:
“Onze machine/auto/device is uitgesloten, dus onze software is ook uitgesloten.”
De CRA-scope is productgericht, niet bedrijfsgericht. Standalone software is zelfstandig een mogelijk product with digital elements. Daardoor moet je vervolgens onderzoeken of ook die app zelf onder dezelfde sectorspecifieke wetgeving valt.
Bijvoorbeeld: software die zelf als medical-device software onder MDR kwalificeert kan mee onder de sectorspecifieke regeling vallen. Maar een gewone customer-data-app die geen medisch hulpmiddel is, krijgt niet vanzelf de MDR-uitzondering enkel omdat hij met een medisch toestel communiceert. Hetzelfde scopeprobleem kan zich voordoen rond voertuigen, luchtvaart en maritieme producten. Dat laatste is een juridische gevolgtrekking uit de product-per-product scope, en verdient bij concrete gevallen een productgerichte legal assessment.
Ook outsourcing lost dit niet noodzakelijk op
Nog een valkuil: “we laten de Data Act-app door een extern softwarehuis bouwen.”
De CRA-definitie van fabrikant omvat ook degene die een product laat ontwerpen of ontwikkelen en het vervolgens onder zijn eigen naam of merk op de markt brengt. Een app laten programmeren door een contractor voorkomt dus niet dat de opdrachtgever CRA-manufacturer kan worden.
Hetzelfde speelt bij remote processing: art. 3(2) spreekt niet alleen van door de fabrikant zelf ontwikkelde software, maar ook van software die is ontwikkeld “under the responsibility of the manufacturer”.
Een generieke cloud/SaaS-dienst die onafhankelijk door een derde is ontwikkeld is iets anders. Recital 12 zegt juist dat cloudservices die buiten de verantwoordelijkheid van de fabrikant zijn ontworpen/ontwikkeld niet om die reden CRA remote data processing worden. Maar dat haalt een eventuele CRA-verplichting voor jouw eigen app/product niet weg.
Data Act “related service” en CRA “remote data processing” zijn niet hetzelfde
Deze twee definities lijken gevaarlijk veel op elkaar, maar ze zijn niet één-op-één.
De Data Act noemt een related service onder andere software waarvan de afwezigheid een of meer productfuncties verhindert, maar ook software die later door fabrikant of derde wordt toegevoegd om functies toe te voegen, te updaten of aan te passen.
Voor CRA remote data processing moet daarentegen sprake zijn van verwerking op afstand, de software moet door of onder verantwoordelijkheid van de fabrikant zijn ontwikkeld, en zonder die verwerking kan het digitale product een van zijn functies niet uitvoeren.
Dus: Data Act related service ≠ automatisch CRA remote data processing solution. Maar het is wel een bijzonder sterke CRA-screening-indicator.
Het sterkste CRA-risico zit volgens mij in de app + API-combinatie
Een API die alleen wat gegevens vanuit een backend beschikbaar stelt, terwijl geen enkel CRA-product daarvan afhankelijk is, is niet automatisch een RDPS. Maar zodra je bijvoorbeeld een Data Act mobile app aan de klant levert, verandert de analyse:
de functie van die app is juist het ophalen/weergeven/exporteren van die productdata.
Als die app zonder jouw backend/API die functie niet kan uitvoeren, heb je precies de functionele afhankelijkheid die de CRA voor remote data processing gebruikt. Dan hoeft de API dus niet noodzakelijk een functie van de fysieke machine mogelijk te maken. Hij kan noodzakelijk zijn voor een functie van de app, die zelf een product with digital elements is. Dat is naar mijn lezing de meest interessante “CRA via de achterdeur”-situatie in jouw vraag — en overweging 11 ondersteunt die lezing opvallend rechtstreeks.
Maar “CRA-plichtig” betekent op 5 september 2026 nog niet meteen volledige CE-compliance
Dit is belangrijk om geen verkeerde alarmbel te luiden. Wanneer zo’n app/API-combinatie onder de CRA valt, zijn er momenteel twee verschillende niveaus:
Vanaf 11 september 2026 geldt art. 14 voor in-scope products with digital elements, ook voor producten die al vóór 11 december 2027 op de markt zijn gebracht. Dat is dus volgende week al operationeel.
De volledige set productvereisten — risk assessment, Annex I security requirements, technische documentatie, conformity assessment, CE-markering, vulnerability handling enzovoort — wordt algemeen toepasselijk 11 december 2027. Voor producten die vóór die datum al op de markt zijn gebracht bevat art. 69 een overgangsregeling: de overige CRA-regels grijpen in beginsel aan wanneer zij vanaf die datum een substantial modification ondergaan; de art. 14-meldplicht is daarvan expliciet uitgezonderd.
Dus een Data Act-app die nu wordt gelanceerd betekent niet automatisch: “volgende week moet er al een volledige CRA-CE conformity assessment klaar zijn.” Maar het kan wél betekenen: “dit is nu een CRA-product en vanaf 11 september moeten we de CRA-reporting scope/processen ervoor hebben geregeld.”
Mijn belangrijkste praktische conclusie
Voor een CRA-scope assessment zou ik vanaf nu nooit alleen de fysieke productcatalogus bekijken. Naast ieder connected product zou ik ook expliciet inventariseren:
firmware → mobile/desktop app → browserportal → client/agent/connector → SDK/library → authentication service → API gateway → manufacturer-developed backend/database → remote update service.
Vervolgens moet je per element vragen: wordt dit softwareproduct aan de markt geleverd; is er een directe/indirecte netwerkverbinding; onder wiens naam wordt het geleverd; wie heeft het ontwikkeld of laten ontwikkelen; en welke product- of appfunctie valt uit wanneer de remote service verdwijnt?
Daarmee worden juist de bedrijven zichtbaar die bij een klassieke CRA-scan ten onrechte als “out of scope” zouden worden gemarkeerd.
En omgekeerd is er ook een nuttig architectuurpunt: de Data Act verplicht niet om per se een cloud-API of mobiele app te bouwen. Art. 3 verlangt toegankelijke data en geeft de voorkeur aan directe toegang waar relevant en technisch haalbaar; art. 4 verlangt een eenvoudige elektronische manier wanneer er geen directe toegang is. Een passende on-device export of eenvoudiger mechanisme kan dus juridisch voldoende zijn zonder onnodig een nieuwe digitale productlaag toe te voegen.
De Commissie heeft bovendien op 27 juli 2026 nieuwe, niet-bindende CRA-guidance gepubliceerd die juist remote data processing, scope, substantial modifications en reporting behandelt. Dat maakt dit het juiste moment om bestaande CRA-scoping opnieuw langs de Data Act-architectuur te leggen.
Lees zeker het boek START2 CRA als voorgerecht bij je assessment
