31 October 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
DigiD Penetration Testing: What the Annual Logius Security Assessment Requires From Your Pentest
Every organisation with a DigiD connection must pass an ICT security assessment each year against the Logius norm, and a penetration test is a fixed part of that evidence. This guide explains how the norm is built, what the IT auditor expects from the tester, how scope and timing work, and what a DigiD-ready report contains.
What the DigiD security assessment is and who must undergo it
DigiD is the Dutch national authentication service for citizens, operated by Logius, an agency of the Ministry of the Interior and Kingdom Relations (BZK). Any organisation that lets citizens log in with DigiD runs a DigiD connection (aansluiting) with its own connection number. That population is wide: municipalities, provinces and water boards, executive agencies such as UWV, SVB and DUO, the Tax Administration, pension funds, health insurers, hospitals and other care providers with patient portals, and the software and hosting suppliers that operate those portals on their customers' behalf.
Since 2012, following a run of incidents at municipal websites and the DigiNotar certificate breach, Logius has required every DigiD connection to pass an annual ICT security assessment (ICT-beveiligingsassessment DigiD). The obligation follows from the DigiD connection terms and, since the Wet digitale overheid, from the legal framework for public digital identity. The assessment is performed against the Norm ICT-beveiligingsassessments DigiD, currently in its third major version (v3.0), which is derived from the NCSC ICT-beveiligingsrichtlijnen voor webapplicaties, the Dutch national guidelines for secure web applications.
The result is an assurance report issued by a Register EDP-auditor (RE) who is registered with NOREA, the Dutch professional body for IT auditors. The report states per norm whether the organisation complies. It is submitted to Logius every year. An organisation that fails norms must submit an improvement plan, and Logius can ultimately suspend or terminate a connection that remains non-compliant. The penetration test is the piece of technical evidence on which several of the norms rest, which is why the quality of the test determines the quality of the assessment.
How the norm is built: policy, implementation and control layers
The DigiD norm selects a subset of the NCSC web application guidelines and groups them in three layers. Knowing the layers tells you where the penetration test fits.
B norms: policy (beleid)
The policy layer asks whether security requirements for the DigiD application are defined and enforced: a security policy that covers the application, security requirements built into development and change management, and a documented division of responsibilities between the organisation, its suppliers and Logius. These norms are assessed on documents and interviews. The penetration test does not prove them, but a test report that references the policy and the release under test supports them.
U norms: implementation (uitvoering)
The implementation layer is the technical heart of the norm and is split into sub-domains: the web application itself (input and output validation, session management, authentication handling, error handling), the platform and web server (hardening, patching, TLS configuration, separation of environments), the network (segmentation, filtering, protection of management traffic) and access provisioning (how administrators reach the systems, multi-factor authentication on management interfaces). Most of these norms cannot be assessed from paper. The IT auditor relies on the penetration test and on configuration evidence to conclude whether they are met.
C norms: control (beheersing)
The control layer covers the processes that keep the application secure over time: vulnerability management, patch management, periodic penetration testing, logging and monitoring, and change management. The control norm on penetration testing is the one that makes the test mandatory in its own right: the application and its infrastructure must be tested periodically for vulnerabilities by a party independent of the teams that build and run them, findings must be followed up, and the test must cover the version that is actually in production.
What the auditor does with the test
The RE uses the report in two ways. First, as direct evidence for the control norm on penetration testing: was a test performed, by whom, on which scope, when, and were findings remediated. Second, as supporting evidence for the implementation norms: a report that shows no exploitable input validation flaws, correct session handling and a hardened TLS configuration supports a positive conclusion on those norms. A report that only lists scanner output supports neither.
The IT auditor and the penetration tester: two roles, one assessment
The assessment needs both. The auditor forms the opinion, the tester produces the technical evidence. Confusing the two, or hiring one party to do both, is a common reason assessments stall.
| Aspect | Register EDP-auditor (RE, NOREA) | Penetration tester |
|---|---|---|
| Appointed by | The organisation holding the connection, or the supplier for a TPM | The organisation or the supplier; must be independent of development and hosting |
| Works to | NOREA guidance for DigiD assessments and the NOREA assurance standard | NCSC web application guidelines, OWASP WSTG and ASVS, PTES, NIST SP 800-115 |
| Assesses | Design and existence of controls, and operating effectiveness where the norm requires it | Exploitable weaknesses in the DigiD connection, the application and the infrastructure |
| Delivers | Assurance report with a conclusion per norm, submitted to Logius | Penetration test report with findings, evidence, risk rating, remediation advice and retest |
| Timing | Fieldwork after remediation and retest, before the Logius deadline | Before the auditor's fieldwork, with time left for fixes and a retest |
| Reliance | May rely on the test report if scope, depth, independence and recency are adequate | Writes the report so the auditor can map each finding and each tested area to the norm |
What a DigiD-ready penetration test must cover
Scope is where most DigiD tests go wrong. The norm covers the entire chain from the citizen's browser to the data behind the login, not only the login page.
- The DigiD coupling itself: the SAML-based integration with DigiD, including assertion signature and audience validation, artifact handling, replay protection, assurance level handling and single logout, tested against the Logius pre-production environment with test accounts
- The web application behind the authentication: every function a citizen can reach after logging in, with attention to authorisation between citizens (direct object references on BSN-linked data), session management and business logic
- The infrastructure that serves the application: web servers, reverse proxies and web application firewalls, TLS configuration, DNS, management interfaces and the separation between production, acceptance and development environments
- The production environment, or an acceptance environment that is demonstrably identical in configuration, with the differences documented in the report
- The release that is live during the assessment period; a major release after the test means a retest of the changed components
- A named, independent tester with verifiable qualifications, a stated methodology and the exact test dates
- Findings mapped to the DigiD norm, so the auditor can trace each norm to evidence without re-interpreting the report
- A retest of remediated findings before the auditor closes fieldwork, with the retest results appended to the original report
TPM: when the supplier is assessed once for all its customers
Most municipalities, care providers and smaller public bodies do not build their DigiD portal themselves. They buy it as a hosted or SaaS product. If every customer's auditor assessed the same platform, the supplier would face dozens of identical assessments a year. The norm solves this with the Third Party Memorandum (TPM, derde-partijmededeling): the supplier commissions its own RE to assess the norms that fall within the supplier's responsibility and issues a TPM that every customer's auditor can rely on. The customer's RE then assesses only the norms that remain with the customer: policy, contract management, user and access management on the customer side, and any customer-specific configuration.
For the penetration test this means the supplier tests the platform once, at platform level, and the TPM documents that. Three things still go wrong regularly. First, period mismatch: the TPM covers a different twelve months than the customer's assessment, leaving a gap the customer's auditor cannot accept. Second, carve-outs: the TPM excludes components (an integration layer, a customer-managed reverse proxy, a document management system behind the portal) that the customer assumed were covered. Third, customisation: customer-specific forms, workflows or integrations that live outside the standard platform and were never in the supplier's test scope. Read the TPM's scope section before you plan your own test; whatever is not in it is yours to test.
Suppliers who serve municipalities and care providers at scale benefit from treating the TPM as a product feature: one well-scoped annual penetration test with a norm-mapped report, delivered to the supplier's RE on a fixed date, saves every customer a conversation and shortens every procurement. We regularly scope these platform-level tests so that the report serves both the TPM and the supplier's own ISO 27001 or NEN 7510 cycle.
Timing: planning the yearly cycle backwards from the Logius deadline
The assessment runs on an annual cycle per connection. Logius sets the submission deadline for the assurance report; historically that has been 1 May of the year following the assessment year, and municipalities submit through the ENSIA process, in which the DigiD assurance report accompanies the college statement. Check the current Logius planning for your connection, because deadlines and reporting formats have been adjusted between versions of the norm.
Plan backwards from that date. The auditor needs the retested report before fieldwork closes, typically in the first quarter. Remediation of medium and high findings on a public-facing portal usually takes four to eight weeks once development and hosting teams are aligned, and the retest follows that. That puts the penetration test itself in the third or fourth quarter of the assessment year, on the release that will be live at the time of the assessment. Organisations that test in January to satisfy a May deadline routinely end up with open findings in the assurance report.
New connections have their own first-assessment timeline, agreed with Logius at onboarding. A penetration test before go-live is the sensible way to meet it, because a portal that fails on day one has to be fixed in production, in public, under time pressure.
Common findings in DigiD penetration tests, and how we test
Over years of testing DigiD-connected portals for municipalities, care providers and their suppliers, the same categories of finding recur. On the connection: assertions accepted without strict audience and recipient checks, single logout that ends the DigiD session but leaves the application session alive, and assurance levels not enforced on sensitive functions. On the application: insecure direct object references that expose another citizen's data by changing an identifier, session cookies without Secure, HttpOnly and SameSite attributes, missing or permissive Content Security Policy, verbose error messages revealing stack traces or framework versions, and rate limiting absent on functions that take a BSN. On the infrastructure: legacy TLS protocols and cipher suites still enabled, missing HSTS, management interfaces reachable from the internet without multi-factor authentication, and outdated components with known vulnerabilities. Almost all of these map directly to an implementation norm, which is why they appear in the assurance report as a failed norm rather than a technical footnote.
A HackersHub DigiD penetration test is scoped per connection number, covers the coupling, the application and the infrastructure, and is executed against the Logius pre-production environment where the coupling is concerned and against production or an identical acceptance environment for the rest. The lead tester is OSCP-certified and named in the report. Every finding carries evidence, reproduction steps, a risk rating with the business context of a public-facing portal, and a reference to the DigiD norm it affects. The retest is part of the engagement, and we coordinate the delivery date with your RE so the assurance fieldwork can proceed without follow-up questions.
Frequently asked questions
Preparing for your DigiD assessment?
We scope the test per connection, cover the coupling, the application and the infrastructure, map every finding to the Logius norm and coordinate the delivery with your IT auditor. Talk to an expert.