Skip to main content

NL-CS Part 2: NL-CS Scheme Procedures

NL-CS Part 2: NL-CS Scheme Procedures

Download PDF (2.2 MB, 28 pages)Read the full text
Cover page of the document, as printed
Document referenceNL-CS (part2)
VersionRC1.0
StatusRelease Candidate
Date25/10/2026
Document typeFITCEM Certification Scheme Scheme Procedures
Parent frameworkNL-SYS-01, NL-SYS-02, NL-SYS-03, NL-SYS-04, NL-SYS-05 NL-TL
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetEuropean Digital Identity Wallet Solutions
Primary audienceScheme Owners, Evaluation Laboratories; CABs, EUDI Wallet providers
Secondary audienceEUDI 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​

NP002 contains the procedures that Certification Bodies, Evaluation Laboratories and product developers follow when applying for, performing and maintaining certification of the European Digital Identity Wallet under the NL FITCEM scheme (§1.1, p. 6). [NP001] (NL-CS part 1) is the complete scheme document; NP002 "does not restate that policy. It adds the procedural detail, and it refers to [NP001] by section number" (§1.1, p. 6). Where NP002 and [NP001] differ, [NP001] prevails (p. 2).

Scope and object of certification​

  • Procedural scope: application and acceptance review; evaluation planning (laboratory selection, architecture verification, sampling); the FITCEM evaluation process (product identity verification, delta assessment); review of dependencies on components outside the TOE; certification decision, certificate, certification report and publication; post-certification (surveillance, special evaluations, change management, incident and vulnerability management); non-conformity, suspension and withdrawal; complaints and appeals; recertification; scheme maintenance (§1.2, p. 6).
  • Object: the Wallet Instance as a standalone TOE under the draft Protection Profile; the WSCA-BE and WSCD are in the operational environment, and the WSCD certificate is "an environmental requirement and not a composition input" (§5.2, p. 16).
  • Only the remote WSCA-WSCD variant is admitted "Today"; embedded secure element and eSIM variants require a Protection Profile before certification; the no dedicated secure element variant is not admitted at assurance level high (§3.3, p. 11).

Who it applies to​

  • Product developer ("The provider of the wallet solution that applies for and holds the certificate of conformity. Formerly Wallet Provider" (Annex B, p. 27)): selects a CB, submits the application, provides evidence, source code, risk assessment and functional certificate, notifies changes and vulnerabilities, prepares VIARs, discloses remediated vulnerabilities, may request recertification (§2.2–2.3, p. 9–10; §4.2, p. 13; §7.4, p. 20; §8, p. 21; §10, p. 23).
  • Certification Body (CB): reviews applications, prepares and approves the evaluation plan, verifies laboratories and architecture, defines sampling rules, chairs ERMs, reviews the ETR, delta assessments and dependencies, takes the certification decision, issues certificates and reports, notifies the supervisory body, handles complaints, conducts surveillance and special evaluations, manages changes, responds to vulnerabilities, suspends and withdraws certificates (§2.4–§10, p. 10–23).
  • Evaluation Laboratory ("Formerly ITSEF" (Annex B, p. 27)): performs the evaluation tasks under CB responsibility, verifies product identity, produces delta assessments and the ETR (§4, p. 13–15).
  • Scheme Owner (identity "[to be confirmed]"): maintains the register of authorised CBs, receives notifications, resolves escalated complaints, maintains the central vulnerability register, maintains the scheme (§1.3, p. 6; §2.2, p. 9; §6.4, p. 17; §6.6, p. 18; §8.5, p. 21; §11, p. 24; Annex B, p. 27).
  • Supervisory body referred to in Article 46a(1) of Regulation (EU) No 910/2014: notified by CBs of issuance, suspension and cancellation of certificates (§6.5, p. 18).
  • Market surveillance authorities: informed where non-conformity concerns other Union legislation (§9.1, p. 22).

Contents​

  • Document control; p.2.
  • §1 Introduction (purpose and relationship to NP001, scope, terms and scheme type, references); p.6. Read
  • §2 Application for certification (eligibility, CB selection, application submission, application review); p.9. Read
  • §3 Evaluation planning (evaluation plan, laboratory selection and licensing floor, architecture verification, sampling rules); p.11. Read
  • §4 FITCEM evaluation process (overview, evidence, evaluation tasks, product identity verification and delta assessment, evaluation review meetings, ETR); p.13. Read
  • §5 Review of dependencies (purpose, scope, acceptability criteria for assurance information of components outside the TOE); p.16. Read
  • §6 Certification decision (assessment, grounds for a positive decision, certificate of conformity, certification report and publication, notification of the supervisory body, complaints and appeals); p.17. Read
  • §7 Post-certification (certification lifecycle, surveillance evaluations, special evaluations, change management); p.19. Read
  • §8 Incident and vulnerability management (notification, policy, impact analysis, disclosure, CB response); p.21. Read
  • §9 Non-conformity, suspension and withdrawal (consequences, suspension, withdrawal, non-compliance by a CB); p.22. Read
  • §10 Recertification; p.23. Read
  • §11 Scheme maintenance; p.24. Read
  • §12 Open points of this document; p.25. Read
  • Annex A: Certification process summary (phases, steps, responsible party, section); p.26. Read
  • Annex B: Glossary (additional terms); p.27. Read
  • Annex C: FOR REVIEW and placeholder register; p.28. Read

Key points​

  • Eligibility: only providers referred to in Article 5a(2) of Regulation (EU) No 910/2014 as amended are eligible; the CB verifies eligibility in the application review (§2.1, p. 9).
  • The product developer selects a CB from the Scheme Owner's register of authorised CBs; "There is no restriction on cross-border engagement of authorised Certification Bodies" (§2.2, p. 9).
  • Application contents (at least): (1) FIT ST; (2) architecture description; (3) functional certificate (or ARF FCAF attestation) for the same product and exact same version; (4) proposed evaluation plan; (5) risk assessment; (6) assurance information for components outside the TOE (WSCD, and WSCA-BE where not in the TOE); (7) source code access; (8) evidence per the [NI002] checklist; (9) operational process descriptions (version control, change management, update delivery, vulnerability management per ISO/IEC 30111); (10) baseline information for changed products (§2.3, p. 9–10).
  • Failure to provide source code "counts as an evaluation failure [stated decision of the scheme owner]" (§2.3, p. 10).
  • Application review: the CB reviews "within a reasonable time" and confirms in writing, or states what is missing, regarding eligibility, FIT ST completeness and PP conformance, admitted architecture, functional certificate validity and identifiers, evaluation plan and laboratory scope, and assurance information for components outside the TOE (§2.4, p. 10).
  • The CB approves the evaluation plan in writing before evaluation starts; it contains scope, tasks and fixed time budget per task, laboratory, pinned versions of PP and external specifications, test to requirement mapping (or delivery date), SUG language, treatment of a terminating finding and tool custody, and the timeline (§3.1, p. 11).
  • Laboratory licensing floor: ISO/IEC 17025 accreditation with scope covering CC (ISO/IEC 15408 with 18045) at EAL4 with AVA_VAN.3 or higher, or SESIP level 3 or higher, including mobile applications; no EN ISO/IEC 17020, 17021 or 17029 substitutes (§3.2, p. 11).
  • Architecture verification per [IR 2981] Article 13(2); for an architecture with no admitted PP "the CB informs the Scheme Owner and does not accept the application" (§3.3, p. 11–12).
  • Sampling: functional and security tests may be performed on a sample of variants and target devices, justified in the evaluation plan ([IR 2981] Article 13(3)); a variant that changes the TOE boundary, operational environment assumptions or architecture variant is not a sampling case (§3.4, p. 12).
  • Assurance level high is mandatory; "The attack potential expectation and the depth of the vulnerability analysis (working position AVA_VAN.3) remain a placeholder in [NP001] section 5.1 and are not set here" (§4.1, p. 13).
  • Required EN 17640 tasks at high: 6.1 Completeness check; 6.4 FIT Security Target evaluation; 6.5 Development documentation (includes "vulnerability and patch management"); 6.6 Evaluation of TOE installation; 6.7 Conformance testing (full coverage, no reduction on the basis of functional conformity testing); 6.10 Penetration testing (Flaw Hypothesis Methodology, OWASP MAS-based, attack potential per EN 17640 Annex F); 6.12 Extended cryptographic analysis; plus product identity verification, delta assessment (where applicable) and reporting (ETR per Annex G of EN 17640) (§4.3, p. 13–14).
  • Not required at high: tasks 6.3, 6.8, 6.9 and 6.11 "[inferred from Table 1 and Table D.2 ...]" (§4.3, p. 14).
  • The evidence provided includes "the vulnerability and patch management process documentation" (§4.2, p. 13).
  • Grounds for a positive decision: all tasks positive; findings resolved or accepted with justification and any termination followed by a completed re-run; positive identity result or accepted positive delta conclusion; valid functional certificate for the exact version at the decision date; positive dependency review; positive initial audit under [NI003]; FIT ST accurate; "no open vulnerability precludes certification at assurance level high" (§6.2, p. 17).
  • Certificate content per Annex VII of [IR 2981] plus: developer and product with version and build; scope incl. architecture variant, PP identification and version, sampling limitation; functional certificate identifiers; assurance level, issue and expiry dates; CB and laboratory with accreditation references; the Trust Mark [to be confirmed] as only mark of conformity (§6.3, p. 17).
  • Certificate validity "does not exceed five years, as laid down in Article 5c(4) of Regulation (EU) No 910/2014" (§6.3, p. 17).
  • The public certification report follows Annex VIII of [IR 2981]; the certification assessment report (CAR) goes to the Scheme Owner and may be made available to the Cooperation Group and the Commission (Article 14(2)) (§6.4, p. 17).
  • Lifecycle (reference schedule of Annex IX of [IR 2981], "a recommendation"): other schedules are possible "as long as the validity does not exceed five years, and each evaluation is performed within 12 months of the evaluation of the previous year" (§7.1, p. 19).
  • Vulnerability assessment "at least every two years in surveillance evaluations"; penetration testing is added in case of increased risk level or new threats (Annex IX, point 1) (§7.1, p. 19).
  • Notification time limits: breaches or compromises likely to impact conformity "without undue delay" (Article 5(2)); critical vulnerabilities and active exploits "within 24 hours of discovery"; high-severity vulnerabilities "within 72 hours"; other vulnerabilities and changes "follow the timeline of the scheme"; severity scale "[to be defined, FOR REVIEW]" (§8.1, p. 21).
  • Vulnerability management policy taking into account ISO/IEC 30111 (Article 5(3)); Article 5(7) requires it to meet Annex I of the Cyber Resilience Act (§8.2, p. 21).
  • VIAR for any vulnerability affecting software components (impact, risks, remediability, possible remedies; Article 5(5)), transmitted to the CB "without undue delay" (Article 5(6)) (§8.3, p. 21).
  • Disclosure: the product developer discloses and registers any publicly known and remediated vulnerability in the online repositories referred to in Annex V of [IR 2981] (Article 5(9)) (§8.4, p. 21).
  • CB response: assesses impact, decides on special evaluation, reports to the Scheme Owner regardless of severity, notifies the supervisory body of any suspension; suspends the certificate "without undue delay" after confirming the breach impacts conformity (Article 12(1)) (§8.5, p. 21).
  • Recertification notice: the CB notifies the product developer "at least 12 months before expiry [carried from the earlier draft; not in NP001]" (§10, p. 23).

Process​

Application, evaluation and decision (per Annex A and the sections cited) (Annex A, p. 26):

  1. Product developer: checks eligibility and selects a CB from the register (§2.1–2.2, p. 9).
  2. Product developer → CB: submits the application including the functional certificate (§2.3, p. 9–10).
  3. CB: reviews the application within a reasonable time and confirms acceptance in writing or states what is missing (§2.4, p. 10).
  4. CB with laboratory and developer: prepares the evaluation plan; CB verifies the laboratory against the licensing floor, keeps accreditation on file and informs the Scheme Owner of the engagement; CB approves the plan in writing before evaluation starts (§3.1–3.2, p. 11).
  5. CB: verifies the architecture and sets sampling rules (§3.3–3.4, p. 11–12).
  6. Product developer → laboratory: delivers evidence per the [NI002] checklist (§4.2, p. 13).
  7. Laboratory (under CB responsibility): performs tasks 6.1, 6.4, 6.5, 6.6, 6.7, 6.10, 6.12, product identity verification and any delta assessment within the fixed time budget (§4.3, p. 13–14; §4.5, p. 14–15).
  8. Laboratory, CB: findings and termination ("section 4.4", see Notes) (Annex A, p. 26).
  9. CB: reviews dependencies (WSCD certificate, WSCA/WSCA-BE assurance information, platform verification mechanisms, other certificates) (§5, p. 16).
  10. CB: initial audit of operational processes per [NI003] (Annex A, p. 26).
  11. CB (chair): optional evaluation review meetings, documenting the outcome of each (§4.6, p. 15).
  12. Laboratory → CB: submits the ETR; CB reviews it and may request clarification (§4.7, p. 15).
  13. CB certifying function: assesses ETR, delta assessment, dependency review and audit report independently of evaluation; takes the decision; issues the certificate and public certification report; provides the CAR to the Scheme Owner; notifies the Scheme Owner (register) and the supervisory body (§6.1–6.5, p. 17–18).

Maintenance and surveillance (lifecycle per Annex IX of [IR 2981]) (§7.1, p. 19):

  • Year 0, Initial (CB/laboratory): full evaluation of the Wallet Instance including vulnerability assessment and the update feature of each software component; evaluation of maintenance processes excluding operating effectiveness ([NI003] initial audit); certificate issued; "start of the 4-year cycle".
  • Year 1, Surveillance: operating effectiveness of maintenance processes (at least version check, update and vulnerability management); evaluation of security-impacting changes.
  • Year 2, Surveillance: vulnerability assessment of the full solution; operating effectiveness; evaluation of changes.
  • Year 3, Surveillance: operating effectiveness; evaluation of changes.
  • Year 4, Recertification: full evaluation including vulnerability assessment, simplified for unchanged features and processes; update feature of each software component; maintenance processes including operating effectiveness; new certificate.
  • Surveillance (CB conducts or oversees): operating effectiveness of version control, update delivery and vulnerability management; review of changes via delta assessment; updated vulnerability assessment where scheduled or triggered; continued validity of the functional certificate and environmental-requirement certificates; CB issues a surveillance report; if conformity is not confirmed, §9 applies (§7.2, p. 19).
  • Special evaluation (triggered by the CB or certificate holder): triggers are a change concluded partially covered or not covered; an identified vulnerability or incident; suspension, withdrawal or expiry of the functional certificate or change of WSCD identity, version or certification status; a developer request before expiry; a CB or Scheme Owner decision on a changed threat environment; it may lead to a new certificate with the same expiry date; scope set by the CB in consultation with the developer (§7.3, p. 20).
  • Change management: the product developer notifies the CB of all planned changes before implementation; the CB determines per change whether a special evaluation or verification of operating effectiveness applies ([IR 2981] Article 18(3)), using the delta assessment: Covered → recorded and examined in next surveillance; Partially covered → special evaluation of affected requirements and modules within the fixed time budget, remainder reused; Not covered → full evaluation (special evaluation with same expiry date if the certificate is retained; otherwise a new certification); the CB records its decision and informs the developer in writing (§7.4, p. 20).
  • Incident and vulnerability handling: see Key rules (§8, p.21).
  • Non-conformity (Article 17): the CB (1) informs the developer and requests remedial actions "within a defined timeframe"; (2) informs other market surveillance authorities where relevant; (3) sets conditions and monitors remediation; (4) restores a suspended certificate when conformity is restored; (5) withdraws where irreparable or not remedied in time (§9.1, p. 22).
  • Suspension: where a vulnerability or incident is confirmed and remediation is pending; required notifications, surveillance cooperation or evidence are not provided; a change requiring evaluation was implemented without it; the functional certificate is suspended or withdrawn; or continued conformity is otherwise in reasonable doubt; communicated "without undue delay" to the developer, Scheme Owner and supervisory body and shown in the public register; the CB states restoration conditions (§9.2, p. 22).
  • Withdrawal ("cancellation in [IR 2981]"): where non-conformity cannot be remedied or is not remedied in time (Article 12(2) and (3)), or the developer requests it, ceases to operate or discontinues the product; considered only where an unremedied vulnerability is likely to significantly affect the reliability of the wallet solution or another wallet solution (recital 19); communicated, published in the register; the developer stops using the Trust Mark (§9.3, p. 22).
  • Recertification: requested by the developer before expiry ([IR 2981] Article 18(2)); full procedure with Annex IX simplifications; reuse justified by delta assessment with the previous evaluation as baseline, including re-assessment of attack potential (Annex C items 16 and 17 of NP001); a functional certificate for the exact version must be valid at the decision; the new certificate is valid at most five years from issue (§10, p. 23).
  • Complaints and appeals: handled by the CB in the first instance; the complainant is informed of progress, decision and right to judicial remedy; unresolved cases go to the Scheme Owner ([IR 2981] Article 15) (§6.6, p. 18).
  • Scheme maintenance (Scheme Owner): governance, timelines for certificates after updated versions, periodic review, monitoring of reference documents with transition periods, coverage of latest risks in the Annex I risk register, process for other changes; transition arrangements published per revision; Cooperation Group notified where required (§11, p. 24).

Requirements in this document​

  • The document does not number requirements. Application elements are numbered 1–10 (§2.3, p. 9–10); evaluation tasks use EN 17640 clause numbers (6.1, 6.4, 6.5, 6.6, 6.7, 6.10, 6.12) (§4.3, p. 13–14); Annex A process steps are tagged with NP001 §6.1 phase numbers 1–7 (Annex A, p. 26). Annex C lists 14 open points by section (Annex C, p. 28).
  • [NP001] (NP001-EUDIW-C, "0.9.4 for review, 24 October 2026"): the complete scheme; NP002 implements its policy and refers to it by section number; NP001 prevails (p. 2; §1.1, p. 6; §1.4, p. 6).
  • [NI002] Evaluation Instruction for Evaluation Laboratories (evidence checklist §3, identity steps §4.1, ERM details §5) and [NI003] Audit Instruction for Operational Processes, both "0.9.4 for review, 24 October 2026" (§1.4, p. 7; §2.3, p. 10; §4.5–4.6, p. 14–15).
  • [PP-WI-REMOTE] (0.2d, 20 August 2026, draft); [PP-WI-DRAFT] "EN 17640 Protection Profile of the Wallet Instance (project draft; cryptographic annex pending)", "Draft 0.6 reviewed; 0.7 pending"; [TP-WI-BB] (1.0, 16 October 2026, effort basis) (§1.4, p. 7).
  • [EUCC-NI002] and [EUCC-NI003]: Dutch NCCA EUCC scheme documents, reference only; [NSI002] "Content and presentation of evaluation review meetings, EUDI Wallet certification using FITCEM (outside the NP001 document set)" (§1.4, p. 7).
  • Standards: EN 17640 (2022), EN 17927 (2023), ISO/IEC 15408 (2022), ISO/IEC 18045 (2022), EN ISO/IEC 17025 (2017), 17065 (2012), 17067 (2013), 30111 (2019), EN ISO 19011 (informative, edition not pinned), OWASP MAS (MASVS 2.1.0; MASWE 1.0; MASTG current; EUDI Wallet profile draft) (§1.4, p. 7–8).
  • EU legal acts: Regulation (EU) No 910/2014 / 2024/1183 (Articles 5a(2), 5c(4), 46a(1)); [IR 2981] (Articles 5, 6, 11, 12, 13, 14, 15, 17, 18; Annexes I, II, IV, V, VII, VIII, IX; recitals including 19); [IR 2979]; [IR 848]; Regulation (EC) No 765/2008; Cyber Resilience Act Annex I (via Article 5(7)) (§1.4, p. 6–8; §2–§11, p. 9–24).
  • [ARF] including the FCAF ("Version to be pinned") (§1.4, p. 8).

Notes on this draft​

  • Section 4.4 is missing: the TOC and body jump from 4.3 to 4.5 (p. 4; p. 14), yet 4.4 is referenced for the treatment of terminating findings and tool custody (§3.1, p. 11), for "any termination under section 4.4" (§6.2, p. 17), for "Findings and termination" (Annex A, p. 26), and in Annex C ("Termination rule, restart budget, tool custody") (Annex C, p. 28).
  • §4.1 states that the attack potential expectation and the depth of the vulnerability analysis (working position AVA_VAN.3) "remain a placeholder in [NP001] section 5.1" (§4.1, p. 13); NL-CS part 1 §5.1 (p.15) reads "high (CC AVA_VAN.3/SESIP3 equivalent)" without a placeholder mark.
  • §3.1 states "the effort table of [NP001] is still a placeholder" (§3.1, p. 11); NL-CS part 1 §5.3 (p.15) contains an effort table with figures.
  • §1.3 contains "[stated as position of R. Huisman in the project record; see [NP001] section 3.1]" (§1.3, p. 6).
  • Annex C register: scheme type "[NP001] says Type 5, [IR 2981] requires type 6"; [NSI002] outside the document set; functional certificate before evaluation versus delta assessment in advance; CB umbrella route versus the floor "(decision 8); no licensing procedure"; cryptographic catalogue for task 6.12; termination rule, restart budget, tool custody; platform assumptions versus platform testing scope; supervisory body missing from the parties; emergency security fixes versus approval before implementation; severity scale; CRA Annex I versus the NP001 scope exclusion; vulnerability disclosure requirements for CBs ([IR 2981] Art. 5(8)); suspension and withdrawal criteria and timeframes "(EZU)"; consequences of non-compliance by a CB (Annex C, p. 28).
  • [PLACEHOLDER] task 6.12: "Until it is issued, task 6.12 is required but its method is undefined" (§4.3, p. 14).
  • [PLACEHOLDER] §9.4 non-compliance by a CB: "The earlier draft and [NP001] are silent ... To be decided" (§9.4, p. 22).
  • §8.4: Article 5(8) requires vulnerability disclosure requirements applicable to CBs, but none are set out (§8.4, p. 21).
  • Unspecified time limits: application review "within a reasonable time" (§2.4, p. 10); remedial actions "within a defined timeframe" (§9.1, p. 22); other vulnerabilities and changes "follow the timeline of the scheme" (no timeline given) (§8.1, p. 21).
  • Bracketed editorial remarks remain: "[Carried from the earlier draft; not addressed in [NP001].]" (§2.2, p. 9); "[checked against the standard text held in the project]" (§4.3, p. 13); "[Escalation to the Scheme Owner is not yet stated in [NP001] section 3.2.]" (§6.6, p. 18); "[checked against the project text]" (§7.1, p. 19); "[carried from the earlier draft; not in NP001]" (§10, p. 23).
  • The supervisory body is "Not yet a role in [NP001] section 3.1" (Annex B, p. 27).
  • [NP001] and [NP002] are listed with version "0.9.4 for review, 24 October 2026" (§1.4, p. 6), while the cover says RC1.0 dated 25/10/2026 (p. 2).
  • Cover lists "NL-WSCA & NL-WSCA-conditions" (not "NL-CS-WSCA") (p. 2); the body (pp.4–28) does not mention NL-CS-WI, NL-WSCA, the conditions documents, or NL-CS parts 3 and 4 (p. 2).

Sources​