Skip to main content

NL-P-03: Secure Software Development & Vulnerability Management Practices for Wallet and PID Providers

NL-P-03: Secure Software Development & Vulnerability Management Practices for Wallet and PID Providers

Download PDF (2.8 MB, 75 pages)Read the full text122 requirements
Cover page of the document, as printed
Document referenceNL-P-03
VersionRC1.0
StatusRelease Candidate Draft
Date01/11/2026
Document typeSecure Software Development and Vulnerability Management Practices
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-03 translates a lifecycle perspective on secure software development, secure maintenance and vulnerability management into requirements and guidance for Wallet Providers and PID Providers operating under the NL EUDI Wallet Certification System (§1.1, p. 4). It complements NL-SYS-01 by defining practices for product cybersecurity risk management, secure development and maintenance, third-party component governance, verification and validation, monitoring, coordinated vulnerability disclosure, remediation, security updates and secure decommissioning (§1.1, p. 4). It shall be read together with NL-SYS-01 and the applicable Wallet Provider and PID Provider certification schemes (§1.1, p. 4).

Scope and object of certification​

  • Applies to the software and related processes used to develop, build, test, release, operate, maintain and decommission EUDI Wallet mobile applications and the Remote Data Processing Solutions (RDPS), interfaces, build and distribution services, and third-party components on which those applications depend (§1.2, p. 4).
  • Covers product cybersecurity risk management; cybersecurity planning and requirements; architecture and design; secure implementation; technical documentation and SBOMs; verification and validation; secure production and distribution; monitoring and issue management; third-party component management; coordinated vulnerability disclosure; remediation; security updates; secure decommissioning (§1.2, p. 4).
  • The requirements apply throughout the support period and shall be revisited when the product, its dependencies, operational environment, threat landscape or legal and technical requirements change (§1.2, p. 4-5).
  • "Secure maintenance" and "vulnerability management" are defined in §1.2 (vulnerability management includes intake, triage, risk evaluation, coordination, disclosure, remediation, testing, release and post-release monitoring) (§1.2, p. 5).
  • The document does not replace functional, organisational or product-security requirements of EUDI Wallet legislation, implementing acts, EU cybersecurity certification schemes or NL schemes, does not establish whether the CRA or national NIS2 legislation applies, and does not prescribe all security properties of the wallet solution itself (§1.2, p. 5).

Who it applies to​

  • Wallet Providers and PID Providers within the NL EUDI Wallet Certification System (§1.1, p. 4; §1.2, p. 4).
  • "Requirements apply to the relevant provider or manufacturer within the scope assigned by the applicable certification scheme" (§3.2, p. 9).
  • Applicant: shall identify the competent authority, applicable reporting obligations and sector-specific cybersecurity requirements (§2.1, p. 6).
  • "Responsible economic operator": where the CRA applies, must separately establish the applicable CRA obligations, conformity-assessment route, technical documentation, reporting duties and market-surveillance requirements (§3.2, p. 9).

Contents​

  • 1 Introduction — foreword and scope (p.4).
  • 2 Legal Basis & References — legal basis, normative references, parent & related documents, informative references (p.6).
  • 3 Relationships with NIS2, CRA — how the document links eIDAS, NIS2 and CRA lifecycle and vulnerability-handling principles (p.8).
  • 4 Product Cybersecurity Risk Management — product context, risk acceptance criteria, asset identification, risk identification, analysis, evaluation and acceptance, treatment, communication, review (p.10).
  • 5 Product Cybersecurity Lifecycle Activities — planning, requirements, architecture and design, secure implementation, technical documentation (SBOM), verification and validation, secure production and distribution, monitoring and issue management, secure decommissioning, third-party components (p.25).
  • 6 Vulnerability Handling — operational security, facilities, coordinated vulnerability disclosure facilities, intake, stakeholder communication, remediation, release of security updates and information (p.55).
  • "2 Colofon" — author and source-document metadata (p.71).
  • Annex - Requirements overview — short key text of each requirement, per clause (p.72).

Key points​

  • The document is informed by Regulation (EU) No 910/2014 as amended by 2024/1183, NIS2, the Cyber Resilience Act (Regulation (EU) 2024/2847), the EUDI Wallet implementing acts and relevant standards; references to the CRA "express alignment with its lifecycle and vulnerability-handling principles" and do not, by themselves, determine whether a specific wallet component, provider or service falls within the legal scope of the CRA (§1.1, p. 4).
  • It "adopts the CRA's lifecycle logic as a state-of-the-art baseline" for the NL system (§3.2, p. 9). CRA alignment is not a parallel certification route, and NL certification does not automatically demonstrate CRA conformity (§3.2, p. 9).
  • Change, vulnerability and remediation records "shall ... feed the applicable surveillance, change-notification, incident-management and certificate-maintenance processes" defined by NL-SYS-01 and the provider and product schemes (§3.2, p. 9).
  • Mandatory requirements and non-mandatory guidance are distinguished; guidance does not create an obligation unless incorporated by a normative requirement or another legal or scheme provision (§3.2, p. 9).
  • Risk management consists of six interconnected activities: product context, risk acceptance criteria, risk assessment, risk treatment, communication of residual risks, monitoring and review (§4.1, p. 10).
  • Where the product includes RDPS, the RDPS is included in the product context (5.2-CR-02) (§4.2, p. 11).
  • The product shall be developed and maintained using a secure development environment; this shall be demonstrated by including the development environment in the scope of the provider’s Information Security Management System certified against ISO/IEC 27001 by an accredited certification body (6.5-CR-01) (§5.5, p. 29).
  • A documented secure coding standard shall be adopted and enforced (6.5-CR-03); a process shall be established for identifying, reviewing and approving the use of memory-unsafe programming languages or constructs, documenting the rationale and compensating controls where their use cannot be avoided (6.5-CR-04) (§5.5, p. 29-30).
  • Cryptographic mechanisms shall reflect the state of the art; where no specific reference is designated, the ECCG "Agreed Cryptographic Mechanisms" (ACM) shall be used as the baseline (6.5-CR-06) (§5.5, p. 30-31). Keys shall be protected through secure hardware modules, or secure software modules if hardware is not feasible (6.5-CR-07) (§5.5, p. 32).
  • A revised SBOM shall be issued for each new build or release or when an inaccuracy is found (6.6-CR-03) (§5.6, p. 35).
  • A process shall be established for selecting, configuring and maintaining SAST and DAST tools appropriate for the mobile platform(s) in scope, and the rationale for tool selection shall be documented (6.7-CR-07) (§5.7, p. 42).
  • MFA and role-based access controls shall be enforced for all accounts with the ability to publish, update or manage mobile application releases on distribution platforms, and an access review process shall be maintained for these accounts (6.8-CR-06) (§5.8, p. 46-47); a code-signing process shall be established and maintained for mobile application distribution artefacts (6.8-CR-05) (§5.8, p. 46).
  • A vulnerability handling policy (7.2-CR-01) and a publicly available coordinated vulnerability disclosure (CVD) policy (7.3-CR-01) shall be established (§6.2, p. 56; §6.3, p. 58). Reporters shall be able to report anonymously (7.3-CR-07) and receipt shall be confirmed within a published response window (7.3-CR-11) (§6.3, p. 60-61).
  • Each vulnerability shall be assigned a handling priority (7.4-CR-04) (§6.4, p. 63).
  • Where technically feasible, security updates shall be delivered independently of functional updates, rather than bundled together (7.6-CR-04) (§6.6, p. 66).
  • Security updates shall be made available at no cost (except where a manufacturer and a business user have explicitly agreed otherwise for a purpose-built product with digital elements) and released without undue delay (7.7-CR-01, 7.7-CR-02) (§6.7, p. 68).
  • Vulnerability information shall be published after resolution with a minimum set of elements (7.7-CR-04); guidance states published vulnerability information should be made available through the EU Vulnerability Database (EUVD) (§6.7, p. 69). Complete publication shall be deferred when all three listed conditions are simultaneously satisfied (7.7-CR-05) (§6.7, p. 70).

Requirements in this document​

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

  • Each requirement is introduced as "Requirement CR-ID: <clause>-CR-<two-digit number>", followed by the requirement text, a "Source:" line and usually a "Guidance" section; each subsection containing requirements also has an "Introduction" and an "Output" statement (§4.2, p. 10-11; §4.2-§6.7, p. 10-70). The document does not expand the abbreviation "CR" (§4.2-§6.7, p. 10-70).
  • The clause number in the CR-ID is one higher than the printed section number: section 4.x uses IDs 5.x-CR, section 5.x uses 6.x-CR, section 6.x uses 7.x-CR (e.g. §4.2 contains 5.2-CR-01) (§4.2, p. 10; §5.2, p. 25; §6.1, p. 55). Cross-references in the text use the CR-ID numbering (e.g. 6.2-CR-01 refers to "the product context from 5.2" and "Clauses 6 and 7") (§5.2, p. 25).
  • Counts (122 requirements in total, counted from the PDF) (§4.2-§6.7, p. 10-70):
    • Product Cybersecurity Risk Management (IDs 5.x, printed §4): 27 — 5.2 Product Context Documentation 3 (p.10); 5.3 Risk Acceptance Criteria 1 (p.12); 5.4 Asset Identification 2 (p.13); 5.5 Risk Identification 3 (p.14); 5.6 Risk Analysis 5 (p.16); 5.7 Risk Evaluation and Risk Acceptance 4 (p.19); 5.8 Risk Treatment 3 (p.20); 5.9 Risk Communication 3 (p.22); 5.10 Risk Review 3 (p.23).
    • Product Cybersecurity Lifecycle Activities (IDs 6.x, printed §5): 57 — 6.2 Planning 2 (p.25); 6.3 Requirements 3 (p.26); 6.4 Architecture and Design 1 (p.27); 6.5 Secure Implementation 10 (p.28); 6.6 Technical Product Documentation 6 (p.33); 6.7 Verification and Validation 11 (p.38); 6.8 Secure Production and Distribution 9 (p.44); 6.9 Monitoring and Issue Management 6 (p.48); 6.10 Secure Decommissioning 2 (p.50); 6.11 Third-Party Component Cybersecurity Management 7 (p.51).
    • Vulnerability Handling (IDs 7.x, printed §6): 38 — 7.1 Operational Security 2 (p.55); 7.2 Facilities 5 (p.56); 7.3 CVD Facilities 12 (p.58); 7.4 Intake 6 (p.62); 7.5 Communication with Stakeholders 2 (p.64); 7.6 Remediation 5 (p.65); 7.7 Release of Security Updates and Information 6 (p.67).
  • "Source:" lines cite codes such as "RMA-01-RQ-02 (40000-1-2)" (§4.2, p. 11), "REQ-CON-003 (40000-10)" (§5.5, p. 32), "PRE-1-RQ-01 (40000-1-3)" (§6.2, p. 56), "SOTA" (§4.2, p. 11), or combinations, sometimes with a remark on how the source was adapted (e.g. "SOTA (from optional to mandatory)") (§6.7, p. 70).
  • The Annex lists each requirement by number with a short key phrase, using the 5/6/7 clause numbering (Annex, p. 72-75).
  • NL-SYS-01 (framework; surveillance, change notification, incident management, certificate maintenance) (§1.1, p. 4; §3.2, p. 9; §2, p. 6) (listed in the chapter-2 subsection numbered "1.1 Parent & Related Documents"); NL-SYS-02 and the other applicable NL-SYS system documents (§2, p. 7).
  • NL-P-P/W (PID Provider & Wallet Provider Certification Schemes); NL-P-01; NL-P-02 (§2, p. 7).
  • Standards (normative): ISO/IEC 17065, 17067, 27001, 27002, 27005 (§2.2, p. 6). Informative: EUDI Wallet Architecture and Reference Framework (§2.3, p. 7).
  • Standardisation work drawn on: draft CEN/CENELEC JTC 13/WG 9 (product cybersecurity risk management, product lifecycle, vulnerability handling) and draft CEN/CENELEC TC 224/WG 17 (identity-management and access-control products) (§3.2, p. 9).
  • Guidance also cites e.g. OpenCRE (§4.1, p. 10); OWASP Mobile Top 10 and OWASP MASVS (§4.3, p. 13); ISO/IEC 27090 and prEN 18282 (§4.4, p. 14); OWASP MASTG (§4.6, p. 17); EN 40000-1-4 (§5.4, p. 28); the ECCG “Agreed Cryptographic Mechanisms” (ACM) (§5.5, p. 31); EN ISO/IEC 29147:2020 (§6.1, p. 55); EN ISO/IEC 30111:2020 (§6.1, p. 56); ISO/IEC 20153:2025 (§6.7, p. 69).
  • EU legal acts: Regulation (EU) No 910/2014 as amended by 2024/1183; Regulation (EU) 2024/2847 (CRA); CIR (EU) 2024/2690 (where in scope or adopted nationally); CIR (EU) 2015/1502 (§2.1, p. 6); Directive (EU) 2022/2555 (NIS2), in particular Article 21 (§1.1, p. 4; §3.1, p. 8).

Notes on this draft​

  • No table of contents is included; the document starts with §1 on p.4 (p. 4).
  • Section numbering errors: the parent-documents subsection in chapter 2 is numbered "1.1 Parent & Related Documents" (p. 6); the colofon is numbered "2 Colofon" (p. 71).
  • CR-ID numbering and cross-references are offset by one from printed section numbers (§4.2, p. 10; §5.2, p. 25).
  • Footers read "Secure Software Practices | RC1.0 | Intern gebruik" ("internal use") (p. 2-75); colofon states author Software Improvement Group, version 0.95, status "Intern gebruik" (Colofon, p. 71).
  • The cover lists NL-P-03 itself under Related Documents (cover, p. 2).
  • The Annex overview lists 3 items for 7.5 and 7 items for 7.7, while the body contains 2 (7.5-CR-01/02) and 6 (7.7-CR-01..06) CR-IDs (Annex, p. 75; §6.5, p. 64-65; §6.7, p. 68-70).
  • 7.3-CR-12 uses "should": reports via channels not meeting 7.1 "should still be accepted" (§6.3, p. 61).
  • Source codes ("40000-1-2", "40000-1-3", "40000-10", "SOTA") are not expanded in the document (§4.2-§6.7, p. 10-70).

Sources​