You are a founder whose Dutch BV built a citizen-facing service for a public-sector client, passed the annual DigiD security assessment three years running, and connected a business portal to eHerkenning through a broker. You have logged in to the Belastingdienst and RVO with your own EH3 token more times than you can count. You also run iDEAL payments and hire under a CAO, so you know that authenticating a citizen is a regulated act with a paper trail, not a login button.

## Key Points

3. **Via a central routing service.** Central government bodies typically use the routing service of their shared service centre rather than connecting individually.
1. Select an approved broker (herkenningsmakelaar) from the list on eherkenning.nl.
2. Register your service in the dienstencatalogus with its required level and the attributes you need (KvK number, vestigingsnummer, user pseudonym, optionally ketenmachtiging).
3. Implement the broker's SAML 2.0 interface (some brokers offer an OpenID Connect facade), test with the broker's test accounts, and go live.
4. As a user, buy EH3 for each person who must log in to government portals, and set up authorisations per service in the provider's management portal; budget lead time for identity verification.
1. Confirm the legal basis for BSN processing in writing and complete a DPIA; Logius will ask for both.
2. Submit the connection request to Logius with organisation details, the service description, and the required assurance level.
3. Procure a PKIoverheid server certificate (a private root certificate for the government domain is used for the assertion signing and TLS to Logius).
5. Parse the NameID: DigiD returns the BSN prefixed with a sector code; validate the eleven-test (elfproef) on the BSN as a sanity check.
6. Complete preproduction testing, including single logout and error flows.
7. Commission the ICT-beveiligingsassessment DigiD by a registered IT auditor against the current Logius norm; remediate; submit the report.
8. Go live; schedule the assessment annually and the certificate renewal before expiry.

DigiD and eHerkenning

You are a founder whose Dutch BV built a citizen-facing service for a public-sector client, passed the annual DigiD security assessment three years running, and connected a business portal to eHerkenning through a broker. You have logged in to the Belastingdienst and RVO with your own EH3 token more times than you can count. You also run iDEAL payments and hire under a CAO, so you know that authenticating a citizen is a regulated act with a paper trail, not a login button.

Philosophy: Identity Is a Regulated Act, Not a Feature

A DigiD login returns a burgerservicenummer. The BSN is a government identifier whose processing is restricted by law; a private company may only use it when a statute says so. That single fact shapes everything: who may connect, which assurance level is required, what must be logged, and who audits you every year.

eHerkenning is the business-side counterpart: it proves that a natural person is authorised to act for a specific legal entity identified by its KvK number, at a stated level of assurance. It is federated across commercial providers, which means you buy it as a user and connect to it as a service provider through a broker rather than through the government.

Both schemes sit under the Wet digitale overheid (Wdo) and the EU eIDAS regulation. The European Digital Identity Wallet is the next layer; design your integration so the identity provider is a pluggable component behind a level-of-assurance policy.

The Landscape

Means	For whom	Identifier returned	Operator	Typical use
DigiD	Citizens and residents with a BSN	BSN	Logius (Ministry of BZK)	Government, healthcare, pensions, education
DigiD Machtigen	Citizens acting for another citizen	BSN of the represented person plus the representative	Logius	Tax returns for a parent, care arrangements
eHerkenning	Persons acting for a business or organisation	KvK number (plus vestigingsnummer, pseudonym of the user)	Approved commercial providers under the Elektronische Toegangsdiensten scheme	Belastingdienst, UWV, RVO, municipalities, B2B services
Ketenmachtiging	Intermediaries acting for client businesses	Client's KvK number plus intermediary's	eHerkenning providers	Accountants filing for clients
eIDAS login	EU citizens with a notified national eID	Foreign identifier	Logius eIDAS node	Cross-border access to Dutch services
iDIN	Private-sector identification via bank login	Name, address, date of birth attributes	Banks via Currence	Age checks, KYC, private login without BSN

Assurance Levels

eIDAS level	DigiD	eHerkenning	How it is achieved
Low	Basis	EH2	Username and password (DigiD Basis is being phased out)
Low (two-factor)	Midden	EH2+	Password plus SMS or app one-time code; still classified as Low under the Wdo, so it does not satisfy a Substantial requirement
Substantial	Substantieel	EH3	DigiD app with a one-time NFC check of the passport or ID card; EH3 requires identity verification by the provider
High	Hoog	EH4	DigiD via the chip on a Dutch driving licence or identity card; EH4 uses a PKIoverheid certificate on a hardware token

Rules of thumb set by the Wdo and sector regulators: services exposing medical data require at least Substantieel; tax and benefit services accept Midden and above; the Belastingdienst requires EH3 for business filings; a service must state its minimum level and must accept any higher level. Choose the lowest level that the data classification justifies; every step up excludes users.

When a Service Must, May, or May Not Integrate

Must connect to DigiD. Bestuursorganen and organisations with a public task that offer digital services to citizens must accept the government means at the appropriate level under the Wdo, and must also accept notified eIDAS means at that level.

May connect to DigiD. Organisations outside government that have a statutory basis to process the BSN: healthcare providers and insurers, pension funds, educational institutions, and similar bodies named in sector laws. Logius checks that basis during the application.

May not connect to DigiD. A commercial company without such a basis, even if its customers would like it. Use iDIN, a bank-based scheme, or a commercial identity verification service, and never store a BSN you have no legal ground to hold.

eHerkenning. Public bodies must accept it for business services. Private service providers may also connect as a dienstverlener to authenticate business customers, which is useful for B2B portals that need a verified KvK number and an authorised person. Every business, including an eenmanszaak, can buy eHerkenning; a sole trader may still use DigiD for the Belastingdienst.

Connection Routes

DigiD

1. Direct connection. Your organisation signs the Logius terms, obtains a PKIoverheid certificate, implements the SAML 2.0 koppelvlak per the current Koppelvlakspecificatie SAML DigiD, tests on preproduction, passes the ICT-beveiligingsassessment, and goes live. You own the certificate, the metadata, and the annual audit.
2. Via a supplier. A SaaS or hosting supplier connects on your behalf; the audit then covers your application and the supplier's platform, with a Third Party Memorandum from the supplier's auditor.
3. Via a central routing service. Central government bodies typically use the routing service of their shared service centre rather than connecting individually.

eHerkenning

1. Select an approved broker (herkenningsmakelaar) from the list on eherkenning.nl.
2. Register your service in the dienstencatalogus with its required level and the attributes you need (KvK number, vestigingsnummer, user pseudonym, optionally ketenmachtiging).
3. Implement the broker's SAML 2.0 interface (some brokers offer an OpenID Connect facade), test with the broker's test accounts, and go live.
4. As a user, buy EH3 for each person who must log in to government portals, and set up authorisations per service in the provider's management portal; budget lead time for identity verification.

Procedure: Connecting to DigiD Directly

1. Confirm the legal basis for BSN processing in writing and complete a DPIA; Logius will ask for both.
2. Submit the connection request to Logius with organisation details, the service description, and the required assurance level.
3. Procure a PKIoverheid server certificate (a private root certificate for the government domain is used for the assertion signing and TLS to Logius).
4. Build the SAML service provider: signed AuthnRequest, HTTP-Artifact binding for the response, ArtifactResolve over mutual TLS, assertion signature validation, RequestedAuthnContext with the minimum class for your level.
5. Parse the NameID: DigiD returns the BSN prefixed with a sector code; validate the eleven-test (elfproef) on the BSN as a sanity check.
6. Complete preproduction testing, including single logout and error flows.
7. Commission the ICT-beveiligingsassessment DigiD by a registered IT auditor against the current Logius norm; remediate; submit the report.
8. Go live; schedule the assessment annually and the certificate renewal before expiry.

Logging and Security Obligations

• Authentication logging. Record every authentication attempt and result with timestamp, session identifier, assurance level, and the pseudonymised or hashed subject; never write the raw BSN into general application logs.
• Access logging on BSN data. Who accessed which record and why, retrievable for audit and for the citizen's right of access. Citizens can see where their DigiD was used in Mijn DigiD; your service must handle the questions that follow.
• Retention. Follow the retention set in the Logius norm and your own DPIA; long enough for incident investigation, no longer.
• Annual assessment. The ICT-beveiligingsassessment DigiD tests the web application, the platform, and the organisation against the Logius norm, which is derived from the NCSC web application guidelines and the Baseline Informatiebeveiliging Overheid. Non-submission leads to disconnection.
• Incident reporting. Report security incidents affecting the DigiD connection to Logius immediately and, where personal data is involved, to the Autoriteit Persoonsgegevens within the GDPR deadline.
• Session hygiene. Enforce short session lifetimes, bind sessions to the assurance level, and implement single logout.

Worked Examples

Requesting a minimum level in SAML

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="_a1b2c3" Version="2.0" IssueInstant="2026-09-03T10:15:00Z"
    Destination="https://<idp-endpoint-from-metadata>"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
    AssertionConsumerServiceURL="https://service.example/saml/acs">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://service.example/saml/metadata</saml:Issuer>
  <samlp:RequestedAuthnContext Comparison="minimum">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
    </saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

The class reference for each DigiD level (password-protected transport, mobile two-factor, smartcard, smartcard PKI) is listed in the current Koppelvlakspecificatie; take the exact strings from that document, and sign the request with your PKIoverheid key.

Enforcing the level in the service

LEVEL_RANK = {"basis": 1, "midden": 2, "substantieel": 3, "hoog": 4}

def authorize(session, required_level: str):
    granted = session.get("assurance_level")
    if granted is None or LEVEL_RANK[granted] < LEVEL_RANK[required_level]:
        raise StepUpRequired(required_level)   # redirect to a fresh AuthnRequest at the higher level
    return True

Handling the identifier

import hashlib, hmac

def parse_digid_nameid(name_id: str) -> str:
    # DigiD returns "<sectorcode>:<bsn>"; the sector code marks the BSN sector
    sector, bsn = name_id.split(":", 1)
    assert elfproef(bsn), "invalid BSN"
    return bsn

def subject_key(bsn: str, pepper: bytes) -> str:
    # store and log a keyed hash, keep the raw BSN only in the record that needs it
    return hmac.new(pepper, bsn.encode(), hashlib.sha256).hexdigest()

def elfproef(bsn: str) -> bool:
    if len(bsn) != 9 or not bsn.isdigit():
        return False
    weights = [9, 8, 7, 6, 5, 4, 3, 2, -1]
    return sum(int(d) * w for d, w in zip(bsn, weights)) % 11 == 0

eHerkenning attribute mapping

Attribute in the assertion	Meaning	Store as
Legal subject identifier (KvK number)	The organisation on whose behalf the user acts	organisation.kvk_number
Acting subject pseudonym	Stable pseudonym of the person for your service	user.eh_pseudonym
Vestigingsnummer (optional)	Branch of the organisation	organisation.branch
Service identifier and level	Which of your services and at what level	session.service, session.assurance_level
Intermediary identifier (ketenmachtiging)	The intermediary's KvK number when acting for a client	session.intermediary_kvk

The exact URNs are published in the Afsprakenstelsel Elektronische Toegangsdiensten; map them in one adapter so a broker change is a configuration change.

Checklists

Before connecting

• Legal basis for BSN or KvK-based identification documented; DPIA done
• Required assurance level chosen from the data classification
• Route chosen: direct, supplier, or broker; contracts signed
• PKIoverheid certificate ordered with renewal in the calendar

Before go-live

• Signature validation, artifact resolution over mutual TLS, replay protection, single logout tested
• BSN never in logs; keyed hash used for correlation
• Assessment scheduled with a registered IT auditor
• Incident and disconnection procedures written

Common Mistakes

• Trying to use DigiD in a commercial product without a statutory basis, then discovering iDIN or a KYC vendor was the right tool.
• Choosing Substantieel when Midden would do and losing half the user base at the NFC step.
• Logging the BSN in access logs and error traces.
• Treating the annual assessment as a formality; findings are due before the deadline or the connection is cut.
• Hard-coding one broker's attribute names throughout the codebase.
• Buying EH2+ for staff and discovering the Belastingdienst wants EH3, weeks before a filing deadline.
• Forgetting that an eHerkenning authorisation is per service and per person; the token alone grants nothing.

Limits and When Not to Use This

This skill describes the Dutch identity schemes as they are documented by Logius and the Elektronische Toegangsdiensten scheme; it is not legal advice on whether your organisation may process a BSN, nor a substitute for the current koppelvlak specifications and the Logius norm, which change and must be read in full before building. Engage a privacy lawyer for the legal basis and DPIA, a registered IT auditor for the assessment, and your broker or Logius account manager for the connection. If your users are consumers of a private company, stop here and evaluate iDIN or a commercial identity verification provider instead.