Skip to main content

NL-P-01: Wallet and PID Provider Requirements

NL-P-01: Wallet and PID Provider Requirements

Download PDF (2.5 MB, 28 pages)Read the full text102 requirements
Cover page of the document, as printed
Document referenceNL-P-01
VersionRC1.0
StatusRelease Candidate Draft
Date01/11/2026
Document typeCommon requirements specification for Wallet Providers and PID Providers
Parent frameworkNL-SYS-01 NL-P-P/W
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetWallet Providers and PID Providers under the NL EUDI Wallet Certification System
Primary audienceWallet Providers, PID Providers, CABs and Scheme Owners
Secondary audienceSupervisory 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-01 specifies common organisational, technical, operational, security and resilience requirements for Wallet Providers and PID Providers participating in the NL EUDI Wallet Certification Scheme ("Stelsel") (§1.1, p. 5). Its structure follows ETSI EN 319 401 V3.2.1, with references to a Trust Service Provider or trust service adapted to the Wallet Provider, PID Provider and provider service context; the document does not claim that Wallet Providers or PID Providers are trust service providers solely because this structure is used (§1.1, p. 5). The requirements constitute subsidiary normative requirements for the Wallet Provider Certification Scheme (NL-P-W) and the PID Provider Certification Scheme (NL-P-P) (§1.2, p. 5).

Scope and object of certification​

  • The certified scope includes the provider organisation and the people, processes, information, infrastructure, cloud and hosting services, cryptographic services, interfaces, suppliers and operational controls used to provide wallet or PID services (§1.2, p. 5).
  • For the Wallet Provider this includes wallet onboarding, activation and wallet-unit lifecycle operations; for the PID Provider, identity proofing, PID issuance, binding, status, suspension, revocation and lifecycle operations (§1.2, p. 5).
  • Wallet Provider and PID Provider certifications are separate subordinate certifications; for a Wallet Provider these certificates form part of the assurance evidence for the top-level certification and national admission decision (§1.2, p. 5).
  • The document does not define the top-level certification decision, admission conditions, product-functional certification or wallet-solution cybersecurity certification (§1.2, p. 5).
  • Provider conformity is assessed as service certification under the NL EUDI Wallet Certification System (§4.1, p. 9).
  • "Certified scope" is defined as the provider role, services, locations, systems, processes, interfaces and outsourced activities covered by the provider certificate (§3.1, p. 8).

Who it applies to​

  • Wallet Provider: "the legal entity responsible for providing and operating the EUDI Wallet service and for the wallet-provider obligations allocated by NL-SYS-01 and NL-P-W" (§3.1, p. 8). It remains responsible for the secure provision and operation of wallet-related services and for maintaining valid assurance evidence for the wallet solution in scope (§4.1, p. 9).
  • PID Provider: "the legal entity responsible for identity proofing and issuing and managing PID for EUDI Wallet Units, including the PID-provider obligations allocated by NL-SYS-01 and NL-P-P" (§3.1, p. 8). It remains responsible for controlled PID issuance, status and lifecycle management, and the supporting trust and fraud-management services within its certified scope (§4.1, p. 9).
  • "provider": a Wallet Provider, a PID Provider, or both, according to the applicability of a requirement (§3.1, p. 8).
  • CAB: "shall be given sufficient architecture, service-decomposition and responsibility-allocation information to validate applicability decisions" (REQ-4.2-03) (§4.2, p. 9); incidents and vulnerabilities that may affect certified conformity shall be reported to the CAB (REQ-7.9-04) (§7.9, p. 20); the Provider shall ensure the CAB and competent authorities can obtain necessary evidence from outsourced activities (REQ-7.14-05) (§7.14, p. 24).
  • Scheme Owner: receives incident and vulnerability reports (REQ-7.9-04) (§7.9, p. 20); the termination plan addresses cooperation with the Scheme Owner and CAB (REQ-7.12-02) (§7.12, p. 23).
  • Applicant: shall identify the competent authority, applicable reporting obligations and any sector-specific cybersecurity requirements relevant to its certified services (§2.1, p. 6).

Contents​

  • 1 Introduction — foreword and scope (p.5).
  • 2 Legal Basis & References — legal instruments, normative references, parent documents, informative references (p.6).
  • 3 Terms & Abbreviations — keyword interpretation per ETSI drafting rules, terms, abbreviations, symbols (p.8).
  • 4 Overview — how chapters 4-7 transpose ETSI EN 319 401 control domains; general responsibilities; applicability of conditional requirements (REQ-4.2) (p.9).
  • 5 Risk management framework and risk assessment — REQ-5 requirements (p.10).
  • 6 Policies and practices — Provider Practice Statement, terms and conditions, information and network security policy (p.12).
  • 7 Provider management and operation — 14 control areas 7.1-7.14 from internal organisation to supply chain (p.14).
  • Annex A (informative) — Mapping to the eIDAS Regulation (p.26). Read
  • Annex B (informative) — Mapping to CIR 2024/2690 (p.28). Read

Key points​

  • Unless marked role-specific or conditional, each requirement applies to both provider roles and to all systems and outsourced services within their certified scope (§4, p. 9).
  • "Shall" identifies a mandatory certification requirement; keywords are interpreted per ETSI drafting rules; requirement identifiers are stable references for evaluation plans, evidence records, findings and certificates (§3, p. 8).
  • The Provider shall document, for every conditional or role-specific requirement, whether it applies and the factual basis (REQ-4.2-01); non-applicability shall not transfer, waive or obscure a responsibility (REQ-4.2-02) (§4.2, p. 9).
  • The Provider shall map its risk assessment to the system risk register maintained under NL-SYS-04 (REQ-5-04) (§5, p. 10).
  • The risk assessment shall address confidentiality, integrity, availability, authenticity, privacy and sole user control (REQ-5-03) and interfaces between Wallet Provider, PID Provider, wallet solution, WSCA/WSCD, trust services, access-certificate and registration-certificate services (REQ-5-05) (§5, p. 10).
  • Risks that may affect certificate validity, subordinate assurance evidence, national admission conditions or another provider shall be reported per NL-SYS-01 and the applicable provider scheme (REQ-5-08) (§5, p. 11).
  • The Provider shall maintain a Provider Practice Statement (the implementation of ETSI EN 319 401's Trust Service Practice Statement), approved by accountable management, version-controlled and reviewed at least annually and after material change (REQ-6.1-01, REQ-6.1-04) (§6, p. 12; §6.1, p. 12).
  • Terms and conditions shall be made available before service use (REQ-6.2-01); the Wallet Provider explains eligibility, onboarding, activation, recovery, suspension, termination and loss/compromise (REQ-6.2-03); the PID Provider explains PID issuance, validity, status, revocation, correction and user redress (REQ-6.2-04) (§6.2, p. 12-13).
  • Incompatible duties shall be segregated, including development and production administration and key activation and key use (REQ-7.1-04) (§7.1, p. 14).
  • Multi-factor authentication shall protect remote access, privileged access and access to security-critical systems (REQ-7.4-06) (§7.4, p. 16).
  • The PID Provider shall protect PID signing or sealing keys and associated status-service keys (REQ-7.5-05) (§7.5, p. 17).
  • Development, test, acceptance and production environments shall be appropriately separated (REQ-7.7-03) (§7.7, p. 18).
  • Incidents and vulnerabilities that may affect certified conformity, users, another provider or the trust framework shall be reported to the CAB, Scheme Owner and competent authorities within applicable deadlines (REQ-7.9-04) (§7.9, p. 20); each Provider shall additionally assess effects on the counterpart provider and the national trust framework (§7.9, p. 20).
  • The PID Provider shall assess systemic impact where an incident may affect multiple Wallet Providers or issued PIDs (REQ-7.9-08) (§7.9, p. 21).
  • The Provider shall maintain traceability from each requirement to implemented control, evidence source, owner, assessment result and open finding (REQ-7.10-04) (§7.10, p. 21).
  • Business impact analysis shall define maximum tolerable disruption, recovery priorities, RTOs and RPOs (REQ-7.11-02); continuity exercises shall include compromise or unavailability of a counterpart Wallet Provider or PID Provider (REQ-7.11-06) (§7.11, p. 22).
  • The Provider shall maintain a termination plan (REQ-7.12-01); the Wallet Provider plan addresses wallet suspension or migration, user access to records, and consequences for active wallet units (REQ-7.12-03); the PID Provider plan addresses continuity of PID validity status, revocation information, evidence retention and effects on all dependent wallets (REQ-7.12-04) (§7.12, p. 22-23).
  • The Provider shall conduct planned internal audits covering all requirements of the document and the applicable provider scheme (REQ-7.13-02) and notify material changes affecting the certified object, assurance evidence or certificate scope before implementation where the scheme requires (REQ-7.13-05) (§7.13, p. 23-24).
  • The Provider remains accountable for outsourced activities (REQ-7.14-05) and shall maintain exit and substitution plans for critical suppliers (REQ-7.14-07) (§7.14, p. 24-25).
  • Where national transposition or sector-specific rules impose more specific or stricter requirements, those prevail (§2.1, p. 6).
  • Annexes A and B are informative. Annex A is an aid to assessment that does not replace the legal text, and its mapping does not establish legal compliance by itself (Annex A, A.1-A.2, p. 26). Annex B is an assessment aid that neither determines whether a Provider falls within CIR 2024/2690 nor replaces the legal text, competent-authority supervision or a required conformity assessment (Annex B, B.1, p. 28).
  • For CIR 2024/2690, the Provider and CAB "should maintain one traceability matrix" linking each applicable provision to requirement identifiers, controls, owners and evidence (Annex B, B.1, p. 28).

Requirements in this document​

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

  • Format: REQ-<section>-<two-digit number>, e.g. REQ-4.2-01, REQ-5-01, REQ-7.14-07 (§4.2, p. 9; §5, p. 10; §7.14, p. 25).
  • Each requirement is a table row with four columns: Requirement ID, Normative requirement, Applies to, Typical evidence (§4.2, p. 9).
  • "Applies to" takes the values "Both", "Wallet Provider" or "PID Provider" (§4.2, p. 9; §5, p. 11). Counted in the document: 94 Both, 3 Wallet Provider (REQ-5-09, REQ-6.2-03, REQ-7.12-03), 5 PID Provider (REQ-5-10, REQ-6.2-04, REQ-7.5-05, REQ-7.9-08, REQ-7.12-04) (§5, p. 11; §6.2, p. 12-13; §7.5, p. 17; §7.9, p. 21; §7.12, p. 23).
  • "Typical evidence" is "Document review, interview and operating records" for all 102 requirements (§4.2-§7.14, p. 9-25).
  • No requirement in the tables is marked "conditional" in the Applies to column; the role-specific ones are the Wallet Provider and PID Provider rows above (§4.2-§7.14, p. 9-25).
  • Counts per section (102 in total): 4.2 Applicability of conditional requirements 3; 5 Risk management 10; 6.1 Provider Practice Statement 4; 6.2 Terms and conditions 4; 6.3 Information and network security policy 4; 7.1 Internal organisation 4; 7.2 Human resources 5; 7.3 Asset management 4; 7.4 Access control 7; 7.5 Cryptographic controls 5; 7.6 Physical and environmental security 4; 7.7 Operation security 8; 7.8 Network security 5; 7.9 Vulnerabilities and incident management 8; 7.10 Collection of evidence 4; 7.11 Business continuity management 6; 7.12 Provider termination and termination plans 5; 7.13 Compliance 5; 7.14 Supply chain 7 (§4.2-§7.14, p. 9-25).
  • Topics by section start page: 5 Risk management (p.10); 6.1 Provider Practice Statement (p.12); 6.2 Terms and conditions (p.12); 6.3 Information and network security policy (p.13); 7.1 Internal organisation (p.14); 7.2 Human resources (p.14); 7.3 Asset management (p.15); 7.4 Access control (p.16); 7.5 Cryptographic controls (p.17); 7.6 Physical and environmental security (p.17); 7.7 Operation security (p.18); 7.8 Network security (p.19); 7.9 Vulnerabilities and incident management (p.20); 7.10 Collection of evidence (p.21); 7.11 Business continuity management (p.21); 7.12 Provider termination and termination plans (p.22); 7.13 Compliance (p.23); 7.14 Supply chain (p.24) (TOC, p. 4).
  • Sections 7.2 to 7.14 each open with a statement that both provider roles "shall apply every ... requirement of ETSI EN 319 401 clause 7.x" (§7.2, p. 14; §7.4, p. 16; §7.9, p. 20; §7.14, p. 24); section 7.1 states that both provider roles "shall apply the organisational governance, reliability and segregation-of-duties requirements of ETSI EN 319 401 clause 7.1 within their respective certified scope" (§7.1, p. 14).
  • NL-SYS-01: read together; allocation of responsibilities; reporting of risks (§1.1, p. 5; §5, p. 10; §5, p. 11).
  • NL-P-W and NL-P-P: the applicable provider certification schemes, for which NL-P-01 is subsidiary normative content (§1.1, p. 5; §1.2, p. 5).
  • NL-P-W04* and NL-P-P04*: role-specific lifecycle and fraud-management requirements remain there (§1.1, p. 5).
  • NL-FS and NL-CS: product-functional and product-cybersecurity requirements remain there (§1.1, p. 5).
  • NL-SYS-04: system risk register to which the risk assessment is mapped (§5, p. 10).
  • Other NL-P* documents contain more specific requirements that apply in addition (§1.2, p. 5); cover lists NL-P-02, NL-P-03 and NL-P-P/W04* as related documents (cover, p. 2).
  • Standards: ETSI EN 319 401 V3.2.1 (2026-01) as the baseline for chapters 4-7; ISO/IEC 17065, 17067, 27001, 27002, 27005 (§2.2, p. 6). Informative: European Digital Identity Wallet Architecture and Reference Framework (§2.4, p. 7).
  • EU legal acts: Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183; CIR (EU) 2024/2982; CIR (EU) 2024/2979; CIR (EU) 2024/2977; CIR (EU) 2024/2981; CIR (EU) 2024/2690 (where in scope or adopted nationally); CIR (EU) 2015/1502 (§2.1, p. 6).
  • Annex A maps eIDAS Articles 5a, 5c, 5d, 5e, 10a, 13(2), 15, 19a, 24(2)(fb) and 24(2)(a)-(i) to chapters of this document (Annex A, A.2, p. 26-27); Annex B maps CIR 2024/2690 topics to chapters (Annex B, B.2, p. 28).

Notes on this draft​

  • Page footers read "NL-P-W | RC1.0" throughout instead of NL-P-01 (p. 2-28).
  • The history table has column headers Version, State and Date only; the change description in the row has no column header (history, p. 3).
  • Status on the cover is "Release Candidate Draft" while the history row says "Release Candidate"; history date 2026-10-31, cover date 01/11/2026 (cover, p. 2; history, p. 3).
  • §4.2 is titled "Applicability of conditional requirements", but no requirement in the tables is labelled "conditional" (§4.2, p. 9).
  • Heading "7.11.1 4.1 General" contains a stray "4.1" (§7.11, p. 22).
  • §2.3 lists parent documents as "NL-SYS-, NL EUDI Wallet Certification System.framework" and "NL-P- Provider certification schemes" (§2.3, p. 6).
  • Annex A refers to "Articles 19a and 24(2)(fb)" (Annex A, A.2, p. 27).

Sources​