hoe zorg ik dat de gegevens in het productpaspoort veilig zijn

Toegang, herkomst en manipulatiebescherming zijn de kern

De beveiliging van het productpaspoort draait om drie dingen: alleen bevoegde partijen kunnen bepaalde gegevens zien of wijzigen, gegevens zijn te herleiden tot wie ze heeft aangeleverd, en niemand kan een paspoort achteraf ongemerkt aanpassen. De ESPR (Verordening (EU) 2024/1781) legt dit vast als eis aan het systeem waarin het paspoort draait, niet als losse keuze van de partij die het paspoort samenstelt. Dat betekent dat een platform dat paspoorten host, dit al technisch geregeld moet hebben — de staalhandelaar of metaalverwerker die het paspoort laat aanmaken, hoeft dit niet zelf te bouwen, maar doet er goed aan te weten wat er wél en niet gegarandeerd wordt.

Voor wie dit geldt, en wat erbuiten valt

Deze beveiligingseisen gelden voor het digitale productpaspoort zelf: het bestand met gegevens dat via de QR-code te bereiken is, en het systeem dat dat bestand opslaat en toont. Ze gaan over de vraag wie gegevens mag inzien, wie ze mag wijzigen, en of de herkomst van een wijziging vastligt. Ze gaan niet over de vraag of de inhoud van het paspoort klopt — dat is een kwestie van juistheid van gegevens, geen kwestie van beveiliging. Ze gaan ook niet over de fysieke QR-code op het product: hoe die wordt aangebracht en of die leesbaar blijft, staat beschreven op de pagina over hoe de QR-code op staal terechtkomt, en dat is een ander vraagstuk dan de databeveiliging achter die code. En deze eisen zeggen niets over een specifiek IT-systeem of leveranciersproduct: de verordening schrijft functionaliteit voor, geen techniek.

Belangrijk is ook het onderscheid tussen wie welke gegevens mag zien. Niet elk gegeven in een paspoort is voor iedereen bedoeld — sommige informatie is voor de eindgebruiker, sommige voor een marktdeskundige, sommige alleen voor een toezichthouder. Die gelaagde toegang is onderdeel van hetzelfde beveiligingsvraagstuk, maar de precieze verdeling wordt per productgroep verder ingevuld en staat dus nog niet in detail vast.

Nog geen vaste ingangsdatum, wel een vastliggend kader

Er is nog geen definitieve datum waarop deze beveiligingseisen voor ijzer en staal gaan gelden. Het werkplan van de Europese Commissie voorziet een eerste gedelegeerde handeling in 2026, met verplichtingen die daarna van kracht worden; zodra die handeling is gepubliceerd, wordt de datum hier vermeld. Wat nu al vaststaat, is het kader uit de ESPR zelf: artikel 10 en artikel 11 beschrijven de eisen aan het paspoort en aan het technisch ontwerp, en die tekst verandert niet meer — alleen de productspecifieke uitwerking en de ingangsdatum moeten nog komen. Tot die tijd is er geen wettelijke verplichting om een productpaspoort voor staal te voeren, maar de eisen aan beveiliging die straks gaan gelden, zijn al wel leesbaar in de verordening.

Wat er in de praktijk uit voortvloeit

Bij het inrichten van een paspoort komt de beveiligingsvraag in een vaste volgorde terug. Eerst: wie levert de gegevens aan, en is die herkomst vastgelegd? Een paspoort wordt samengesteld uit gegevens van de fabrikant of importeur, en het moet achteraf te herleiden zijn wie welk gegeven heeft ingevoerd. Ten tweede: wie mag het paspoort na publicatie nog wijzigen? De verordening vereist dat een paspoort niet ongemerkt aangepast kan worden — een wijziging moet zichtbaar of controleerbaar zijn, niet stilletjes overschreven. Ten derde: wie krijgt welke gegevens te zien? Een staalhandelaar die het paspoort doorgeeft aan een klant, hoeft zich niet zelf te bekommeren om de toegangsrechten binnen het systeem — dat is de verantwoordelijkheid van de partij die het paspoort host — maar het is wel goed om te weten dat niet elk gegeven publiek toegankelijk hoeft te zijn.

Wie een productpaspoort wil koppelen aan een bestaand ERP- of voorraadsysteem, doet er goed aan deze beveiligingsvraag vroeg te stellen: gegevens die vanuit een intern systeem automatisch doorstromen naar een openbaar paspoort, moeten onderweg beschermd blijven tegen ongeautoriseerde aanpassing. Meer hierover staat op de pagina over het koppelen van het paspoort aan een eigen systeem. Ook de vraag hoe lang een paspoort na publicatie beschikbaar en onveranderd moet blijven, hangt samen met deze beveiligingseisen; dat onderwerp wordt apart behandeld op de pagina over hoe lang een productpaspoort beschikbaar blijft.

Voor de ondernemer die zelf geen IT-afdeling heeft, komt het in de praktijk neer op een controlevraag aan de partij die het paspoort host: kan die aantonen wie welke gegevens heeft aangeleverd, is er een sluitstuk tegen ongemerkte wijziging, en is de toegang tot gevoelige gegevens afgeschermd van het publieke deel van het paspoort? Dat zijn geen juridische vragen maar praktische, en ze zijn te stellen zonder kennis van de verordening zelf nodig te hebben.

Waar dat staat: artikel 10 en artikel 11 van de ESPR

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) beschrijft de vereisten waaraan het digitale productpaspoort moet voldoen, waaronder de toegang tot gegevens door verschillende typen gebruikers. Artikel 11 gaat specifiek over het technisch ontwerp en de werking van het paspoort, en daarin liggen de eisen over herleidbaarheid, bescherming tegen manipulatie en de werking van het onderliggende systeem vast. Beide artikelen vormen samen het kader waaruit de beveiligingseisen voortvloeien; de verdere technische invulling volgt met de gedelegeerde handelingen die nog gepubliceerd moeten worden.

Wie nu al met een productpaspoort aan de slag wil, kan het beste beginnen met de eigen gegevensstromen op orde te krijgen — vastleggen wie welke gegevens aanlevert en hoe die worden bijgehouden — zodat er straks weinig hoeft te veranderen zodra de verplichting en de technische details definitief zijn vastgesteld.

Waar dit op gebaseerd is

De verordening zelf staat op EUR-Lex. Wij verwijzen per bewering; u hoeft ons niet te geloven.

Wat u concreet moet doen

Wat er van u wordt verwacht

De ESPR stelt eisen aan het productpaspoort die niet alleen gaan over wélke gegevens erin staan, maar ook over hóe die gegevens worden beheerd en beschermd. Artikel 10 en artikel 11 van de ESPR (Verordening (EU) 2024/1781) vormen samen de basis hiervoor: artikel 10 beschrijft de vereisten waaraan het paspoort moet voldoen, artikel 11 gaat specifiek over het technische ontwerp en de werking. Voor een staalhandel of metaalverwerker die dit voor het eerst organiseert, valt dat uiteen in een aantal praktische aandachtspunten.

Toegang tot gegevens regelen naar rol

Niet iedereen die het paspoort raadpleegt, hoeft dezelfde gegevens te zien. Een inkoper bij een constructiebedrijf heeft andere informatie nodig dan een toezichthouder of een recycler aan het einde van de levensduur. Artikel 10 van de ESPR gaat uit van gedifferentieerde toegang: sommige gegevens zijn openbaar, andere zijn alleen zichtbaar voor bepaalde partijen zoals marktdeelnemers of autoriteiten. Voor een bedrijf van 10 tot 100 medewerkers betekent dit dat er, voordat het paspoort live gaat, een keuze gemaakt moet zijn over wie welke gegevenslaag te zien krijgt — en dat die keuze technisch ook echt is doorgevoerd, niet alleen op papier.

Herkomst en juistheid van gegevens borgen

Een productpaspoort is alleen waardevol als de gegevens erin kloppen en traceerbaar zijn naar de bron. Dat raakt aan de betrouwbaarheid van het hele systeem: als een afnemer niet kan nagaan waar een gegeven vandaan komt, verliest het paspoort zijn functie. Praktisch betekent dit dat vastgelegd moet worden wie welk gegeven heeft aangeleverd — de fabrikant, de importeur, of een tussenpartij — en wanneer dat is gebeurd. Voor bedrijven die zelf geen gegevens invoeren maar deze doorgeven, is het van belang te weten hoe de gegevens zijn aangeleverd in het juiste formaat, omdat een foutieve aanlevering zich verderop in de keten vertaalt in een onbetrouwbaar paspoort.

Bescherming tegen wijziging na publicatie

Artikel 11 van de ESPR beschrijft dat het digitale productpaspoort technisch zo moet functioneren dat gegevens niet ongemerkt kunnen worden aangepast nadat ze zijn vastgelegd. Voor een metaalverwerker die het paspoort niet zelf host maar laat hosten — zoals via een platform als dit — betekent dit dat de keuze voor een hostingpartij ook een keuze is over hoe die partij wijzigingen registreert, logt en beveiligt. Dat is geen theoretisch punt: als een klant of toezichthouder een gegeven uit het paspoort betwist, moet aantoonbaar zijn wanneer dat gegeven is vastgelegd en door wie.

Koppeling met bestaande bedrijfssystemen

Veel bedrijven willen het productpaspoort niet als geïsoleerd systeem beheren, maar verbinden met de administratie die er al is. Dat is mogelijk, maar de beveiliging van het paspoort staat dan niet los van de beveiliging van dat onderliggende systeem. Wie overweegt het paspoort te koppelen aan het eigen ERP- of voorraadsysteem, doet er goed aan om te kijken naar wie er toegang heeft tot die koppeling en of een lek in het ene systeem gevolgen heeft voor het andere.

Waar het misgaat in de praktijk

Een aantal situaties komt in de praktijk steeds terug.

Bij bedrijven die de QR-code op het product zelf laten aanbrengen, wordt soms over het hoofd gezien dat de code an sich geen beveiliging biedt — de vraag is wat er gebeurt áchter die code. Wie zich afvraagt hoe de QR-code op het staal terechtkomt, moet zich ook afvragen wie de achterliggende data beheert en of die scheiding tussen drager en inhoud helder is vastgelegd.

Een andere situatie ontstaat wanneer meerdere partijen in de keten gegevens aanleveren voor hetzelfde paspoort, zonder dat vooraf is afgesproken wie welk deel mag aanpassen. Dat leidt tot verwarring over welke versie de geldige is, en soms tot het per ongeluk overschrijven van juiste gegevens door een andere partij.

Ook bij kleine onderdelen gaat het weleens mis: als een QR-code op een klein stukje staal technisch beperkt is, wordt soms gekozen voor een vereenvoudigde link of een tussenpagina — waarbij niet altijd is nagedacht over of die tussenstap dezelfde beveiligingsafspraken volgt als het hoofdpaspoort.

Een vierde situatie: bedrijven die zelf een offline kopie van paspoortgegevens bijhouden voor gebruik op locaties zonder verbinding, vergeten die kopie te synchroniseren of te beveiligen op dezelfde manier als de online versie. Dat is een reëel punt, want niet elke werkplek heeft een stabiele verbinding, en de vraag of het paspoort ook offline moet werken speelt juist bij dit soort praktische inrichting.

Tot slot: bedrijven die stoppen of een bedrijfsonderdeel afstoten, vergeten soms dat de gegevens van het paspoort blijven bestaan en dat toegang en beheer daarvan overgedragen moeten worden — iets dat te maken heeft met de vraag wat er met het paspoort gebeurt als het bedrijf stopt.

Wat u kunt vastleggen

Een aantal afspraken en documenten helpt om de beveiliging van paspoortgegevens aantoonbaar te maken:

Een overzicht van wie welke rol heeft in het aanleveren en beheren van gegevens, inclusief contactpersoon per partij in de keten.
Een registratie van de herkomst van elk gegeven: van welke fabrikant, importeur of tussenpartij het afkomstig is en op welk moment het is aangeleverd.
Afspraken met de hostingpartij over logging van wijzigingen, zodat aantoonbaar is wanneer een gegeven is vastgelegd en of het nadien is aangepast.
Een beschrijving van de toegangsniveaus die zijn ingesteld: welke gegevens openbaar zijn en welke alleen zichtbaar zijn voor specifieke partijen.
Indien van toepassing, een overzicht van de koppeling met het eigen ERP- of voorraadsysteem, met daarin wie toegang heeft tot die koppeling.
Een plan voor de situatie waarin het bedrijf stopt of een onderdeel wordt overgedragen, zodat beheer en toegang tot bestaande paspoorten niet in de lucht komen te hangen.

Deze vastlegging is niet alleen nuttig richting toezicht, maar ook praktisch: het voorkomt dat interne kennis over wie wat beheert, verloren gaat bij personeelswisselingen of bedrijfsovername.

Dit is geen juridisch advies. Deze pagina geeft algemene informatie over de regelgeving waar dit platform over gaat. Wij kennen uw situatie niet. Bij twijfel over uw eigen geval raadpleegt u een jurist of de bevoegde toezichthouder.

Geschreven met AI op basis van de bronnen hierboven, gecontroleerd door een mens op 2026-09-05. Klopt er iets niet? Laat het weten — correcties krijgen voorrang.