Een slimme meter is geen meetinstrument meer. Het is een endpoint in kritieke infrastructuur. En zodra je miljoenen endpoints uitrolt, wordt “wie levert” minder belangrijk dan “wie bestuurt”. De DSMR6 E-meter-tender laat dat scherp zien. In 2024 startten netbeheerders de aanbesteding voor de volgende generatie slimme elektriciteitsmeters. De looptijd is lang en de impact groot. In 2025 belandde het dossier in de rechtszaal: een inschrijver betwistte de gunning, onder meer op het punt of de winnende leverancier wel voldeed aan de eis dat assemblage in een GPA-land (Government Procurement Agreement, red.) plaatsvindt, waartoe China niet behoort. De rechter ging daar niet in mee en de gunning bleef staan.
Slimme meters, slimme grenzen: wie houdt straks de sleutelbos?
Nederlandse netbeheerders kregen de afgelopen weken flinke kritiek op de aanbesteding van Chinese sensoren voor slimme meters. Angst voor afhankelijkheid van China en privacy schending spelen hierin de hoofdrol. De aanbesteding is via Europese richtlijnen verlopen, stellen de netbeheerders, maar biedt dat voldoende garanties? Volgens Ronald Scherpenisse is “wie levert” minder belangrijk dan ‘wie bestuurt’. Belangrijk is dat soevereiniteit als meetbare SLA opgenomen wordt en dat bij geopolitieke of juridische verstoring break-glass procedures van kracht kunnen worden.
Op het eerste gezicht is dit een technisch-juridisch detail. Maar juist dit detail toont welke grens in de aanbesteding als hard wordt beschouwd: de assemblagegrens.
Assemblage en security
In de gepubliceerde tenderinformatie zien we dat “GPA Candidate” wordt gedefinieerd aan de hand van drie factoren: vestiging in een GPA-land, assemblage in een GPA-land en uiteindelijk belanghebbenden (UBO’s) in een GPA-land. Ook wordt assemblage in vragen en antwoorden omschreven als “in de breedste zin”. In de vraagstelling wordt daarbij expliciet verwezen naar stappen die ook security raken, zoals programmeren, configureren en het laden van securitymateriaal (bijvoorbeeld encryptiesleutels).
Dat is relevant, want het laat zien dat assemblage niet alleen een productiestap is, maar ook een securitymoment. Tegelijkertijd zit de echte soevereiniteitsvraag niet in de fabriekshal. Die zit in de bedieningslaag na installatie: updates, sleutels en toegang.
Expliciet vastleggen
In de gepubliceerde stukken die ik heb kunnen inzien, vind ik wél expliciete eisen rondom GPA, eigendom en transparantie over buitenlandse subsidies (FSR). Maar ik kon op basis van diezelfde publiek beschikbare set niet expliciet valideren of, en hoe, de aanbesteding grenzen stelt aan:
- remote toegang tot de beheerketen (leverancier, derde partijen)
- geo-grenzen voor remote support (EU/EEA, Nederland, of wereldwijd)
- governance van firmware-updates (wie autoriseert, wie tekent, wie rolt uit, wie kan terugdraaien)
- key custody: waar sleutels worden gegenereerd, beheerd en geaudit
Belangrijk: dat betekent niet dat deze eisen niet bestaan. Ze kunnen in annexen of contractteksten staan die niet publiek of niet in de door mij ingeziene set zijn opgenomen. Maar het punt is breder: als dit soort controls niet expliciet en auditeerbaar is vastgelegd in het sourcingproces, dan wordt soevereiniteit impliciet een aanname.
En “general practices” in de industrie bewegen de andere kant op. Follow-the-sun support, centrale updatepijplijnen en cloud-native fleet management zijn schaalbaar en goedkoper. Maar zonder harde kaders leiden ze tot control plane drift: feitelijke controle verschuift naar leverancier of ketenpartners, ongeacht waar het product is geassembleerd.
Soevereiniteitsrisico
De risicostelling is daarom eenvoudig: als remote access, update authority en key custody niet expliciet begrensd en aantoonbaar geborgd zijn, ontstaat een structureel soevereiniteitsrisico. Niet omdat iemand kwaad wil, maar omdat economische optimalisatie zelden samenvalt met publieke weerbaarheid.
De oplossing ligt in continue borging: soevereiniteit als meetbare SLA, break-glass clausules bij geopolitieke of juridische verstoring en een continuiteitsplan waarmee patching en support ook onder druk doorgaan.
De volledige uitwerking, inclusief de control-plane waarheidstoets en een concreet mitigatiepakket, staat deze long read op LinkedIn
Plaats een reactie
U moet ingelogd zijn om een reactie te kunnen plaatsen.
Zolang niet wordt vastgelegd in de Europese aanbestedingsregels dat productielanden buiten de EER mogen worden uitgesloten zullen we met dit probleem blijven zitten. Denk maar aan de diverse OV-concessies met bussen uit China die inmiddels zijn gedaan. Of beveiligingscamera's waarbij camera's uit China niet mochten worden geweigerd. Dan kan de AIVD adviseren wat ze wil, maar de wetgeving laat uitsluiting gewoon niet toe. Zeer frustrerend dit!
Prima analyse. Uiteindelijk komt soevereiniteit in de operationele zin neer op control en corporate governance. Dus business as usual: hoe werkt de keten, beheersing van risks voor ongeautoriseerde toegang , continuiteit en integriteit , en dan preventie en detectie. Kortom, Een goed werkend control system - gebaseerd op criteria (en maatregelen), degelijke controle met een jaarlijkse audit, rapportage en continue verbetering.
Je kunt simpelweg zeggen: door de geopolitieke ontwikkelingen zijn sommige risks toegenomen. Je moet daar dus meer aan doen. Dat is een betere, rationelere benadering dan steeds te roepen "je moet technologie uit alle landen die andere regels en mores hebben dan wij helemaal gaan vermijden". In de hoop dat je dan die risico's niet hebt. En irrationeel want uiteindelijk zit overal wel ergens een luchtje aan.
Wat een goed en noodzakelijk artikel! Onze elektriciteitsvoorziening is inmiddels kritieke infrastructuur en dus te belangrijk geworden om aan de onderhoudsmonteur over te laten. Het is een strategisch Business Continuity Asset geworden en een sociale verzekering. Gelukkig gaat het uiteindelijk inderdaad om de data en die dingen ZIJN data. Elk van die sensoren heeft een merk, een type, een versie, een variant, een batchnummer, een locatie, iemand die hem heeft geplaatst etc. Het kernidee “wie levert” is minder belangrijk dan “wie bestuurt” Een slimme meter uit China kan technisch prima zijn, maar het risico zit vaak niet in de meter als “doosje”, maar in de besturing eromheen: wie mag de updates sturen, wie beheert de sleutels (encryptie/ identiteiten), wie kan op afstand inloggen (remote access) en waar gaan de data heen en wie mag ze zien? DAARVOOR hebben we nou NIS2 en de EU Data Act: die eisen niet “koop bij land X”, maar wel dat jij je risico’s beheerst, inclusief de supply chain security, incident handling, business continuity, cryptografie en access control. De EU Data Act komt daar nog bij. NIS2 zegt dus: "beste netbeheerder/energie-keten, jullie zijn kritisch, dus je móét maatregelen nemen. De Data Act zegt o.a. (voor connected devices/data en data processing services) dat gebruikers toegang MOETEN kunnen krijgen tot data uit hun connected product/related service en dat er interoperabiliteit mechanismen MOETEN zijn, alsmede waarborgen tegen onrechtmatige toegang (ook door derde-land overheden) tot niet-persoonsgebonden data die in de EU wordt gehouden. Nog los van het feit dat het vrij stom is om je killswitch in buitenlandse handen te leggen. Kun je Chinese slimme meters zo veilig maken? Zeker! Met NGSI-LD + FIWARE (PDP/PEP). De slimme meter is een sensor. De FIWARE Context Broker (Open Source software) kun je zien als de “centrale postkamer” waar metingen als “context” binnenkomen. Het Policy Enforcement Point (PEP) is de “portier bij de deur” (controleert of je binnen mag) en het Policy Decision Point (PDP) is de “chef beveiliging” die de regels kent en beslist: ja/nee. Dus bouw je besturing gewoon zó dat de leverancier geen “control plane” heeft. De meter mag best data sturen, maar kan niet “stiekem bestuurd” kunnen worden door de fabrikant. Dus moet je een architectuur verplicht stellen en ook real time controleren dat meters nooit direct met de leverancier KUNNEN praten. Alleen verbinding naar netbeheerder-headend/DMZ via een streng gecontroleerd netwerkpad (bijv. private APN/VPN). Gebruik een FIWARE Context Broker als standaard data-laag. (https://github.com/FIWARE/context.Orion-LD)
Standaardiseer de data met NGSI-LD (semantisch model), door ETSI gestandaardiseerd voor contextinformatie (digitale tweelingen/context-data via API) en zet een PEP als filter/policy checklist vóór je broker en APIs (Policy Enforcement Point)**
Met zo'n PEP-proxy bescherm je de backend services, zodat alleen geautoriseerde gebruikers/systemen erbij kunnen. Gebruik een PDP voor beslissingen op basis van beleid (ABAC - Attribute Based Access Control). Je kunt bijvoorbeeld AuthZForce gebruiken; een PDP/PAP die ABAC ondersteunt via XACML 3.0.
(https://github.com/authzforce/server) Nu wordt het mogelijk om identiteit/tokens te kunnen regelen (wie ben je?) en dat los kan trekken van de autorisatie (wat mag je?)
Open source software als Keyrock (FIWARE IdM) levert OAuth2-based identity management en werkt samen met PEP en PDP. Dus zelfs als de hardware “van China” is, dan kan de macht wel degelijk bij de netbeheerder liggen én je data kan in een open standaard (NGSI-LD) worden opgeslagen, waardoor je makkelijker van leverancier kunt wisselen (minder lock-in). Soevereiniteit hoor je meetbaar te maken door in contracten en techniek af te dwingen dat je sleutels alleen kunt genereren/beheren in de EU (HSM) en niet bij de vendor. Firmware-updates moet je alleen toelaten als ze ook door de netbeheerder zijn getekend en via de eigen updatepipeline gaan. Je kunt remote access = default uit afdwingen, dus geen “follow-the-sun support” zonder harde grenzen.
Nu wordt het ook mogelijk om een "Break-glass" handeling te kunnen organiseren bij geopolitieke/juridische verstoring, dus alle vendor-remote routes dicht, alleen nood-updatekanaal (eigen keys), versneld key-rotatie plan, minimale dienstverlening blijft werken (business continuity). Dat sluit aan op NIS2-eisen rond supply chain, incident handling en continuïteit. (https://eur-lex.europa.eu/eli/dir/2022/2555/oj)
Alle benodigde protocollen bestaan en zijn uitgekristalliseerd. Nu gebruiken.