NOREA heeft op 23 september de Handreiking ICT-beveiligingsassessment DigiD 2026 gepubliceerd. De nieuwe versie verduidelijkt de reikwijdte van het assessment en scherpt verschillende technische toetscriteria aan. Voor organisaties met een DigiD-aansluiting vraagt dit vooral om inzicht in de volledige dienstverlening, duidelijke leveranciersafspraken en aantoonbare uitvoering van beveiligingsmaatregelen.
De handreiking 2026 moet worden gebruikt voor assessments met een onderzoeksdatum voor opzet en bestaan vanaf 1 oktober 2026. Het normenkader blijft bestaan uit 21 normen. Ook de vijf normen die op werking worden getoetst, blijven gelijk. De veranderingen zitten vooral in de scope, de uitwerking van de toetscriteria en de toepassing op moderne cloud- en ontwikkelomgevingen.
De volledige gebruikersreis bepaalt de scope
De nieuwe handreiking maakt explicieter dat het assessment betrekking heeft op de volledige gebruikersreis. Die begint bij het invullen van gegevens of bij de pagina met de DigiD-inlogmogelijkheid: het vroegste moment is bepalend.
Ook voorzieningen die deze gebruikersomgeving kunnen wijzigen of beïnvloeden, horen bij de scope. Denk aan beheeromgevingen, CI/CD-pipelines, cloudbeheer, toegangsbeheer, secrets, API’s, WAF, CDN en DNS. Uitbesteding of het opsplitsen van een applicatie in microservices verkleint de scope niet. Alle diensten achter hetzelfde aansluitnummer moeten worden meegenomen bij de afbakening.
Een nieuw beslismodel helpt om per onderdeel te bepalen of het binnen scope valt. Een bronsysteem dat uitsluitend gegevens levert, kan buiten scope blijven; het koppelvlak valt dan wel binnen scope. Daarbij hoeft niet ieder onderdeel aan alle 21 normen te worden getoetst. De auditor bepaalt welke normen relevant zijn.
Voor mobiele apps geldt een bijzondere situatie: de mobiele programmatuur valt volgens het beslismodel binnen scope, maar vooralsnog buiten de toetsingsverplichting. De relevante achterliggende systemen en koppelingen moeten wel worden getoetst.
Dagelijks scannen en sneller opvolgen
Een belangrijke aanscherping betreft kwetsbaarhedenbeheer. Waar de handreiking 2025 minimaal jaarlijkse vulnerability assessments beschreef, noemt de versie 2026 dagelijkse kwetsbaarheidsscans. Ook worden scans bij relevante merge requests en/of pipeline-deployments toegevoegd.
Voor de behandeling van kwetsbaarheden staan nu concrete termijnen in de handreiking:
5 werkdagen voor kritieke kwetsbaarheden op internet-facing componenten;
10 werkdagen voor kritieke kwetsbaarheden op niet-internet-facing componenten en voor hoge kwetsbaarheden;
1 maand voor kwetsbaarheden met een medium of lage classificatie.
Binnen die termijnen moeten kwetsbaarheden worden beoordeeld en, waar van toepassing, verholpen, gemitigeerd of aantoonbaar geaccepteerd. Dat vraagt om duidelijke eigenaars, opvolging en rapportage. Een risicoacceptatie betekent daarbij niet automatisch dat ook aan de afzonderlijke norm voor patchmanagement wordt voldaan.
Sterker beheer van toegang en wijzigingen
De handreiking stelt MFA expliciet verplicht voor kritieke infrastructuur. Alleen MFA op een beheer-VPN is onvoldoende wanneer kritieke componenten vervolgens zonder aanvullende sterke authenticatie toegankelijk zijn. Onder meer cloudbeheer, firewalls, hypervisors, back-upsoftware, Kubernetesbeheer en CI/CD-platformen worden genoemd.
Bij Infrastructure as Code voor beheermechanismen of platformconfiguraties wordt het vierogenprincipe expliciet gemaakt. Goedkeuringen, gescheiden rollen en beveiliging van branches moeten voorkomen dat wijzigingen ongecontroleerd naar productie gaan.
Aanvullende aandachtspunten richten zich op onder andere machine-identiteiten, noodaccounts, cloudmeldingen, beheerlogging en wijzigingen aan pipelines en cloudconfiguraties. Organisaties moeten beoordelen of hun bestaande beheerprocessen deze onderdelen voldoende afdekken.
Patchmanagement loopt door tot productie
De uitwerking van patchmanagement benoemt nu nadrukkelijk softwareafhankelijkheden, frameworks, container images, Kubernetes en PaaS-componenten. Alleen code of een image in een repository bijwerken is onvoldoende: de bijgewerkte onderdelen moeten aantoonbaar naar productie zijn uitgerold.
Ook wanneer een leverancier het platform beheert, blijft opvolging nodig. De dienstverlener moet de leverancier aanspreken op actualisatie. Voor specifieke situaties waarin dit objectief niet mogelijk is, beschrijft de handreiking een leveranciersverklaring over het niet-exploiteerbaar zijn van een kwetsbaarheid binnen de gebruikte dienstverlening en configuratie.
Meer aandacht voor de daadwerkelijke technische inrichting
Ook op andere technische onderwerpen verandert de uitwerking. De Content Security Policy wordt strikter: de eerdere uitzondering voor unsafe-inline bij gebruik van een nonce vervalt. Voor API’s zijn expliciete CORS-criteria toegevoegd.
Cloud-hardening, functionele netwerkzonering en het beperken van publieke toegang tot onderliggende cloudresources worden concreter beschreven. Architectuurdocumentatie moet de gebruikte diensten, onderlinge relaties en beveiligingsgrenzen inzichtelijk maken.
Pentests en configuratiecontroles moeten aansluiten op de relevante API’s en tussenlagen, zoals gateways, WAF en CDN. Bij testen op acceptatie moet de representativiteit voor productie aantoonbaar zijn.
Er is ook een versoepeling: TLS-instellingen met de classificatie ‘uit te faseren’ mogen nog worden gebruikt. De auditor moet daarbij wijzen op mogelijke toekomstige afkeuring. Een uitfaseerplanning blijft daarom verstandig.
Auditplanning en leveranciersrapporten vragen afstemming
De controleperiode voor werking blijft minimaal zes aaneengesloten maanden en hoeft niet op 31 december te eindigen. Bij een her-assessment op werking is opnieuw minimaal zes maanden nodig, gerekend vanaf het herstel van de tekortkoming. Dat kan grote gevolgen hebben voor de herstelplanning.
Daarnaast verduidelijkt de handreiking het gebruik van leveranciersrapporten, uitbestede user controls en versiegegevens bij Continuous Deployment. Een oudere handreikingversie bij een serviceorganisatie vereist niet automatisch een nieuw rapport. Hergebruik van een RSO blijft beperkt mogelijk, met een specifieke uitzondering na een her-assessment.
Ook de rapportage bij het ontbreken van relevante gebeurtenissen — non-occurrence — is verduidelijkt. De tijdelijke ENSIA-uitzondering voor toepassing van richtlijn 3000A is verwijderd; 3000D is het uitgangspunt.
Begin met scope, verantwoordelijkheden en bestaand bewijs
Voor organisaties is de eerste stap om samen met leveranciers en de auditor vast te stellen welke onderdelen worden geraakt. Controleer vervolgens welke maatregelen en bewijsstukken al beschikbaar zijn en waar aanvulling nodig is.
Niet iedere toevoeging is een nieuwe verplichting. NOREA vermeldt expliciet dat de afzonderlijke aandachtspuntenblokken praktische hulpmiddelen zijn en geen aanvullende normvereisten introduceren. Een zorgvuldige toepassing voorkomt onnodige auditlast.
Bij Cilde zien we hierin het belang van samenhangende compliance: verbind maatregelen aan de betrokken systemen, verantwoordelijken en bewijsstukken. Gebruik bestaand beleid en beheerbewijs waar dat toereikend is. Zo worden wijzigingen gericht opgepakt en blijft aantoonbaar wie waarvoor verantwoordelijk is.
Bron: NOREA Handreiking ICT-beveiligingsassessment DigiD 2026, versie 1.0 van 23 september 2026, vergeleken met versie 2025 van 29 augustus 2025.
