Overslaan en naar de inhoud gaan
(advertentie)

De sociale schaduwzijde van digitale veiligheid

Jonge man staart vertwijfeld naar smartphone
- Shutterstock

Google en Apple zijn al langere tijd gestopt met de ondersteuning van Android 10/11 en iOS 15. Deze besturingssystemen ontvangen daarom geen beveiligingsupdates meer. Vanuit cyberveiligheid is dat een logische stap. Verouderde software vormt immers een risico voor gebruikers en voor de digitale infrastructuur als geheel. Maar wat technisch begrijpelijk is, heeft maatschappelijke gevolgen.

Banken als ABN AMRO en ING hebben inmiddels aangekondigd hun apps vanaf maart niet langer te ondersteunen op deze systemen. Andere digitale diensten zullen volgen. Daarmee dreigt een situatie te ontstaan waarin een grote groep mensen van de ene op de andere dag geen toegang meer heeft tot hun bankrekening, DigiD of andere essentiële voorzieningen. De vraag is niet of digitale veiligheid noodzakelijk is, daar is geen twijfel over. De vraag is hoe we voorkomen dat veiligheidsbeleid onbedoeld leidt tot digitale uitsluiting en daarmee tot nieuwe uitvoeringsproblemen voor gemeenten.

De vraag is hoe we voorkomen dat veiligheidsbeleid onbedoeld leidt tot digitale uitsluiting en daarmee tot nieuwe uitvoeringsproblemen voor gemeenten.

De smartphone als publieke infrastructuur

De smartphone is allang geen luxeproduct meer. Voor veel inwoners is het een primair en soms enige toegangspunt tot publieke dienstverlening. Bankzaken, zorgportalen, overheidsberichten, OV-betalingen en communicatie met instanties verlopen grotendeels via apps. Wie geen werkende smartphone heeft, kan in de praktijk niet volwaardig deelnemen aan een samenleving die op rap tempo digitaliseert. Daarmee is de smartphone feitelijk onderdeel geworden van onze publieke infrastructuur.

Toch behandelen we de uitfasering van besturingssystemen nog altijd als een individuele consumentenkwestie. ‘Dan koop je toch een nieuw toestel?’ Dat uitgangspunt miskent de realiteit van een aanzienlijke groep burgers.

Twee groepen, twee opgaven

De komende maanden zullen twee groepen zichtbaar worden. De eerste groep heeft een toestel dat technisch nog kan worden geüpdatet, maar deze groep weet niet hoe dat moet of durft het niet. Angst om iets ‘kapot te maken’, beperkte digitale vaardigheden of taalbarrières spelen hierbij een rol. Voor deze groep is ondersteuning bij het updaten van apparaten vaak voldoende.

De tweede groep heeft een toestel dat simpelweg niet meer te updaten is. Voor hen rest slechts één optie: een nieuw toestel aanschaffen. En daar ontstaat de spanning. Voor huishoudens die leven rond het bestaansminimum is een smartphone van 150 tot 800 euro geen vanzelfsprekende uitgave. Tegelijkertijd zijn zij vaak juist afhankelijk van digitale dienstverlening voor toeslagen, zorgtoegang en schuldhulp. Wat vanuit veiligheid logisch is, kan in de praktijk betekenen dat mensen hun bankzaken niet meer kunnen regelen, geen toegang meer hebben tot DigiD of niet kunnen inloggen op gemeentelijke systemen.

Voor huishoudens die leven rond het bestaansminimum is een smartphone van 150 tot 800 euro geen vanzelfsprekende uitgave.

Een stille verschuiving naar het lokale niveau

De beslissing om besturingssystemen uit te faseren wordt genomen door internationale techbedrijven. Banken passen hun beveiligingsbeleid daarop aan. Maar de gevolgen landen lokaal. Gemeenten zullen te maken krijgen met inwoners die vastlopen. Wijkteams, bibliotheken, balies en schuldhulpverleners zullen de eerste signalen oppakken. Niet omdat gemeenten het beleid bepalen, maar omdat zij het vangnet vormen wanneer systemen haperen. Daarmee dreigt digitale veiligheid een nieuw uitvoeringsvraagstuk te worden in het sociaal domein. Dit is geen incident. De cyclus van technologische vernieuwing versnelt. Hardware wordt sneller afgeschreven. Software-eisen worden zwaarder. Zonder structurele aanpak zal deze problematiek zich herhalen, telkens met nieuwe groepen die achterblijven.

De kosten van niets doen

Wanneer inwoners plotseling geen toegang meer hebben tot digitale diensten, ontstaan er risico’s zoals:

  • Gemiste betalingen en oplopende schulden
  • Geen toegang tot zorgportalen om zorg te regelen
  • Meer vraagstukken en fysieke druk bij (gemeente)loketten
  • Toename van informele afhankelijkheid van familie of buren
  • Verminderd vertrouwen in de digitale overheid

De maatschappelijke kosten van uitsluiting zijn hoger dan de kosten van preventie. Digitale veiligheid mag niet onbedoeld leiden tot uitsluiting van de digitale samenleving.

Digitale veiligheid is ook sociaal beleid

Cybersecurity en sociale inclusie worden vaak als gescheiden domeinen behandeld. Het ene valt onder IT en informatieveiligheid, het andere onder het sociaal domein. In werkelijkheid raken ze elkaar steeds vaker. Wanneer digitale veiligheidseisen ertoe leiden dat mensen hun toegang verliezen, wordt veiligheid een sociale beleidskwestie. Dat vraagt om integrale benadering. Gemeenten hoeven het probleem niet alleen op te lossen, maar zij kunnen wel op tijd anticiperen.

Gemeenten hoeven het probleem niet alleen op te lossen, maar zij kunnen wel op tijd anticiperen.

Wat is er nodig?

Allereerst: tijdige communicatie. Veel inwoners weten niet dat hun toestel binnenkort niet meer wordt ondersteund. Gerichte voorlichting via gemeentelijke kanalen, wijkteams en lokale partners kan paniek en escalatie voorkomen.

Ten tweede: versterking van ondersteuningsstructuren. Bibliotheken, maatschappelijke organisaties en vrijwilligersnetwerken spelen een belangrijke rol bij het begeleiden van updates en toestelwisselingen. Extra middelen of tijdelijke inzet kunnen voorkomen dat mensen langdurig buiten spel staan.

Ten derde: structurele toegang tot betaalbare hardware. Voor de groep die geen nieuw toestel kan aanschaffen, is een incidentele oplossing onvoldoende. Denk aan landelijke of regionale afspraken over refurbished smartphones, publiek-private samenwerking of fondsenconstructies. Net zoals laptops inmiddels via herinzettrajecten een tweede leven krijgen, kan dit ook gelden voor smartphones.

Ten vierde: het gesprek aangaan met dienstverleners. Gemeenten, al dan niet via de VNG, kunnen het gesprek voeren met banken en andere aanbieders over gefaseerde uitfasering, webalternatieven of lichtere versies van apps. Veiligheid hoeft niet automatisch te betekenen dat oudere systemen van de ene op de andere dag worden afgesloten.

Van incident naar structurele aanpak

De kern van het vraagstuk is niet technologisch, maar bestuurlijk. Zolang digitale dienstverlening de norm is, moet toegang tot die dienstverlening ook als publieke randvoorwaarde worden beschouwd. Dat betekent niet dat gemeenten verantwoordelijk zijn voor elke software-update. Wel betekent het dat digitale veiligheid en digitale inclusie niet los van elkaar kunnen worden gezien. Wie inzet op een digitale overheid, moet ook nadenken over de toegankelijkheid van de middelen waarmee inwoners die overheid bereiken.

Wie inzet op een digitale overheid, moet ook nadenken over de toegankelijkheid van de middelen waarmee inwoners die overheid bereiken.

Een gezamenlijke verantwoordelijkheid

Digitale veiligheid is noodzakelijk. Niemand pleit voor het openhouden van onveilige systemen. Maar veiligheid die leidt tot uitsluiting ondermijnt het vertrouwen in digitalisering. Een inclusieve digitale samenleving vraagt om gezamenlijke verantwoordelijkheid van overheid, bedrijven en maatschappelijke organisaties.

Voor gemeenten betekent dit: agendeer het onderwerp tijdig, verbind het aan bestaanszekerheid en digitale inclusie en werk samen met partners om te voorkomen dat inwoners tussen veiligheid en toegang moeten kiezen. De uitfasering van Android 11 en iOS 15 is een technisch feit. De maatschappelijke gevolgen ervan zijn dat niet. Die zijn het resultaat van keuzes en daarmee beïnvloedbaar.

De vraag is niet of digitale veiligheid belangrijk is. De vraag is hoe we die veiligheid vormgeven zonder nieuwe ongelijkheid te creëren. Dat vraagt bestuurlijke aandacht. En die aandacht is nu nodig, niet pas wanneer de eerste inwoners zich aan de balie melden omdat hun bankapp het niet meer doet.

Plaats een reactie

U moet ingelogd zijn om een reactie te kunnen plaatsen.

Vincent Hoek | 2 maart 2026, 12:36

Zoals de cabaretier Hans Teeuwen al zei: "Leuk ... die zwakkeren ... maar ze houwen de boel wèl op!" Deze analyse klopt — maar de oplossingsrichting is veel te defensief; betere communicatie, refurbished toestellen, gesprekken met banken — zijn slechts symptoombestrijding binnen een (gebrek aan) architectuur die op dit moment zélf het probleem veroorzaakt. Niet omdat overheden slordig of dom waren, maar omdat de maatschappelijke dataficering ongekende combinaties mogelijk heeft gemaakt, waar organisaties zich nog op aan moeten passen. We proberen vooralsnog om mensen toegang te geven tot een Systeem dat structureel uitsluitend is ontworpen.
De kern van het probleem is niet dat Android 10 geen updates meer krijgt.
De kern van het probleem is dat identiteit, authenticatie en toegang tot publieke diensten gekoppeld is aan propriëtaire ecosystemen van techbedrijven. Zolang Apple en Google bepalen welk besturingssysteem "veilig genoeg" is en zolang banken en overheden die afhankelijkheid klakkeloos overnemen, zal elke hardware-cyclus opnieuw een uitsluitingsgolf produceren. Daar kan de politiek écht niet bij helpen, alleen architectuur en verplichte compliance. Het structurele alternatief ligt namelijk allang op tafel — in Europees beleid, in internationale standaarden en in allang bewezen technologie. Het vereist alleen bestuurlijke moed om het te implementeren.
Alles wat nodig is, is het naleven van drie architectuurprincipes.
Stap 1: trek identiteit gewoon los van het apparaat. (Verifiable Credentials)
Het huidige model werkt als volgt: je identiteit zit opgesloten in een app (DigiD, bankapp), die draait op een besturingssysteem (Android/iOS), dat draait op hardware (smartphone), die wordt ondersteund door een fabrikant (Google/Apple).
Vier afhankelijkheden in serie. Valt er één weg, dan verlies je alles!
Verifiable Credentials (VCs) doorbreken deze keten fundamenteel. Een VC is een cryptografisch ondertekend digitaal bewijs — van je identiteit, je leeftijd, je recht op een toeslag, je BSN-verificatie — dat door de houder zelf wordt beheerd (holder-centric model) en onafhankelijk is van een specifieke app of platform. Daardoor is het verifieerbaar zonder dat de verificateur contact hoeft met de uitgever, waarna het op elk apparaat kan worden gepresenteerd dat basale cryptografie ondersteunt — inclusief een webbrowser op een vijf jaar oude telefoon. Easy. Concreet betekent dit: een inwoner hoeft géén DigiD-app meer te installeren die Android 13 vereist. Een verifiable credential kan worden opgeslagen in een wallet die als progressive web app (PWA) draait, of zelfs als QR-code op papier wordt gepresenteerd bij een fysiek loket. De W3C Verifiable Credentials Data Model 2.0-standaard is hiervoor al jaren geleden vastgesteld. De European Digital Identity Wallet (EUDI Wallet) onder eIDAS 2.0 is precies op dit principe gebouwd! Een pragmatische stap voor gemeenten zou dus zijn om aan te dringen via de VNG op versnelde implementatie van de EUDI Wallet-architectuur, met de expliciete eis dat de wallet ook functioneert op oudere besturingssystemen via webstandaarden — niet alleen als native app. Stap 2: Data Spaces: dienstverlening zonder centrale platformafhankelijkheid. Het tweede structurele probleem is namelijk dat élke dienstverlener — bank, zorgverzekeraar, gemeente, UWV — zijn eigen app bouwt met zijn eigen beveiligingseisen en zijn eigen systeemvereisten en achterhaalde politieke mindset (mandaat/budget leidt tot infrastructuurcentrische puntoplossingen). Zo moet 'de burger' een stuk of tien apps zien te onderhouden op een toestel dat vervolgens dus tien sets eisen moet vervullen. Architecturaal onhoudbaar!
Data Spaces bieden een fundamenteel ander model. In een Data Space-architectuur — zoals uitgewerkt in het International Data Spaces (IDS) Reference Architecture Model en de Gaia-X-principes — worden data en diensten niet gecentraliseerd in apps, maar gefedereerd en gedecentraliseerd uitgewisseld tussen deelnemers op basis van gestandaardiseerde protocollen, afspraken en vertrouwensraamwerken.
Nu ziet het inclusievraagstuk er ineens anders uit. Je hebt dan nog maar één toegangspunt in plaats van tien apps. Een inwoner kan via één wallet of portaal — gemeentelijk, bibliotheek-gebaseerd, of zelfs een fysiek loket met een medewerker — toegang krijgen tot bankgegevens, toeslagen, zorgportalen en gemeentelijke diensten. Niet omdat alles in één systeem zit, maar omdat de onderliggende Data Space-connectoren de uitwisseling regelen en PET (Privacy Enhancing Technologies) domweg worden meegenomen in de Policy Decision en Enforcement points. Een Data Space-architectuur dwingt af dat de dienst juist NIET gekoppeld is aan het kanaal. De bankdienst is de bankdienst — of je die nu bereikt via een app op een nieuwe iPhone, via een webbrowser op een oude Android, via een terminal in de bibliotheek, of via een baliemedewerker die namens jou handelt met jouw expliciete toestemming (vertegenwoordiging via VC-mandaat). Het gaat om de DATA en niet om de INFRASTRUCTUUR.
Er is dus geen vendor lock-in op OS-niveau meer mogelijk, want de Data Space-connector (bijv. gebaseerd op het Eclipse Dataspace Components-framework) communiceert via open standaarden (HTTP, JSON-LD, DID-communicatie). Het maakt het besturingssysteem irrelevant, zolang het basisprotocollen ondersteunt. Je kunt gemeentelijke dienstverlening dan gewoon ontsluiten via een Data Space-connector die ook via een webinterface bereikbaar is. Koppel dit aan de lopende MijnOverheid-vernieuwing en de Common Ground-architectuur die veel gemeenten al implementeren en je kunt zelfs de oudere investeringen gewoon uitnutten. Dan is er stap 3: Decentralized Identifiers (DIDs): vertrouwen zonder platformtussenpersoon. Het derde element is de gefedereerde identiteitslaag. Momenteel is DigiD een gecentraliseerd systeem dat afhankelijk is van een specifieke app met specifieke systeemeisen. Dit is een single point of failure — niet alleen technisch, maar ook sociaal. Decentralized Identifiers (DIDs) — de W3C-standaard die de basis vormt onder Verifiable Credentials — maken het mogelijk om identiteitsankers te creëren die niet afhankelijk zijn van één provider. Een DID kan worden verankerd op een blockchain, op een gedistribueerd register, of op een DNS-achtige infrastructuur. Het punt is: de burger is niet langer afhankelijk van Google Play Services of Apple's Secure Enclave om zijn identiteit te bewijzen.
Daarbij zouden we dan gedifferentieerde vertrouwensniveaus moeten hanteren. Niet elke handeling vereist hetzelfde beveiligingsniveau. Het opvragen van openbare gemeentelijke informatie vereist minder dan het wijzigen van een bankrekening. Met DIDs en VCs kun je Level of Assurance (LoA) differentiëren: een eenvoudige credential-presentatie via een webbrowser voor lage-risico handelingen, een hardware-gebonden credential voor hoge-risico handelingen. Dit voorkomt dat de zwaarste beveiligingseis de universele drempel wordt en scheelt bakken aan kosten. Het levert ook allerlei frisse mogelijkheden, want je kunt bijvoorbeeld vertegenwoordiging en mandatering dan formaliseren. Een mantelzorger, een maatschappelijk werker of een gemeenteambtenaar kan — met een cryptografisch verifieerbaar mandaat — namens een inwoner handelen. Dit is nu al juridisch mogelijk, maar technisch niet ondersteund ... om dat verschillende overheden, onder verschillende mandaten, op basis van verschillende budgetten verschillende puntoplossingen verwerven.
Met DIDs en VCs wordt dit echter een standaard patroon in de architectuur en zeker binnen het Rijk vindt je wel degelijk hele slimme pilots die precies dit 'doen'.
Wat dus nodig is, is samenwerking in Proofs of Value voor gedelegeerde digitale identiteit, waarbij een baliemedewerker of wijkteamlid met een verifieerbaar mandaat namens een inwoner kan handelen in het digitale domein. We moeten niet 'de digibeet' gaan helpen, maar 'iedereen' . Het gaat niet om achterstalligheid, maar om een integrale architecturale omslag van apparaat-centrisch naar mens-centrisch, van applicatie-centrisch naar data-centrisch en van content-centrisch naar context-centrisch.
Dus van het huidige model: Burger → Smartphone → OS → App → Dienst
(Apple/Google controleert de hele keten) naar Burger → Credential (in eigen beheer)
→ Kanaal naar keuze (app / web / loket / vertegenwoordiger)
→ Data Space connector
→ Dienst (bank / gemeente / zorg / UWV)
In dit model bepaalt niet het besturingssysteem of je toegang hebt, maar je verifieerbare identiteit en je rechten. Het kanaal wordt inwisselbaar. De beveiliging zit in de cryptografie van de credential, NIET in de versie van Android of Apple.
Wat dit vraagt zijn vijf concrete acties:


Kanaal-onafhankelijkheid als architectuurprincipe.
Geen enkele essentiële dienst mag uitsluitend via een native app beschikbaar zijn. Dit is geen technische wens — het is een toegankelijkheidsvereiste die verankerd moet worden in de Wet digitale overheid (Wdo) en de bijbehorende uitvoeringsregelingen.


Versnel de EUDI Wallet-implementatie met expliciete inclusie-eisen.
De huidige EUDI Wallet-pilots (onder de Large Scale Pilots: POTENTIAL, EWC, DC4EU, NOBID) focussen primair op functionaliteit en interoperabiliteit. Voeg een expliciete eis toe: de wallet-functionaliteit moet ook beschikbaar zijn via een webstandaard (PWA) die functioneert op besturingssystemen tot minimaal vijf jaar oud.


Richt een gemeentelijke Data Space-connector in als onderdeel van Common Ground. Veel gemeenten werken al met de Common Ground-architectuur (NLX, Haven, API-standaarden). Bouw hier gewoon op voort door een Data Space-connector te implementeren die het mogelijk maakt dat inwoners via één toegangspunt — digitaal of fysiek — gefedereerd toegang krijgen tot meerdere dienstverleners.


Ontwikkel een mandateringsstandaard op basis van Verifiable Credentials.
Formaliseer het patroon waarbij een vertegenwoordiger — formeel of informeel — namens een inwoner kan handelen in het digitale domein. Dit lost niet alleen het OS-uitfaseringsprobleem op, maar ook de bredere problematiek van digitale toegang voor ouderen, laaggeletterden en mensen met een beperking.


Organiseer de financiering structureel, niet incidenteel.
De kosten van een refurbished smartphone zijn veel lager dan de kosten van één schuldhulpverleningstraject dat ontstaat doordat iemand zijn bankzaken niet meer kon regelen. Reken het door. Maak het onderdeel van de reguliere financiering van digitale inclusie, niet van een eenmalige subsidieregeling.


Dit kan allemaal vrij snel gerealiseerd worden. Alles bestaat allang. De W3C-standaarden voor DIDs en VCs zijn vastgesteld. De eIDAS 2.0-verordening is aangenomen. De EUDI Wallet-architectuur wordt nu gebouwd. Data Spaces zijn allang operationeel in domeinen als mobiliteit (Catena-X), energie en gezondheid. De Eclipse Dataspace Components zijn gewoon Open Source beschikbaar en Common Ground draait bij tientallen gemeenten. Wat ontbreekt is niet technologie. Wat ontbreekt is de multidisciplinaire bestuurlijke verbinding tussen cybersecurity, digitale identiteit en sociale inclusie. Zolang we deze drie als gescheiden domeinen behandelen — het eerste bij de CISO, het tweede bij BZK, het derde bij het sociaal domein — zullen we bij elke OS-uitfasering opnieuw verrast worden door dezelfde voorspelbare gevolgen.
De uitfasering van Android 10/11 en iOS 15 is namelijk geen incident. Het is een structureel kenmerk van een architectuur die afhankelijk is van propriëtaire platformen voor publieke dienstverlening. De oplossing is dus NIET om die afhankelijkheid te verzachten met refurbished toestellen en soft sector communicatiecampagnes. De oplossing is om die afhankelijkheid pragmatisch te doorbreken — met Open Standaarden, gedistribueerde identiteit en gefedereerde data-uitwisseling.
Dat is geen utopie. Dat is architectuur en uiteindelijk échte Vrijheid.

Melden als ongepast

Door u gemelde berichten worden door ons verwijderd indien ze niet voldoen aan onze gebruiksvoorwaarden.

Schrijvers van gemelde berichten zien niet wie de melding heeft gedaan.

(advertentie)

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in