Skip to main content

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

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

Download PDF (557 kB, 33 pages)Read the full text52 requirements
Cover page of the document, as printed
Document referenceNL-P-04P (part2)
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 lifecycle events of the PID after issuance — revocation by the PID Provider, expiry at the end of the validity period, and user-initiated deletion — and establishes security requirements that the PID Provider must implement so that PID lifecycle management meets eIDAS Assurance Level High per 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 lifecycle management, used by PID Providers for implementation and by CABs for audit and conformity assessment (§1.1, p. 5). Requirements are risk-based, with a companion risk register maintained as a separate deliverable (§1.1, p. 5).

Scope and object of certification​

  • Covers revocation, expiry and user-initiated deletion of the PID within the EUDI Wallet framework; the PID is treated as an object governed by the ARF state model (§1.2, p. 5).
  • Lifecycle events: PID Revocation (permanent invalidation of a PID by the PID Provider); PID Expiry (natural end of the validity period); PID Deletion (removal of a PID from the Wallet Unit at the initiative of the Wallet User) (§1.2, p. 6).
  • Out of scope: PID initial issuance and renewal (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 (an individual issued instance) is meant (§1.1, p. 5).
  • The document distinguishes revocation ("permanent and irreversible invalidation of one or more Technical PIDs by the PID Provider"), expiry ("natural end of the validity period of a Technical PID") and deletion ("removal of the PID and associated data and key material from the Wallet Unit at the initiative of the Wallet User") (§4.1, p. 11).

Who it applies to​

  • PID Provider: subject to assurance level High requirements of CIR (EU) 2015/1502 (§4.2, p. 12); the REV and EXP requirements place obligations on the PID Provider (e.g. REV-4.1-02 "The PID Provider shall revoke the outstanding Technical PIDs it has issued to a Wallet Unit when a revocation condition applies ..."; EXP-5.1-01 "The PID Provider shall detect, in its administration, when the validity period of a Technical PID has ended.") (§5.1, p. 13; §6.1, p. 25).
  • Wallet Unit: the DEL requirements are formulated as "The Wallet Unit shall ..." (DEL-6.1-01 to DEL-6.3-01) (§7, p. 29-30). The chapter NOTE states there are "no requirements on the PID Provider, only on the capabilities of the Wallet Unit and the on the Wallet Provider" for deletion (§7, p. 29).
  • Wallet Providers: receive notification from the PID Provider of a person's decease (REV-5.1-08) (§5.1, p. 15), forwarded revocation requests (REV-5.2-10) and forwarded loss/theft reports (REV-5.2-12) (§5.2, p. 19).
  • The person / Wallet User: can view an overview of every Wallet Unit holding a PID in their name after authentication at assurance level substantial or high, not via a Wallet Unit (REV-5.2-08); can report loss, theft or compromise without authenticating through a Wallet Unit (REV-5.2-11) (§5.2, p. 18-19).
  • CAB: shall assess the individual requirements and their combined effectiveness across the post-issuance lifecycle, including whether a high-attack-potential attacker could circumvent the intended outcome (§4.1, p. 11); shall assess whether the processes preserve assurance level High and continued sole control (§4.2, p. 12).

Contents​

  • 1 Introduction — foreword and scope (p.5).
  • 2 References — normative [1]-[9] and informative [i.1]-[i.3] (p.7).
  • 3 Terms & Abbreviations — terms, abbreviations, modal verbs, notations, symbols (p.8).
  • 4 Relation to Resilience & High Assurance — resilience of post-issuance processes; assurance level High and sole control (p.11).
  • 5 Lifecycle Event: PID Revocation — triggers and conditions, procedures, status service update, Wallet User notification (p.13).
  • 6 Lifecycle Event: PID Expiry — detection and notification, post-expiry behaviour, pre-deletion security measures, cleanup and deletion (p.25).
  • 7 Lifecycle Event: PID Deletion — user-initiated deletion, PID Provider notification, PID revocation (p.29).
  • Annex A (informative) — PID State Diagram, referring to Annex A of the PID Issuance specification (p.31). Read
  • Annex B (informative) — Risk Register Cross-Reference (p.32). Read

Key points​

  • Revocation triggers: reliable information that the Wallet Unit or its device is no longer under the legitimate user's control (REV-4.1-01); revocation conditions including loss of eligibility, decease, confirmed fraud or a substantiated request of the legitimate user (REV-4.1-02); revocation of the Wallet Unit (REV-4.1-05) (§5.1, p. 13-14).
  • An indication of a revocation condition is acted upon only after its reliability is established through a defined verification procedure (REV-4.1-03) (§5.1, p. 13).
  • On revocation, every outstanding Technical PID of the Logical PID issued to the Wallet Unit is revoked, including batch-replenished ones (REV-4.1-04), and the Administrative Validity Period is ended (REV-4.1-06) (§5.1, p. 14-15).
  • [CONDITIONAL] Where the authentic source provides event-driven notification of decease or loss of eligibility, the PID Provider subscribes to it for each person with an active Logical PID (REV-5.1-07) (§5.1, p. 15).
  • The maximum revocation time is set in the risk assessment and shall not exceed the maximum time for revoking an EAA in ETSI TS 119 471 clause 4.2.5.1 (REV-4.2-01, REV-4.2-02); revocation is completed within it (REV-4.2-03) (§5.2, p. 16).
  • A revoked Technical PID shall not be reinstated (REV-4.2-05) (§5.2, p. 17).
  • The PID Provider periodically verifies the validity status of each Wallet Unit holding non-terminal Technical PIDs, at a risk-assessed interval (REV-4.2-06, REV-4.2-07) (§5.2, p. 17-18).
  • Employee-initiated revocation takes effect only after approval by a second employee, both approvals recorded in a tamper-evident log, within a risk-assessed maximum time (REV-5.2-14 to REV-5.2-16) (§5.2, p. 20).
  • Each Technical PID includes the reference to its status mechanism, as required by ETSI TS 119 471 and the attestation format profile ETSI TS 119 472-1 (REV-4.3-01), and the identifier or index that distinguishes it within that mechanism, as required by ETSI TS 119 471 (REV-4.3-02) (§5.3, p. 20-21).
  • Revocation-status information need not be maintained for a Technical PID with a validity period of less than 24 hours, if stated in the PID provision policy (REV-4.3-04) (§5.3, p. 21).
  • The maximum delay to publish revoked status is risk-assessed and bounded by ETSI TS 119 471 clause 4.2.5.1 (REV-4.3-05 to REV-4.3-07) (§5.3, p. 22).
  • The Wallet User is notified of revocation through the government electronic mailbox (MijnOverheid Berichtenbox) and additionally through a registered contact method; the notification identifies the PID, the Wallet Provider and the Wallet Unit issuance date (REV-4.4-01, -02, -04, REV-5.4-05, -06) (§5.4, p. 23-24).
  • Expiry: the PID Provider detects the end of validity and stops treating the Technical PID as valid (EXP-5.1-01, -02); it notifies the Wallet User before the Administrative Validity Period ends, with risk-assessed advance time (EXP-5.1-03, -04) (§6.1, p. 25-26).
  • A Technical PID is not revoked solely because its validity period has ended, and revocation-status information need not be maintained after that (EXP-5.2-01, EXP-5.2-02) (§6.2, p. 26).
  • Expired Technical PIDs are removed per a defined cleanup procedure, with a risk-assessed retention period; audit and status records are kept until their retention period ends (EXP-5.4-01 to -03) (§6.4, p. 27-28).
  • Deletion: the Wallet Unit allows user-initiated deletion with confirmation, erases attribute data and key material irrecoverably, does not notify the PID Provider, and informs the Wallet User that deletion does not revoke the PID (DEL-6.1-01 to DEL-6.3-01) (§7.1-7.3, p. 29-30). The NOTE cites ARF requirement PAD_03 as prohibiting the Wallet Unit from notifying the PID Provider of a deletion (§7, p. 29).

Requirements in this document​

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

  • Format: "<the 3 to 5 letters identifying the lifecycle> - < the clause number> - <2 digit number – incremental>"; edition rules: next number at end, 00 at start, appended capital letters for insertions between existing requirements, "VOID" for deletions, capital 'X' for modifications (§3.4, p. 10).
  • Unmarked requirements apply to any EUDIW implementation; "[CONDITIONAL]" marks implementation-specific ones (§3.4, p. 10). One requirement is marked [CONDITIONAL]: REV-5.1-07 (§5.1, p. 15).
  • Prefixes (§3.4) and counts (counted in the PDF; 52 in total):
  • Guidelines and CAB verification: every requirement is followed by a "Guidelines" heading with dash-bullets, the last of which describes CAB verification (e.g. REV-4.1-01: "A CAB verifies that a reliable indication of lost control of the Wallet Unit or its device results in revocation of the Technical PIDs issued to it, for instance by tracing a sample indication through to revocation.") (§5.1, p. 13). All 52 requirements have such a section (counted in the PDF).
  • Annex B maps 21 risk IDs (between R-21 and R-67) to requirement IDs (Annex B, p. 32).
  • NL-SYS-01 and NL-P-P (parent framework); related NL-P-01, NL-P-02, NL-P-03 (cover, p. 2).
  • Companion PID Issuance specification [9] (Trust Agency, "PID Issuance Specification") defining the PID initial issuance, batch replenishment and renewal lifecycle events; its Annex A defines the PID lifecycle state model (§2.1, p. 7; Annex A, p. 31).
  • Normative references: [1] Regulation (EU) 2024/1183; [2] CIR (EU) 2015/1502; [3] CIR (EU) 2024/2981; [4] CIR (EU) 2024/2977; [5] ETSI TS 119 472-3; [6] ARF TS10; [7] ETSI TS 119 471 (revocation time limits, clause 4.2.5.1); [8] ETSI TS 119 472-1; [9] PID Issuance specification (§2.1, p. 7; §5.2, p. 16).
  • 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 (§2.2, p. 7).
  • ARF requirement PAD_03 (deletion not notified to PID Provider) (§7, p. 29).

Notes on this draft​

  • Requirement ID clause numbers do not match the printed chapter numbers: revocation requirements in chapter 5 use REV-4.x and REV-5.x (mixed within the same sections), expiry requirements in chapter 6 use EXP-5.x, deletion requirements in chapter 7 use DEL-6.x (§5-§7, p. 13-30).
  • Cross-references within requirements use the same ID numbering (e.g. REV-5.1-07 refers to REV-4.1-03; REV-5.4-05 refers to REV-4.4-01) (§5.1, p. 15; §5.4, p. 24).
  • Guidelines of the DEL requirements refer to "clause 6.3" (DEL-6.1-01, DEL-6.2-01) for the consequences of deletion for revocation and to "clause 6.1" (DEL-6.3-01) for the deletion itself; in the printed numbering these topics are §7.3 and §7.1 (§7.1, p. 29; §7.2, p. 30; §7.3, p. 30).
  • The deletion chapter NOTE refers to requirements "on the capabilities of the Wallet Unit and the on the Wallet Provider"; all DEL requirements are formulated as "The Wallet Unit shall ..."; the cover gives the certification target as PID Providers (§7, p. 29; §7.1-§7.3, p. 29-30; cover, p. 2).
  • Section 7.3 is titled "PID Revocation" and contains one requirement, on informing the Wallet User that deletion does not revoke the PID (DEL-6.3-01) (§7.3, p. 30).
  • Section 6.3 "Pre-Deletion Security Measures" contains EXP-5.3-01 on data retention after expiry (§6.3, p. 27).
  • The cover title is "PID Lifecycle Specification (part2)"; page footers read "PID Lifecycle Events Specification"; Part 1 refers to this document as [7] "PID Lifecycle Events Specification" (p. 1; p. 2-33; NL-P-04P-1 §2.1, p. 7).
  • Definitions include "Suspension" of a Wallet Unit; no suspension requirements appear in this document (§3.1, p. 9).
  • Annex A does not reproduce the state model and refers to Annex A of the PID Issuance specification (Annex A, p. 31).
  • The Colofon reads "v1.1" while the document version is RC1.0 (Colofon, p. 33; cover, p. 2).

Sources​