Netherlands restricts DigiD to European operator

The Dutch government will restrict operation of DigiD, the national identity platform serving roughly 16 million users, to a European-headquartered operator. The framing is digital sovereignty. The actual risk model has not changed. A single vendor running a single identity provider for an entire national population is the architectural condition. Jurisdiction is metadata. The attack surface is the platform.

DigiD is an identity provider. It issues authentication assertions consumed by thousands of relying parties: tax authority, healthcare, municipal services, education, pension administration. The trust chain is centralised by design. A relying party does not authenticate the user. It receives a signed assertion from DigiD claiming the user authenticated. Compromise the IDP, compromise every relying party that trusts it. The blast radius is the federation graph.

This is the Okta model. Okta is breached, every downstream tenant inherits the breach exposure. October 2023, Okta’s support case management system was accessed. Session tokens uploaded by customers for HAR file debugging were extracted. Attackers used those tokens to authenticate into customer Okta tenants. From the customer tenant, federated trust into Cloudflare, BeyondTrust, 1Password, anywhere the customer had configured SSO. MITRE T1199, trusted relationship. The IDP is the trust anchor. Compromising it laterally compromises everything downstream that delegated authentication to it. Single-vendor concentration is the precondition for this class of compromise. Not the vendor’s nationality.

Consider the failure modes for an IDP operator. The build pipeline. The signing keys used to sign SAML assertions and OIDC ID tokens. The session backplane that issues and validates session cookies. The admin plane that allows operators to modify trust relationships, attribute mappings, MFA enrolment. The directory store that holds user identifiers, credential hashes, recovery state. Any one of these compromised, the IDP is owned. Owned at the level where the assertion is forged at source, not bypassed at the relying party.

Forged assertions are difficult to detect. The relying party validates the signature against the IDP’s published key. The signature is valid. The assertion is structurally correct. The claimed user exists. There is no signal at the SP that distinguishes a legitimately-issued assertion from one signed by a stolen key. Detection requires correlation between IDP issuance logs and SP consumption, and that correlation only works if the attacker is not also inside the IDP logging plane. Golden SAML, T1606.002, is the technique. Documented since 2020. Used by APT29 in SolarWinds-adjacent intrusions, where assertions were forged with stolen ADFS signing material to access cloud resources under arbitrary identities.

What does the telemetry look like at the relying party. Nothing useful. The session opens. The user authenticates from a plausible IP, with a plausible user agent. The assertion validates. Authorisation proceeds. No SIEM rule fires because no rule exists for valid assertion from compromised IDP. The detection burden falls on the IDP operator. The operator must monitor signing key access, admin plane authentication, anomalous assertion patterns: issuance to user accounts with no preceding authentication event, assertions issued to relying parties the user has never accessed before, assertions issued outside a logged user session.

Now apply that to DigiD operating one IDP for 16 million users across thousands of relying parties. The signal-to-noise problem at the issuance plane is severe. Edge case behaviour blends with normal use. Detection engineering at this scale is a separate discipline from running an IDP. There is no public evidence that the operator selection process is weighted on detection capability.

The supply chain dimension is where the concentration multiplies. DigiD is software. That software has dependencies. Those dependencies have build pipelines. The pipelines run on CI infrastructure with credentials to sign and ship the artifacts that become the IDP runtime. T1195.002, compromise software supply chain. SolarWinds Orion. 3CX. XZ Utils. The pattern is established. The IDP runtime is downstream of every npm, Maven, NuGet, and container base image its build pulls. A European vendor does not change the global nature of those dependency graphs. The vendor’s headquarters is in jurisdiction. Its dependency tree is not.

The substitution problem is well understood. The xz backdoor in 2024, CVE-2024-3094, sat in liblzma for weeks before discovery. A maintainer-position compromise. Slow, social, deliberate. Any IDP runtime that built against any binary that linked liblzma was exposed. Nothing about that exposure is bounded by where the operator’s office is located. Dependency confusion attacks against internal package registries operate the same way, regardless of operator jurisdiction. A typosquatted PyPI package pulled into the build environment of a European vendor compromises that vendor’s pipeline as completely as it compromises any other.

Operator jurisdiction does help with one thing. Legal access. A non-European operator can be compelled by its home jurisdiction to produce data or grant access under legal process the Dutch government does not control. CLOUD Act exposure. FISA 702. Section 215 authorities prior to sunset. That is a real concern and it is a real reason to restrict operation to a European entity. But it is a legal-access problem, not an exploitation problem. Conflating the two produces the false comfort that compelled-access mitigation also addresses adversarial compromise. It does not. The SVR does not file a subpoena.

The architecture that actually reduces concentration risk is structural. Multiple independent IDPs with cryptographic separation. Hardware-rooted key custody so that a software compromise does not cascade into forged assertions. HSM-backed signing where the key never leaves the device and signing operations are rate-limited and audited per call. Detection at the relying party for anomalies that survive signature validation: geographic improbability, device posture deltas, session reuse from new ASNs, claim drift between assertions for the same principal across short intervals. None of these are achieved by selecting which entity gets the contract. They require designing the platform so that no single operator compromise compromises the federation.

The patch boundary here is not a CVE. There is no version number that crosses into safe. The boundary is architectural. A single IDP for a national population is a high-value target by design. The threat actors interested in it are the ones who break Okta, who maintain access to telecom infrastructure for years, who burn zero-days on identity systems because identity is the universal trust primitive. State-aligned services with five-year planning horizons. The economics of compromising a national IDP justify those actors’ resource allocation. Vendor selection does not change the target value.

What the operator change does is reset the operational baseline. A new operator inherits the existing architecture, the existing codebase, the existing trust relationships, the existing keys. Migration windows are exposure windows. Key custody handover is a documented attack surface. Any moment where a long-lived signing key is transferred between entities is a moment that key is reachable by more parties than the steady state. The cutover plan, the dual-running period, the trust republication to relying parties: each of these is a procedural step where adversarial activity can hide in legitimate change traffic.

For downstream relying parties the detection guidance is to treat the migration as a high-probability period for IDP-sourced anomalies. Increase scrutiny on session establishment events that follow assertion issuance. Correlate assertion claims against expected behaviour for the claimed principal. Treat any change to the IDP’s signing key set as a high-fidelity event requiring active verification, not silent re-trust. Rotate trust on a published schedule rather than accepting it through automated metadata refresh during the cutover. The relying party is the last layer of defence when the IDP is the threat vector. Default-trust posture toward a national IDP is a control gap, not a baseline assumption.

The technical reality is that this decision changes who holds the keys. It does not change how many keys there are, what they protect, or who wants them. Single-vendor identity infrastructure for 16 million users remains the same architectural risk regardless of the operator’s flag. The supply chain underneath that infrastructure remains globally entangled regardless of headquarters. Sovereignty over the operator is not sovereignty over the threat model. Treating it as such is the failure mode.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.