Skip to main content

NL-P-04W: EUDI Wallet Lifecycle Specification

NL-P-04W: EUDI Wallet Lifecycle Specification

Download PDF (3.5 MB, 124 pages)Read the full text201 requirements
Cover page of the document, as printed
Document referenceNL-P-04W
VersionRC1.0
StatusRelease Candidate
Date01/11/2026
Document typeRequirements (Wallet Onboarding & Lifecycle Management)
Parent frameworkNL-SYS-01 NL-P-W
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetWallet Providers under the NL EUDI Wallet Certification System
Primary audienceWallet Providers, CABs and Scheme Owners
Secondary audiencePID Provider, 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​

NL-P-04W addresses the lifecycle events of Wallet Instances and Wallet Units and establishes the security requirements that Wallet Providers must implement so that wallet onboarding and lifecycle management processes meet the required security level (§1.1, p. 6). It is intended as a normative basis for conformity assessment of EUDIW solutions with respect to wallet onboarding and lifecycle management, to be used by Wallet Providers for implementation and by CABs for conformity assessment (§1.1, p. 6). The requirements are risk-based, derived from legislation, reference frameworks and threat models; a companion risk register is maintained as a separate deliverable (§1.1, p. 6).

Scope and object of certification​

  • Defines the normative requirements for Wallet Providers for secure onboarding and lifecycle management of Wallet Instances and Wallet Units; it is "a subsidiary requirements specification under NL-P-W" (§1.2, p. 6).
  • "The object addressed by this specification is the Wallet Provider's onboarding and lifecycle-management service and its controlled interaction with the Wallet Instance, Wallet Unit, WSCA/WSCD, Wallet User, PID Provider and other relevant ecosystem parties" (§1.2, p. 7).
  • Lifecycle events in scope: Wallet Instance Installation; Wallet Unit Activation; Operational State (Without PID); PID Storage and Transition to Valid State; Wallet Unit Management and Maintenance; Device Change / Migration; Uninstallation; Revocation (Permanent) (§1.2, p. 7).
  • Out of scope: Wallet Solutions where more than one Wallet Instance per Wallet Unit can be active at the same time; PID Provider processes (identity verification and PID issuance); lifecycle events of the Wallet Solution (build, versioning, solution suspension and revocation); Wallet Solution-level organisational, policy, hardware, software and infrastructure requirements; EAA lifecycle events; Relying Party requirements; cross-Member-State interoperability (§1.2, p. 7).
  • A Wallet Instance is the software application installed on a Wallet User's device; a Wallet Unit is the personalised, Wallet User-bound instance of that software which has undergone activation and binding to the Wallet User's cryptographic material and identity (§1.1, p. 6). §3.1 defines a Wallet Unit as "A unique configuration of a Wallet Solution that includes one or more Wallet Instances, Wallet Secure Cryptographic Applications and Wallet Secure Cryptographic Devices, provided by a Wallet Provider to an individual Wallet User" (§3.1, p. 10).

Who it applies to​

  • Wallet Provider: must implement the requirements (§1.1, p. 6); 170 of the 201 requirements begin "The Wallet Provider shall" (counted), e.g. INST-5.1-01 (§5.1, p. 17).
  • Wallet Unit / Wallet Instance: some requirements are formulated for the Wallet Unit, e.g. "The Wallet Unit shall obtain the registration certificate of a PID Provider exclusively from the credential issuer metadata" (PID-8.1-01) (§8.1, p. 51); the specification defines controls that "the Wallet Provider and Wallet Unit shall apply at their side" of interactions with the PID Provider (§1.2, p. 7).
  • PID Provider: "Requirements allocated to the PID Provider remain outside the Wallet Provider's responsibility" (§1.2, p. 7). The Wallet Provider does not assume the PID Provider's responsibilities for identity proofing, identity verification or PID issuance (§4.2, p. 15).
  • CAB: the requirements "shall consequently be assessed both individually and in their lifecycle context"; the CAB shall evaluate whether the Wallet Provider's implementation maintains the required security properties across the applicable lifecycle transitions and whether alternative, exceptional and recovery paths introduce opportunities to bypass controls (§4.1, p. 15). The CAB shall assess the requirements from the high-assurance perspective; the assessment shall determine whether the lifecycle processes adequately protect against circumstances that could result in loss of control over the Wallet Unit, unauthorised use of the Wallet User's digital identity, or continued reliance on a Wallet Unit for which the required security conditions can no longer be assured (§4.2, p. 16). Each requirement's Guidelines include a bullet beginning "A CAB verifies", e.g. INST-5.1-01 (§5.1, p. 17).
  • Wallet User: e.g. must be given an explicit choice on creating a Migration Object during activation (ACT-6.7-01) (§6.7, p. 44) and a means to report suspected compromise without authenticating to the Wallet Unit (MON-13.1-03) (§13.1, p. 115).

Contents​

  • 1 Introduction — foreword and scope (p.6).
  • 2 References — normative [1]-[13] and informative [i.1]-[i.3] references (p.8).
  • 3 Terms & Abbreviations — terms, abbreviations, modal verbs, notations (identifier scheme), symbols (p.10).
  • 4 Relation to Resilience & High Assurance — rationale linking lifecycle requirements to resilience and to the assurance of the Wallet User's identity (p.14).
  • 5 Lifecycle Event: Wallet Instance Installation — distribution, device pre-checks, installation, user information and consent (p.17).
  • 6 Lifecycle Event: Wallet Unit Activation — WSCD/WSCA initialisation, WIA and Key Attestation issuance, binding, user account and authentication setup, Migration Object import and setup (p.28).
  • 7 Lifecycle Event: Operational State (Without PID) — non-PID use cases and preparedness for PID issuance (p.48).
  • 8 Lifecycle Event: PID Storage and Transition to Valid State — PID issuance request, binding to user identity verification, secure PID reception, storage, user activation of PID (p.51).
  • 9 Lifecycle Event: Wallet Unit Management and Maintenance — updates, re-authentication, key rotation, PID/EAA lifecycle, user support, backup and restore, security monitoring, data retention, trust anchor management (p.64).
  • 10 Lifecycle Event: Device Change / Migration — initiation, data transfer, new device verification, re-establishment, old device decommissioning and deletion, recovery when the source device is unavailable (p.85).
  • 11 Lifecycle Event: Uninstallation — user-initiated uninstallation, pre-uninstallation measures, data deletion, revocation and deregistration, verification of removal (p.97).
  • 12 Lifecycle Event: Revocation (Permanent) — triggers, procedures, impact on PIDs and attestations, data deletion (p.103).
  • 13 Monitoring and Fraud Management — general monitoring, state-specific inputs, application and web ecosystem monitoring, user warning channel (p.114).
  • Annex A (informative) — Lifecycle State Diagram (p.119). Read
  • Annex B (informative) — Risk Register Cross-Reference (p.121). Read

Key points​

  • Requirements are either applicable to any EUDIW implementation (no marking) or to specific implementations, marked "[CONDITIONAL]" (§3.4, p. 12). 17 requirements carry the [CONDITIONAL] marking (counted).
  • Modal verbs are interpreted per clause 23 of the ETSI Drafting Rules (§3.3, p. 12).
  • The Wallet Provider is not, as Wallet Provider, subject to CIR (EU) 2015/1502; "high assurance" here expresses the objective that onboarding and lifecycle processes "shall not introduce weaknesses that could materially undermine the assurance associated with the Wallet User's digital identity" (§4.2, p. 15-16).
  • The Wallet Provider shall sign the Wallet Instance software package (INST-5.1-01) and hold the private signing key in an HSM that requires multi-person authorisation for each signing operation and is certified to FIPS 140-3 Level 3, Common Criteria EAL4+, or an equivalent recognised level (INST-5.1-04) (§5.1, p. 17-18).
  • The Wallet Provider shall record every administrative action that modifies the Wallet Instance software package, the code-signing infrastructure or the distribution channel configuration, with operator identity and time, in a tamper-evident log retained for at least 12 months (INST-5.1-05) (§5.1, p. 19).
  • The Wallet Provider shall ensure that the Wallet Instance, at installation and at each subsequent launch, verifies that the OS version and security patch level meet the minimum requirements documented by the Wallet Provider, and refuses to activate Wallet Unit functionality on devices that do not (INST-5.2-01) (§5.2, p. 20).
  • The Wallet Provider shall ensure that all private keys attested in a Key Attestation and all private keys of device-bound PIDs and attestations are generated within the WSCD and never extracted from the WSCD in the clear (ACT-6.1-02) (§6.1, p. 28).
  • The Wallet Provider shall manage WIA and Key Attestation validity periods such that a non-revoked Wallet Unit can at all times present a WIA and a Key Attestation each with a remaining validity period of at least 31 days (ACT-6.2-09) (§6.2, p. 32).
  • The Wallet Provider shall ensure that at least one storage option offered for the Migration Object is EU based, under the Wallet User's exclusive control and not a location controlled by the Wallet Provider (ACT-6.7-05) (§6.7, p. 46).
  • The Wallet Provider shall ensure that the Wallet Unit accepts PID only after the PID Provider has confirmed, through identity proofing at Level of Assurance High as specified in CIR (EU) 2015/1502, that the Wallet User is the natural person to whom the PID data corresponds (PID-8.2-01) (§8.2, p. 52); before accepting a PID credential, the Wallet Unit shall verify that the PID Provider's signing certificate traces to a trust anchor published by the European Commission in the list of trusted entities applicable to PID Providers (PID-8.3-01) (§8.3, p. 55).
  • A revocation of a Wallet Unit, or establishment of a replacement Wallet Unit, carried out by support staff on behalf of a Wallet User takes effect only after a second member of staff has approved it (MAINT-9.5-06) (§9.5, p. 75); the maximum time for the second approval is determined as part of the risk assessment and shall be met (MAINT-9.5-08, MAINT-9.5-09) (§9.5, p. 76).
  • Documented periodic reviews of the security controls and procedures governing the Wallet Unit infrastructure at intervals not exceeding twelve months (MAINT-9.7-02) (§9.7, p. 81); the applicable trusted lists and lists of trusted entities shall be retrieved at intervals not exceeding 24 hours (MAINT-9.9-01) (§9.9, p. 82).
  • Any backup shall be encrypted before being stored or transmitted outside the Wallet Unit, using a password known only to the Wallet User (MAINT-9.6-02), and shall remain unreadable to the Wallet Provider and to the operator of any storage location offered or used (MAINT-9.6-04) (§9.6, p. 77).
  • The Wallet Provider shall ensure that migration is initiated solely by the Wallet User from the source Wallet Unit, without Wallet Provider authorisation, approval or notification as a precondition (MIG-10.1-01) (§10.1, p. 85); for recovery to a new device when the source device is unavailable (clause 10.7), identity proofing at the assurance level applicable to initial PID issuance is required before any PID credential is re-issued (MIG-10.7-02) (§10.7, p. 94).
  • Revocation is permanent and irreversible (§3.1, p. 11); a revoked Wallet Unit shall be disabled within a defined maximum timeframe (REV-12.2-02) (§12.2, p. 106), and the Wallet Provider shall document and enforce that maximum delay (REV-12.2-03) (§12.2, p. 107); WIA/KA revocation status shall be published within a defined and documented maximum period, in a status list that PID Providers and Attestation Providers can query without authenticated access (REV-12.3-01) (§12.3, p. 110).
  • The Wallet Provider shall treat a notice from the PID Provider of the decease of a Wallet Holder as a request under REV-12.1-03 for permanent revocation of the Wallet Unit (REV-12.1-08) (§12.1, p. 105).
  • Per the MON-13.1-01 guidelines, monitoring draws only on interactions the Wallet Provider receives; relying party interactions and credential presentations do not pass through the Wallet Provider and are not a monitoring input (§13.1, p. 114). The Wallet Provider shall maintain a push channel, independent of the Wallet Instance, for warning the Wallet User when compromise of the Wallet Unit is suspected (MON-13.4-01) (§13.4, p. 118).
  • Suspension and reactivation are not part of the lifecycle model; an untrusted Wallet Unit is revoked and recovery is by activating a new Wallet Unit (Annex A, p. 120).

Requirements in this document​

All 201 entries are listed one by one, with their text and PDF page, on the NL-P-04W 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>", e.g. INST-5.1-01 (§3.4, p. 12; §5.1, p. 17). Identifiers may be used in "the companion Assessment Checklist" (§3.4, p. 12).
  • Edition rules: insertion at end → next number; at start → 00; between → capital letters appended; deleted → "VOID"; modified → "the requirement number is amended by a capital 'X' letter" (§3.4, p. 12-13).
  • Prefixes defined in §3.4 and counts (counted in the PDF; 201 requirements in total):
    • INST — Wallet Instance Installation: 20 (5.1: 6, 5.2: 7, 5.3: 4, 5.4: 3) (§3.4, p. 12; §5, p. 17-27)
    • ACT — Wallet Unit Activation: 42 (6.1: 3, 6.2: 14, 6.3: 4, 6.4: 6, 6.5: 4, 6.6: 5, 6.7: 6) (§6, p. 28-47)
    • OPS — Operational State (Without PID): 5 (7.1: 3, 7.2: 2) (§7, p. 48-50)
    • PID — PID Storage and Transition to Valid State: 23 (8.1: 4, 8.2: 5, 8.3: 8, 8.4: 4, 8.5: 2) (§8, p. 51-63)
    • MAINT — Wallet Unit Management and Maintenance: 42 (9.1: 5, 9.2: 3, 9.3: 4, 9.4: 6, 9.5: 9, 9.6: 8, 9.7: 2, 9.8: 1, 9.9: 4) (§9, p. 64-84)
    • MIG — Device Change / Migration: 23 (10.1: 1, 10.2: 5, 10.3: 1, 10.4: 3, 10.5: 5, 10.6: 3, 10.7: 5) (§10, p. 85-96)
    • UNINST — Uninstallation: 14 (11.1: 4, 11.2: 2, 11.3: 5, 11.4: 1, 11.5: 2) (§11, p. 97-102)
    • REV — Revocation (Permanent): 22 (12.1: 8, 12.2: 8, 12.3: 3, 12.4: 3) (§12, p. 103-113)
    • MON — used in chapter 13 Monitoring and Fraud Management: 10 (13.1: 3, 13.2: 2, 13.3: 4, 13.4: 1) (§13, p. 114-118); MON is not listed in the §3.4 identifier table (§3.4, p. 12).
  • Guidelines and CAB verification: each requirement is followed by a "Guidelines" heading with dash-bullets; these typically explain the requirement, describe the risk ("Without this control, ..."), give "Acceptable approaches include ...", and end with a bullet "A CAB verifies this requirement by ..." describing review, sampling or testing activities, e.g. INST-5.1-01 (§5.1, p. 17). All 201 requirements have a Guidelines section containing exactly one bullet beginning "A CAB verifies" (counted).
  • Annex B maps risk IDs LR-001 to LR-051 from the companion risk register to requirement IDs (Annex B, p. 121-123).
  • NL-P-W: parent scheme; NL-P-04W is subsidiary to it (§1.2, p. 6; cover, p. 2). NL-SYS-01 is listed as parent framework (cover, p. 2).
  • Related: NL-P-01, NL-P-02, NL-P-03 (cover, p. 2). Organisational cyber-resilience and secure development / vulnerability management are "addressed elsewhere within the NL EUDI Wallet Certification System" (§4.1, p. 15).
  • Normative references: [1] Regulation (EU) 2024/1183; [2] CIR (EU) 2015/1502; [3] CIR (EU) 2024/2981; [4] ETSI EN 319 401; [5] ETSI TS 119 472-3; [6] ECCG Agreed Cryptographic Mechanisms; [7] European Digital Identity Framework Technical Specification TS10 "Data Portability and Download (Export)"; [8] ETSI TS 119 612 Trusted Lists; [9] ETSI TS 119 471; [10] IETF Token Status List; [11] ISO/IEC 18013-5; [12] CIR (EU) 2024/2979; [13] CIR (EU) 2024/2977 (§2.1, p. 8).
  • Informative: [i.1] Regulation (EU) No 910/2014; [i.2] ARF Version 3.0.0 (2026-07-21); [i.3] ETSI SR 001 262 drafting rules (§2.2, p. 9).
  • Companion deliverables mentioned: a risk register (§1.1, p. 6) and an Assessment Checklist (§3.4, p. 12).

Notes on this draft​

Sources​