Skip to main content

NL-P-04P Part 1: PID Issuance & Lifecycle Management Requirements, Part 1

NL-P-04P Part 1: PID Issuance & Lifecycle Management Requirements, Part 1

Cover page of the document, as printed
Document referenceNL-P-04P (part1)
VersionRC1.0
StatusRelease Candidate Draft
Date01/11/2026
Document typeRequirements (PID Issuance & Lifecycle Management)
Parent frameworkNL-SYS-01 NL-P-P
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetPID Providers under the NL EUDI Wallet Certification System
Primary audiencePID Providers, CABs and Scheme Owners
Secondary audienceWallet Providers, Supervisory bodies, accreditation bodies and EUDI Wallet ecosystem stakeholders
Assurance levelHigh/High
How to read this page

This page summarises the document. Every statement points to the section and page of the authoritative PDF it comes from: click a reference such as §6.1, p. 10 to open that page. If this summary and the PDF differ, the PDF applies.

What this document is​

This specification addresses the initial issuance, the batch replenishment and the renewal of the PID, and establishes security requirements that the PID Provider must implement so that these processes meet eIDAS Assurance Level High as set out in CIR (EU) 2015/1502 (§1.1, p. 5). It is intended as a normative basis for conformity assessment of PID Provider solutions with respect to PID issuance and renewal processes, used by PID Providers for implementation and by CABs for audit and conformity assessment (§1.1, p. 5). The requirements are risk-based; a companion risk register documents the underlying risk analysis (§1.1, p. 5).

Scope and object of certification​

  • Covers requirements for the initial issuance and the renewal of the PID; the PID is treated as an object governed by the ARF state model (§1.2, p. 5).
  • Lifecycle events covered: PID Initial Issuance (to a Wallet Unit under sole control of the subject, from eligibility verification to the PID being stored and active); PID Batch Replenishment (silent, autonomous re-issuance of once-only Technical PIDs when stock falls below a threshold or attribute values change at the Authentic Source, without user action and without renewed identity proofing); PID Renewal (re-issuance near the end of validity, which "always requires renewed identity proofing") (§1.2, p. 5-6).
  • Out of scope: PID lifecycle events after issuance (revocation, expiry, deletion — covered in a separate specification); PID Provider organisational, security and policy requirements; PID data model; Authentic Source processes; Wallet Unit or Wallet Instance lifecycle; Relying Party requirements (§1.2, p. 6).
  • "PID" denotes the Logical PID unless a Technical PID is meant; a batch comprises multiple Technical PIDs of the same Logical PID (§1.1, p. 5). A Logical PID has no validity period or revocation status of its own; only its Technical PIDs do (§3.1, p. 8).
  • The Administrative Validity Period is the period during which the PID Provider may issue further batches of Technical PIDs of a Logical PID to a Wallet Unit without renewed identity proofing (§3.1, p. 8).

Who it applies to​

  • PID Provider: "A Member State authority or body, or a private entity designated by a Member State, that issues PID to Wallet Units" (§3.1, p. 8); it is "subject to the requirements applicable to assurance level High under Commission Implementing Regulation (EU) 2015/1502" (§4.2, p. 12). The requirements with own text place obligations on the PID Provider (e.g. ISS-5.1-01: "The PID Provider shall not issue a PID to a Wallet Unit that already holds an active Logical PID issued by that PID Provider.") (§5.1, p. 15).
  • CAB: shall assess not only individual controls but whether the processes collectively preserve the intended security properties, including whether an attacker with high attack potential could circumvent a control through an alternative process path (§4.1, p. 12); shall assess whether an end-to-end chain of assurance preserves assurance level High and sole control across issuance, replenishment, renewal and their interfaces with revocation, expiry and deletion (§4.2, p. 14).
  • Wallet Unit / Wallet Provider: the PID Provider verifies the Wallet Unit's Wallet Instance Attestation, issuer presence in the trusted list, Wallet Trust Evidence and key provenance (ISS-5.2-01 to ISS-5.2-05) (§5.2, p. 17-18); the Wallet Unit is responsible for deciding when to trigger out-of-cycle replenishment before an offline period (§6.3, p. 45).
  • The person (citizen / Wallet User): receives notifications through a channel independent of the Wallet Unit (ISS-5.7-05) (§5.7, p. 30) and may register contact methods (ISS-5.7-07) (§5.7, p. 31).
  • Authentic Source / authoritative population register: source of PID attributes; a PID is generated only from a complete and current attribute set (ISS-5.5-01) (§5.5, p. 26).

Contents​

  • 1 Introduction — foreword and scope (p.5).
  • 2 References — normative [1]-[7] and informative [i.1]-[i.5] (p.7).
  • 3 Terms & Abbreviations — terms (incl. Logical PID, Technical PID, Administrative Validity Period), abbreviations, modal verbs, notations, symbols (p.8).
  • 4 Relation to Resilience & High Assurance — resilience against high-attack-potential attackers, assurance level High and sole control (p.11).
  • 5 Lifecycle Event: PID Initial Issuance — pre-issuance eligibility, Wallet Unit verification, user identity verification (incl. identity proofing using a digital identity document), issuance request and authorisation, PID generation and signing, delivery, post-issuance status service registration (p.15).
  • 6 Lifecycle Event: PID Batch Replenishment — triggers and thresholds, batch request and issuance protocol, offline fallback, exhausted credential cleanup (p.39).
  • 7 Lifecycle Event: PID Renewal — triggers, re-identification, request and authorisation, generation and signing, delivery (p.47).
  • Annex A (informative) — PID State Diagram (p.51). Read
  • Annex B (informative) — Risk Register Cross-Reference (p.54). Read

Key points​

  • Sole control means the exercise of the PID and its bound cryptographic capabilities "requires the involvement or authorisation of the correctly identified citizen and cannot be exercised independently by another person, device, Wallet Unit, provider or intermediary" (§4.2, p. 13).
  • Renewal "shall not be treated as a mere extension of technical validity"; identity proofing is repeated at the assurance level required for initial issuance (§4.2, p. 14).
  • No PID to a Wallet Unit that already holds an active Logical PID from the same PID Provider (ISS-5.1-01) (§5.1, p. 15); no PID to a Wallet Unit of a Wallet Provider while the same person holds an active Logical PID in another Wallet Unit of that same Wallet Provider, unless those Technical PIDs are revoked per ISS-5.1-05 (ISS-5.1-04) (§5.1, p. 16).
  • Before issuance the PID Provider verifies a valid, unexpired, unrevoked Wallet Instance Attestation, its issuer on the trusted list, Wallet Trust Evidence for Assurance Level High, proof of possession of the binding key, and key provenance in a suitably certified device (ISS-5.2-01 to ISS-5.2-05) (§5.2, p. 17-18).
  • Guidelines state that in the Netherlands the unique identifier is the BSN obtained through the polymorphic pseudonym-derivation step of the eID scheme (§5.3.1, p. 19).
  • Identity proofing using a digital identity document [CONDITIONAL]: anti-cloning check via chip active authentication or equivalent; issuer signature validation against the country signing PKI; live chip read; status check where available; document PIN verified by the chip; recording and flagging of failed PACE/PIN attempts above a threshold (ISS-5.3-03 to ISS-5.3-12) (§5.3.2, p. 20-22).
  • Where contact methods are registered, issuance to a Wallet Unit that does not yet hold a Logical PID of that person requires entry of a one-time code sent to a registered contact method (ISS-5.4-04); such messages contain "no link, QR code, or telephone number to call" (ISS-5.4-05) (§5.4, p. 24-25).
  • PID attributes come from the authoritative population register (ISS-5.5-01); PID validity shall not exceed the national maximum PID lifetime or the validity of the Wallet Unit (ISS-5.5-07, ISS-5.5-08) (§5.5, p. 26-28).
  • A PID that has left the PID Provider's systems is classified as issued, and is revoked (not cancelled) if the Wallet Unit reports non-acceptance (ISS-5.6-04, ISS-5.6-05) (§5.6, p. 29).
  • The person is notified through a channel independent of the Wallet Unit when a PID is issued in their name (ISS-5.7-05) and when a request fails identity proofing or eligibility (ISS-5.7-05A) (§5.7, p. 30).
  • At first issuance the PID Provider collects a mobile number and an e-mail address as contact methods unless the person explicitly declines (ISS-5.7-20) (§5.7, p. 35).
  • Network origin or locality indicators of issuance or renewal requests are recorded where available to the PID Provider; network origin indicators are retained only for a risk-assessed period and used for no purpose other than fraud detection (ISS-5.7-13, ISS-5.7-26, ISS-5.7-27) (§5.7, p. 33; p. 37-38).
  • No replenishment after the Administrative Validity Period has ended (REP-6.1-02) (§6.1, p. 39); replenishment stops on a verified indication of loss of control (REP-6.1-05, REP-6.1-06) (§6.1, p. 40).
  • The PID Provider determines in its risk assessment a maximum batch size and maximum outstanding Technical PIDs per Wallet Unit and does not exceed them (REP-6.1-08, REP-6.1-09) (§6.1, p. 41).
  • Renewal requires identity verification at the initial-issuance assurance level (REN-7.2-01) and proof of possession of the private key of the existing PID binding public key (REN-7.3-03) (§7.2, p. 48; §7.3, p. 49).

Requirements in this document​

All 126 entries are listed one by one, with their text and PDF page, on the NL-P-04P Part 1 requirements page. You can also search them together with all other requirements.

  • NL-SYS-01 and NL-P-P (parent framework); related NL-P-01, NL-P-02, NL-P-03 (cover, p. 2).
  • Companion "PID Lifecycle Events Specification" [7] defining the PID revocation, expiry and deletion lifecycle events (§2.1, p. 7; Annex A, p. 51).
  • Normative references: [1] Regulation (EU) 2024/1183; [2] CIR (EU) 2015/1502; [3] CIR (EU) 2024/2977; [4] CIR (EU) 2024/2981; [5] ETSI TS 119 472-3 (issuance profile; e.g. CRED-REQ-PROC-4.6.2.1-0 for proof of possession); [6] ARF TS10; [7] PID Lifecycle Events specification (§2.1, p. 7; §5.2, p. 18).
  • Informative: [i.1] Regulation (EU) No 910/2014; [i.2] ARF Version 3.0.0 (2026-07-21) or later; [i.3] ETSI SR 001 262; [i.4] ISO 37003:2025 fraud control management; [i.5] PID Issuance Assessment Checklist "(to be issued)" (§2.2, p. 7).

Notes on this draft​

Sources​