Skip to main content

NL-CS Part 3: NL-CS Evaluation Instruction for Evaluation Laboratories

NL-CS Part 3: NL-CS Evaluation Instruction for Evaluation Laboratories

Download PDF (2.1 MB, 17 pages)Read the full text15 requirements
Cover page of the document, as printed
Document referenceNL-CS (part3)
VersionRC1.0
StatusRelease Candidate
Date25/10/2026
Document typeFITCEM Certification Scheme Scheme Specification
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​

NI002 instructs Evaluation Laboratories on how to perform the FITCEM evaluation tasks for the European Digital Identity Wallet at assurance level high, and what to record; it is the document that [NP001] section 7 lists as the general FITCEM evaluation task instructions for laboratories (Document control, p. 2). It tells the Evaluation Laboratory what to do, in which order and with what output, for each evaluation task that [NP001] requires, supporting the fixed time premise of FITCEM (§1.1, p. 5). It adds no requirement to [NP001]; where a requirement is stated it is drawn from [NP001], [EN 17640] or [NP002] and the source is named (Document control, p. 2).

Scope and object of certification​

  • Applies to evaluations of the European Digital Identity Wallet Instance at assurance level high under the NL FITCEM scheme, for the architecture variants admitted in [NP001] section 2.3 (§1.2, p. 5).
  • "Today that is the remote WSCA-WSCD variant under [PP-WI-REMOTE]" (§1.2, p. 5).
  • Out of scope: the audit of the product developer's operational processes ([NI003]), the certification decision, and the procedures of [NP002] (§1.2, p. 5).
  • Items marked [proposed] are drafting proposals of this document and are not yet decided (Document control, p. 2).

Who it applies to​

  • Evaluator (Evaluation Laboratory): performs the evaluation tasks, produces the evaluator evidence and the ETR; acts under the responsibility of the CB ([NP001] section 3.3) (§1.3, p. 5).
  • Certifier (Certification Body): reviews the evaluation activities, issues the mandatory guidance and the evaluation plan, chairs evaluation review meetings, reviews the ETR and any delta assessment (§1.3, p. 5). The CB decides in the evaluation plan whether and when to hold evaluation review meetings (§5, p. 13), and does not take a positive decision without a positive identity result or a delta conclusion it has accepted (§4.1, p. 9).
  • Product developer (Applicant): delivers the evidence checklist, the test samples and accounts, and the source code; answers evaluator questions (§1.3, p. 5).

Contents​

  • Document control — document metadata table, introductory paragraph and version history table; starts p.2 (Contents, p. 4).
  • 1 Introduction — purpose, scope, involved roles and conventions; starts p.5 (§1, p. 5).
  • 2 General rules for the evaluation — assurance level, task set and time; evaluator competence; pinning and tool control; starts p.6 (§2, p. 6).
  • 3 Evidence checklist — the scheme-specific checklist E1–E15 referred to by [EN 17640] 6.1 and 6.5; starts p.7 (§3, p. 7).
  • 4 Task instructions — instructions per task (4.1 product identity verification to 4.11 ETR); starts p.9 (§4, p. 9).
  • 5 Evaluation review meetings (optional) — proposed form of ERM1, ERM2 and final ERM; starts p.13 (§5, p. 13).
  • Annex A: ETR outline [proposed] — nine-section outline of the ETR; starts p.14 (Annex A, p. 14). Read
  • Annex B: References — reference tags with versions or dates; starts p.15 (Annex B, p. 15). Read
  • Annex C: FOR REVIEW and placeholder register — open points per section with their origin; starts p.17 (Annex C, p. 17). Read

Key points​

  • The assurance level is high and this is mandatory ([NP001] section 5.1) (§2.1, p. 6).
  • Required tasks: [EN 17640] 6.1, 6.4, 6.5, 6.6, 6.7, 6.10 and 6.12, together with the product identity verification ([NP001] section 6.2.1) and, where it applies, the delta assessment ([NP001] section 6.6) (§2.1, p. 6).
  • Each task has a fixed time budget set in the evaluation plan; the evaluator shall record the time spent per task and report any deviation in the ETR; more functionality raises the probability of findings within the budget but does not extend the budget (§2.1, p. 6).
  • The evaluator shall not reduce testing because a requirement has been covered by functional conformity testing, except where [NP001] section 6.6 and the Protection Profile expressly permit reuse (§2.1, p. 6).
  • The competence statements per task in [EN 17640] apply; [NP001] section 3.3 requires the laboratory to maintain evaluator competence "at or above the level required by this document"; the competence requirements document NI-COMP-001 was removed from the scheme in the current [NP001] (§2.2, p. 6).
  • The evaluator shall record the exact versions of the Protection Profile, each OWASP MAS deliverable, the platform and devices, and every tool and script; scripts and test tools shall be kept under configuration control and identified by version (§2.3, p. 6).
  • The evidence checklist is a baseline that the Protection Profile can extend, because the Protection Profile and the OWASP profile are not complete (§3, p. 7).
  • Source code (E7): failure to provide it counts as an evaluation failure (§3, p. 7).
  • Missing or incomplete evidence items are recorded as findings and communicated to the CB; the evaluator shall not proceed with a task whose evidence is missing unless the evaluation plan says otherwise (§4.2, p. 9).
  • Product identity must be determined from the evaluated product itself (at minimum application identifier, version name, version code and signing certificate fingerprint), not solely from the developer's declaration (§4.1, p. 9).
  • FIT ST evaluation: because a Protection Profile is mandatory, work unit 1b applies and work unit 1a does not (§4.3, p. 9); the evaluator confirms that the environmental requirements table of the Protection Profile is mirrored in the FIT ST and not restated or altered (§4.3, p. 9), and that the WSCA-BE and WSCD are placed as the Protection Profile places them (§4.3, p. 10).
  • Development documentation: [EN 17640] advises schemes to keep this task as light as possible; source code is used to support penetration testing and extended cryptographic analysis; further source code review beyond what the Protection Profile requires is not part of this task (§4.4, p. 10).
  • Conformance testing: at assurance level high the coverage is complete and the acceptance criteria are defined by the scheme; the security requirements to be tested are the Functional Security Requirements (FSR) and the Resilience Security Requirements (RSR), determined from the FIT ST and the Protection Profile (§4.6, p. 10).
  • A test without a recorded target requirement does not contribute to assurance; the test-to-requirement mapping is many to many (§4.6, p. 11).
  • Penetration testing uses the Flaw Hypothesis Methodology and is a superset of vulnerability testing ([EN 17640] 6.9) (§4.7, p. 11).
  • The penetration test set is built on OWASP MAS as pinned in the evaluation plan; the working baseline at assurance level high is L2 + R + P with the EUDI Wallet profile on top; the ETR references OWASP content rather than reproducing it (§4.7, p. 11).
  • Attack potential is determined per [EN 17640] Annex F; expected resistance and depth of vulnerability analysis are the placeholder of [NP001] section 5.1 ("working position AVA_VAN.3") (§4.7, p. 11).
  • The platform is tested only as far as [NP001] sections 2.2 and 2.4 allow; the Wallet Instance's mechanisms that detect and reject platform states not meeting the environmental requirements are evaluated security controls ([IR 2981], Annex IV, section 4) (§4.7, p. 11).
  • The hours basis of [TP-WI-BB] organises effort per requirement and is not an evaluation test specification (§4.7, p. 11).
  • Extended cryptographic analysis is a [PLACEHOLDER]: until the cryptographic annex is issued, the evaluator shall record the cryptographic specification as evidence, review the algorithms and protocols of the FIT ST for suitability, and propose the method to the CB for approval in the evaluation plan (§4.8, p. 11).
  • Delta assessment shall not be used where the change alters the TOE boundary, the assumptions on the operational environment, the environmental requirements, or the identity or version of a certified component the product depends on; where the analysis cannot be completed within the budget the conclusion is not covered (§4.9, p. 12).
  • Findings: per the working position of [NP001] section 5.2 a finding within the fixed budget terminates the evaluation and the full trajectory is re-run after remediation; until settled, the evaluator stops a task only on CB instruction, reports the finding without undue delay and records the time spent (§4.10, p. 12).
  • The ETR follows [EN 17640] Annex G and [NP002] section 4.7 and is submitted to the CB when all tasks are complete (§4.11, p. 12).
  • Evaluation review meetings are optional; the evaluator shall not rely on a meeting to substitute for the recording obligations of [EN 17640], [ISO/IEC 17025] or [ISO/IEC 17065]; the CB documents the outcome of each meeting (§5, p. 13).

Process​

  1. Product identity verification (Evaluator, together with the completeness check): obtain the functional certificate and report; record identifiers from the certificate; determine the same identifiers from the delivered package; record and compare any cryptographic digest; state whether identifiers are identical; if not, record differences and apply the delta assessment; confirm the functional certificate was valid at the date of the check. Output: positive, negative or delta identity result in the ETR (§4.1, p. 9).
  2. Completeness check, [EN 17640] 6.1 (Evaluator): verify all evidence of section 3 is present; output the completed checklist with delivery date and version per item (§4.2, p. 9).
  3. FIT Security Target evaluation, [EN 17640] 6.4 (Evaluator): check operations assigned, PP conformance claim and pinned version, mirrored environmental requirements table, TOE boundary, consistency with SUG, functional certificate identification, cryptographic algorithms; output verdict and list of inconsistencies (§4.3, p. 9–10).
  4. Development documentation, [EN 17640] 6.5 (Evaluator): check completeness against the checklist and analyse the 6.5.2 entries; output verdict per checklist item and list of gaps (§4.4, p. 10).
  5. Evaluation of TOE installation, [EN 17640] 6.6 (Evaluator; set-up may be done together with the product developer): install from the identified distribution channel per the SUG, record versions, record whether the TOE is in the secure state, check the SUG (§4.5, p. 10).
  6. Conformance testing, [EN 17640] 6.7 (Evaluator): determine FSR/RSR to test, define test cases, record target requirement per test, execute and record failures, record strategy and results in the ETR (§4.6, p. 10–11).
  7. Penetration testing, [EN 17640] 6.10 (Evaluator): gather information, hypothesise flaws, exclude attacks, test, record; output test plan, results, attack potential for failed tests, residual risks (§4.7, p. 11).
  8. Extended cryptographic analysis, [EN 17640] 6.12 (Evaluator proposes method; CB approves in evaluation plan) — placeholder (§4.8, p. 11).
  9. Delta assessment where applicable (Evaluator; product developer supplies a description of all changes): six steps referencing [NP001] Annex C items 1–20, ending in a conclusion of covered, partially covered or not covered (§4.9, p. 12).
  10. Findings handling (Evaluator reports to CB; CB instructs whether to stop) (§4.10, p. 12).
  11. ETR submitted to the CB when all tasks are complete (Evaluator) (§4.11, p. 12).
  • Optional evaluation review meetings [proposed] (CB chairs; evaluator presents): ERM1 "understanding" (results of 4.1–4.4, module decomposition, checklist); ERM2 "test plan" (installation result (4.5), conformance test plan and mapping (4.6), penetration test plan and hypotheses (4.7), cryptographic analysis approach (4.8), time used per task, updated checklist); Final ERM "results" (test results, findings and severity, delta assessment, WSCD and other certificate records, completed checklist, draft ETR). The certifier shall challenge the evaluator on understanding at ERM1, on soundness of the plan at ERM2 and on the analysis of results at the final ERM (§5, p. 13); the certifier chairs evaluation review meetings (§1.3, p. 5).

Requirements in this document​

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

  • The evidence checklist uses identifiers E1–E15 (15 items), each with a "source" column stating whether it is required by [EN 17640], by [NP001], or is [proposed] (§3, p. 7–8):
    • E1 FIT ST (Wallet Security Specification) — [NP001] 4.1, 2.4, 6.2 (§3, p. 7)
    • E2 Functional certificate and report — [NP001] 3.4, 6.2 (§3, p. 7)
    • E3 Specification of the functionality — [EN 17640] 6.5.2 (§3, p. 7)
    • E4 Development process documentation — [EN 17640] 6.5.2 (§3, p. 7)
    • E5 Design documentation — [EN 17640] 6.5.2; [NP001] 5.4 (§3, p. 7)
    • E6 Security architecture description — [EN 17640] 6.5.2; [NP001] 6.6 (§3, p. 7)
    • E7 Source code — [NP001] 3.4; scheme decision (§3, p. 7)
    • E8 Setup and User Guide (SUG) — [EN 17640] 6.6 (§3, p. 7)
    • E9 Test samples and access — [EN 17640] 6.6.4.1 (backend example) (§3, p. 7)
    • E10 Product identification data — [NP001] 6.2.1 (§3, p. 7)
    • E11 Third-party components — [proposed]; needed for [NP001] Annex C item 6 (§3, p. 7)
    • E12 Update mechanism description — [IR 2981] Annex IX (§3, p. 8)
    • E13 Risk assessment — [NP002] 2.3 (§3, p. 8)
    • E14 Assurance information for components outside the TOE — [NP001] 2.4, 5.4 (§3, p. 8)
    • E15 Test to requirement mapping inputs — [proposed] (§3, p. 8)
  • Of the 15 items, two (E11, E15) are marked [proposed] (§3, p. 7–8).
  • Conventions: "Shall" marks a requirement from [NP001], [NP002] or [EN 17640]; "Should" marks a recommendation of this instruction; epistemic tags [established], [inferred], [assumption], [unknown] follow [NP001] (§1.4, p. 5).
  • The ETR outline in Annex A has nine numbered sections: Identification, Summary, Product identity, Environment, Task reports, Mapping, Findings, Residual risks and limitations, Evaluators (Annex A, p. 14).
  • [NP001] NP001-EUDIW-C, NL FITCEM EUDI Wallet Certification Scheme (complete scheme), 0.9.4 for review, 24 October 2026 (Annex B, p. 15); requirements stated in this document are drawn from [NP001], [EN 17640] or [NP002], and [NP001] section 7 lists this document (Document control, p. 2); cited for the assurance level (5.1), product identity verification (6.2.1) and time budget (5.3) (§2.1, p. 6), the delta assessment (section 6.6, Annex C) (§4.9, p. 12) and the termination rule working position (5.2) (§4.10, p. 12).
  • [NP002] Scheme Procedures, 0.9.4 for review, 24 October 2026 — risk assessment (2.3), ERMs (4.6), ETR content (4.7) (Annex B, p. 15; §3, p. 8; §5, p. 13; §4.11, p. 12).
  • [NI002] this document; [NI003] Audit Instruction for Operational Processes — out of scope here (Annex B, p. 15; §1.2, p. 5).
  • [PP-WI-REMOTE] FITCEM Protection Profile for EUDI Wallet Instance supported by a remote WSCA-WSCD, 0.2d, 20 August 2026, draft; the admitted variant is "the remote WSCA-WSCD variant under [PP-WI-REMOTE]" (Annex B, p. 15; §1.2, p. 5).
  • [PP-WI-DRAFT] EN 17640 Protection Profile of the Wallet Instance (project draft; cryptographic annex pending), Draft 0.6 reviewed; 0.7 pending (Annex B, p. 15); section 4.8 states that the cryptographic annex is deferred, per the project record, to a later draft of the [EN 17640] Protection Profile of the Wallet Instance (§4.8, p. 11).
  • [TP-WI-BB] Black-Box Penetration Testing Plan for the Wallet Instance, 1.0, 16 October 2026 — effort basis, not an evaluation test specification (Annex B, p. 15; §4.7, p. 11).
  • Standards: [EN 17640] (FITCEM, 2022); [EN 17927] SESIP (2023); [ISO/IEC 15408] (2022); [ISO/IEC 18045] (2022); [ISO/IEC 17025] (2017); [ISO/IEC 17065] (2012); [ISO/IEC 17067] (2013); [ISO/IEC 30111] (2019); [ISO 19011] (informative, edition not pinned) (Annex B, p. 15). [EN 17640] Annex C and Table D.2 are cited for conformance testing (§4.6, p. 10), Annex F for attack potential (§4.7, p. 11) and Annex G for the ETR (§4.11, p. 12).
  • [EUCC-NI002] and [EUCC-NI003] Dutch NCCA EUCC scheme documents (reference only) (Annex B, p. 15); the [proposed] form of the evaluation review meetings follows the idea of progressive review used in the Dutch EUCC practice (§5, p. 13).
  • [NSI002] Content and presentation of evaluation review meetings, EUDI Wallet certification using FITCEM (outside the NP001 document set), 1.0 (Annex B, p. 16).
  • EU legal acts: [IR 2981] Commission Implementing Regulation (EU) 2024/2981 (Annex IX for update mechanism, Annex IV section 4 for platform-state detection); [IR 2979] (EU) 2024/2979; [IR 848] (EU) 2025/848 (Annex B, p. 16; §3, p. 8; §4.7, p. 11).
  • [OWASP MAS] MASVS 2.1.0; MASWE 1.0; MASTG current; EUDI Wallet profile draft, not released — basis of the penetration test set (Annex B, p. 16; §4.7, p. 11).
  • [ARF] EUDI Wallet Architecture and Reference Framework incl. Functional Conformance Assessment Framework, version to be pinned (Annex B, p. 16).
  • Cover: CIR 2015/1502 and EU Regulation 2019/881 (assurance level High/High) (Document control, p. 2).

Notes on this draft​

  • The document uses two identifiers: "NL-CS (part3)" as Document reference and "NI002" on the cover and in every footer (cover, p. 1; Document control, p. 2; footer, p. 2–17). Its own reference table lists [NI002] as "0.9.4 for review, 24 October 2026" while the document is RC1.0 (Annex B, p. 15).
  • Dates differ: cover "2026.10.25", Document control "25/10/2026", history of changes "24 October 2026" (cover, p. 1; Document control, p. 2; Document control, p. 3).
  • Related documents in the Document control table are named "NL-WSCA & NL-WSCA-conditions" (not "NL-CS-WSCA") (Document control, p. 2). The body does not cite NL-CS-WI by that name; it cites [PP-WI-REMOTE] (version 0.2d, draft) and [PP-WI-DRAFT] (§1.2, p. 5; Annex B, p. 15). The body refers to other documents by reference tags such as [NP001], [NP002] and [NI003], not by NL-CS part numbers (Annex B, p. 15).
  • Section 4.8 is "[PLACEHOLDER] method of the task. The scheme has not yet fixed the cryptographic catalogue or methodology for the extended cryptographic analysis." (§4.8, p. 11); section 4.3 refers to approved algorithms as "[placeholder, see section 4.8]" (§4.3, p. 10).
  • Section 4.7 uses "working position AVA_VAN.3" for expected resistance, a placeholder of [NP001] section 5.1; the platform test scope and budget allocation per task are "open" points of [NP001] (§4.7, p. 11).
  • Section 4.10: "Until the rule is settled … Severity differentiation and the interaction with a partially covered delta conclusion are to be settled." (§4.10, p. 12).
  • Section 2.2: NI-COMP-001 "was removed from the scheme in the current [NP001]"; evaluator competence requirements are an open review point (§2.2, p. 6; Annex C, p. 17).
  • Section 4.6 refers to "Annex C of [EN 17640] on acceptance criteria" while the delta assessment refers to "[NP001] Annex C"; these are different annexes (§4.6, p. 10; §4.9, p. 12).
  • Annex C register lists open points: 2.2 evaluator competence; 2.3 who holds scripts and tools; 3 checklist extension from the PP; 4.6 test set and mapping table; 4.7 attack potential expectation, platform test scope, budget allocation; 4.8 cryptographic catalogue and method; 4.10 termination rule and severity; 5 ERM content agreed with certifiers (Annex C, p. 17).
  • [ARF] "Version to be pinned"; [OWASP MAS] EUDI Wallet profile "draft, not released"; [ISO 19011] "Edition not pinned" (Annex B, p. 15–16).
  • The section-5 ERMs, the Annex A ETR outline and E11/E15 are marked [proposed]; items so marked are drafting proposals and are not yet decided (§5, p. 13; Annex A, p. 14; §3, p. 7–8; Document control, p. 2).

Sources​