Skip to main content

NL-CS Part 1: NL-CS Scheme Specification

NL-CS Part 1: NL-CS Scheme Specification

Download PDF (2.1 MB, 28 pages)Read the full text
Cover page of the document, as printed
Document referenceNL-CS (part1)
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​

This document is "the complete evaluation and certification specification for the European Digital Identity Wallet under the NL FITCEM Cybersecurity Evaluation and Certification Scheme, operated by the Scheme Owner", covering scheme policy, roles, the security requirements approach, the evaluation methodology and the certification process (§1.1, p. 5). The scheme provides a framework for independent cybersecurity evaluation and certification of the wallet using the fixed time evaluation methodology (FITCEM) of EN 17640:2022, augmented with evaluation methodology from Common Criteria (ISO/IEC 15408) and SESIP (EN 17927) (§1.1, p. 5). It applies to the Certification Bodies, Evaluation Laboratories and product developers operating under the scheme (§1.1, p. 5).

Scope and object of certification​

  • Target of Evaluation (TOE): "The product, or defined portion of it, subject to evaluation" (§1.4, p. 6).
  • In scope: the Wallet Instance and its security functions (WSF) and interfaces (WSFI); wallet core functionalities per CIR (EU) 2024/2979; the application's use of platform security services (under §2.4 assumptions); positive tests and vulnerability tests (§2.1, p. 8).
  • WSCA and WSCD are in scope "only to the extent that the applicable Protection Profile places them inside the TOE. Under the current draft Protection Profile they are not in the TOE: the Wallet Instance is a standalone TOE and the WSCA-BE and WSCD are part of the operational environment, subject to the environmental requirement that key protection and cryptographic operations are performed inside a certified WSCD/WSCA" (§2.1, p. 8).
  • Wallet Instance (WI): "The application installed on the User device; the TOE under [PP-WI-REMOTE]" (§1.4, p. 6). WSCA-BE is the backend variant of the WSCA "executing on Wallet Provider infrastructure"; WSCD "In the remote architecture, a certified remote HSM" (§1.4, p. 6).
  • Out of scope: server side and back office components and their interfaces beyond the Protection Profile assumptions; conformity with the Cyber Resilience Act, software development lifecycle assurance and ISMS type certification; the underlying mobile platform and OS ("subject to assumptions and only light verification") (§2.2, p. 8).
  • The management system element is scoped to processes directly relevant to the certified product's security maintenance: change management, vulnerability management and update delivery; general ISMSs are not part of the certification decision (§2.2, p. 8).
  • Architecture variants and admitted Protection Profiles (§2.3, p. 8):
    • Remote WSCA-WSCD (remote HSM): [PP-WI-REMOTE] v0.2d, draft; Wallet Instance as standalone TOE; WSCA-BE and WSCD in the operational environment.
    • Embedded secure element: "[None admitted. Protection Profile required before certification.]"
    • eSIM based: "[None admitted. Protection Profile required before certification.]"
    • No dedicated secure element: "[Not admitted at assurance level high.]"
  • Assumptions on the operational environment: the Protection Profile section 3.3 environmental requirements table (Logical / Procedural / Logical/Procedural; assigned to the User or the Wallet Provider) covers the COTS platform, the certified WSCD/WSCA, mTLS availability of the Wallet Provider backend and WSCA/WSCD, account creation and identity proofing, protection of authentication secrets, trusted list and revocation list availability, and Wallet Provider responsibility for lifecycle maintenance and continued certification; "That table is normative and shall be mirrored, not restated, in the FIT ST" (§2.4, p. 9).

Who it applies to​

  • Scheme Owner: owns and governs the scheme; approves and publishes this document; maintains the register of authorised CBs and issued certificates; issues guidance and interpretations; maintains the central vulnerability register; normative basis "[to be confirmed]" (§3.1, p. 10). Coordinates vulnerability response and issues guidance (§6.4, p. 19). Periodically reviews and revises the document and notifies the relevant EU Cooperation Group of revisions where required (§6.7, p. 20).
  • Certification Body (CB): accredited by the National Accreditation Body under EN ISO/IEC 17065:2012 with a scope covering certification of the wallet at assurance level high (§3.2, p. 10). Minimum competence: two years of active certification experience under EN ISO/IEC 17065:2012 accreditation at assurance level high; technical knowledge of the wallet, threat model and methodology; five years for CBs wishing to develop or co-develop the scheme's technical content (§3.2, p. 10). Duties: manage the process from application through surveillance; review and approve the FIT ST; plan evaluations and issue the evaluation plan; engage laboratories and bear full responsibility for them (§3.2, p. 10); guarantee adequate fixed time budgets; issue mandatory written guidance to laboratories; issue, maintain, suspend and withdraw certificates; conduct initial and periodic audits of developer operational processes; report all incidents and vulnerabilities, regardless of severity, to the Scheme Owner; review delta assessments; handle complaints and appeals in the first instance; maintain records (§3.2, p. 11).
  • Evaluation Laboratory: fulfils EN ISO/IEC 17025:2017 for wallet evaluation activities at assurance level high, demonstrated by 17025 accreditation (primary and preferred) or through the engaging CB's 17065 accreditation arrangements (§3.3, p. 11). "Laboratory licensing floor (proposed)": 17025 accreditation covering either Common Criteria (ISO/IEC 15408 with ISO/IEC 18045) at EAL4 with AVA_VAN.3 or higher, or SESIP (EN 17927) at SESIP level 3 or higher, including evaluation of mobile applications (§3.3, p. 11). EN ISO/IEC 17020, 17021 or 17029 accreditation is not accepted as a substitute (§3.3, p. 11). Duties: perform assigned evaluation tasks per EN 17640:2022; act under CB responsibility (no independent certification role); prepare the ETR per Annex G of EN 17640:2022; participate in Evaluation Review Meetings; report vulnerabilities to the CB without undue delay; verify product identity (§6.2.1) and perform delta assessments (§6.6); maintain evaluator competence (§3.3, p. 11).
  • Product developer / sponsor: before evaluation, selects an authorised CB and applies; provides the FIT ST claiming conformance to the applicable Protection Profile; provides all evaluation evidence; provides source code to the laboratory as required by the Protection Profile; provides a risk assessment; provides the functional certificate (and, where available, the functional conformity assessment report) for the same product and exact same version (§3.4, p. 12). After certification: notifies the CB of critical vulnerabilities and active exploits within 24 hours and high-severity vulnerabilities within 72 hours; maintains a vulnerability management policy per EN ISO/IEC 30111:2019 and prepares Vulnerability Impact Analysis Reports; notifies the CB of all planned changes prior to implementation; maintains the functional certificate for the lifetime of the certificate of conformity; cooperates in surveillance; uses only the scheme's Trust Mark [to be confirmed] (§3.4, p. 12).
  • National Accreditation Body: accredits CBs (EN ISO/IEC 17065:2012) and Evaluation Laboratories (EN ISO/IEC 17025:2017) under Regulation (EC) No 765/2008 (§3.5, p. 12).
  • Market Surveillance Authorities: oversight of certified products in the market (§3.1, p. 10).

Contents​

  • Document control (cover data and history); p.2.
  • §1 Introduction (1.1 Purpose and scope, 1.2 Regulatory and normative basis, 1.3 Relationship to other schemes, 1.4 Terminology); p.5. Read
  • §2 Target of Evaluation (2.1 In scope, 2.2 Out of scope, 2.3 Architecture variants and admitted Protection Profiles, 2.4 Assumptions on the operational environment); p.8. Read
  • §3 Roles and responsibilities (Scheme Owner, CB, Evaluation Laboratory, product developer/sponsor, National Accreditation Body); p.10. Read
  • §4 Security requirements approach (Protection Profile, FSR/RSR, test to requirement mapping, required test set based on OWASP MAS); p.13. Read
  • §5 Evaluation methodology (methodology and assurance level, fixed time evaluation, evaluation effort table, module decomposition and composition); p.15. Read
  • §6 Certification process (overview of phases, functional certificate prerequisite and product identity verification, certificates and publication, incident and vulnerability management, suspension and withdrawal, delta assessment, scheme maintenance); p.17. Read
  • §7 Related scheme documents (NP001-EUDIW-C, NP002, NI002, NI003 with status); p.21. Read
  • Annex A: Glossary; p.22. Read
  • Annex B: References; p.24. Read
  • Annex C: Delta assessment evidence checklist (20 evidence items); p.26. Read
  • Colofon; p.28.

Key points​

  • Assurance level: "The assurance level is high and this is mandatory; substantial is not sufficient" (§1.1, p. 5). "The assurance level for the EUDI Wallet is high (CC AVA_VAN.3/SESIP3 equivalent) and this is mandatory" (§5.1, p. 15).
  • Methodology: "Evaluation is performed under FITCEM (EN 17640:2022), using CC or SESIP methodology" (§5.1, p. 15); EN 17927:2023 (SESIP) is an "Accepted alternative evaluation methodology and source of the assurance component semantics" (§1.2, p. 5).
  • "The complete wallet is expected to resist attackers with high attack potential"; source code shall be available as indicated in the Protection Profile (§5.1, p. 15).
  • Scheme type: EN ISO/IEC 17067:2013 "Type 5 scheme" (§1.2, p. 6); the process "follows the Type 5 certification system structure", combining third-party type testing with assessment of the developer's maintenance processes and post-certification surveillance (§6.1, p. 17).
  • Relationship to EU schemes: designed to be compatible with and complementary to the EU cybersecurity certification framework under the CSA, "including the EUCC and the future EUDI Wallet scheme(s)"; certificates under FITCEM-based schemes "are recognised assurance information under the criteria of Annex II" of CIR (EU) 2024/2981 (§1.3, p. 6).
  • It is a cybersecurity certification, not a functional conformity assessment, and does not substitute for one (§1.3, p. 6).
  • Protection Profile: security requirements are derived from a threat assessment and expressed in the applicable Protection Profile; the FIT ST (Wallet Security Specification, equivalent of a Security Target) claims conformance to it and instantiates it for the product (§4.1, p. 13; §1.4, p. 6).
  • The applicable Protection Profile is "FITCEM Protection Profile for EUDI Wallet Instance supported by a remote WSCA-WSCD, identification FITCEM-PP-WALLET-INSTANCE-for-REMOTE-WSCA-WSCD, version 0.2d, 20 August 2026, draft" ([PP-WI-REMOTE]), applying to the remote WSCA-WSCD variant only (§4.1, p. 13).
  • Security requirements are split into Functional Security Requirements (FSR) and Resilience Security Requirements (RSR) with a module decomposition; they "are inserted here by reference on issue of the Protection Profile and are not reproduced or invented in this document" (§4.2, p. 13).
  • Test to requirement mapping: every required test is mapped to the requirement it exercises; "a test run without a recorded target requirement does not contribute to assurance under this scheme"; the draft PP's mapping of each FSR and RSR to OWASP MAS shall be re-keyed to MASWE v1.0 identifiers before issue; keying the mapping to MASWE and to CIR 2024/2981 Section IV threat identifiers (TRnn) gives the scheme "an externally maintained coverage argument for its fixed scope"; "The full mapping table ... is inserted here on issue" (§4.3, p. 13).
  • Required test set is built on OWASP MAS (referenced, not reproduced): MASVS v2.1.0, MASWE v1.0, MASTG (current version), MAS testing profiles L1, L2, R, P with baseline "L2 + R + P" for assurance level high "[FOR REVIEW, see note below.]", plus the OWASP MAS EUDI Wallet profile (W), "Draft as at the date of this version and not yet normative" (§4.4, p. 14).
  • Fixed time: evaluation is performed within a fixed time budget; "the effort is fixed rather than scaled to functionality; more functionality raises the probability of findings within the fixed budget rather than extending the budget" (§5.2–5.3, p. 15).
  • Effort table (based on [TP-WI-BB], 8 h per person day "[assumption, to be confirmed]"): FSR subtotal 22 requirements, 690 h, 86.25 person days; RSR mandatory 13, 562 h, 70.25 days; RSR recommended 6, 174 h, 21.75 days; "Mandatory total (all FSR and mandatory RSR)" 35 requirements, 1252 h, 156.5 person days; total including recommended RSR 41, 1426 h, 178.25 person days (§5.3, p. 15).
  • Module decomposition: mandatory wallet core (attestation acquisition and presentation), WSCA/WSCD cryptographic device interface, remote electronic signing module (optional), presentation and proximity interface module, optional modules per architecture (HSM backed, embedded secure element, eSIM) (§5.4, p. 16).
  • Composition: "Common Criteria and SESIP certifications can be reused under the responsibility of the Certification Body"; where the PP places the WSCD in the operational environment, its certificate "is an environmental requirement rather than a composition input", and the laboratory records its identity, version and validity (§5.4, p. 16).
  • Functional certificate prerequisite: "A functional certificate is mandatory. A certificate of conformity shall not be issued under this scheme unless a valid functional certificate exists for the same product" — same product name, product identifier, version identifier and build or release identifier (§6.2, p. 17). It "is the output of the functional conformity assessment performed under the Functional Conformance Assessment Framework of the ARF"; an attestation is accepted if it identifies product and version unambiguously; it must be valid at the date of the certification decision (§6.2, p. 17).
  • "Functional conformity does not substitute for any part of the security evaluation"; testing is not reduced on that basis except where §6.6 and the PP permit reuse (§6.2, p. 18).
  • Product identity verification by the laboratory, from the delivered package itself (application identifier, version name and version code, signing certificate fingerprint; digest where available) (§6.2.1, p. 18); no positive certification decision without a positive identity result or an accepted positive delta conclusion (§6.2.1, p. 18).
  • Certificate validity: "The maximum certificate validity period is five years"; surveillance follows the periodic cycle consistent with Annex IX of CIR (EU) 2024/2981; the CB issues a Certificate of Conformity, publishes a Certification Report, and notifies the Scheme Owner for the public register (§6.3, p. 18).
  • Vulnerability handling: developer notifies critical vulnerabilities and active exploits within 24 hours, high-severity within 72 hours, "of other changes and vulnerabilities per the timeline in this document", maintains an EN ISO/IEC 30111:2019 policy and prepares VIARs; the CB assesses notifications and VIARs, reports all incidents and vulnerabilities to the Scheme Owner, decides on suspension or withdrawal; the Scheme Owner maintains the central vulnerability register (§6.4, p. 18–19).
  • Suspension and withdrawal: the CB "may suspend" where continued conformity is in doubt pending remediation; "shall withdraw" where non-conformity is permanent, unremediated within the required timeframe, or the developer ceases to maintain the product; loss of the functional certificate triggers assessment (§6.5, p. 19).
  • Delta assessment conclusions: Covered (previous results remain applicable in full), Partially covered (affected subset re-analysed and re-tested), Not covered (full evaluation required); "covered" and "partially covered" require all Annex C evidence; the CB may reject and require "not covered" (§6.6, p. 19).
  • Delta assessment is not used where the change alters the TOE boundary, operational environment assumptions, PP environmental requirements, or identity/version of a certified component relied on; changing the architecture variant or moving a function across the TOE boundary is "not covered" (§6.6, p. 19). Changes that shall not be concluded "covered" without new analysis and testing include changes to the Remote User Authentication Protocol, WSCA-BE/WSCD interface or WSCD status, key handling, attestation handling (WUA, WIA, KA), resilience mechanisms, trusted list/revocation/trust anchor handling, target platform API level, signing key or distribution channel (§6.6, p. 20). If not completed within the fixed budget, the conclusion is "not covered" (§6.6, p. 20).
  • Tool reuse in a delta assessment requires version identification, configuration control, continued applicability for state-of-the-art attacks at the high level, and demonstrated operation on the changed product (§6.6, p. 20).
  • Scheme maintenance: transition arrangements per revision shall specify effective date, timelines for new certifications, re-evaluation obligations and simplification provisions for certified products, and interaction with surveillance (§6.7, p. 20).

Process​

Phases per §6.1 table (§6.1, p. 17):

  1. Application — product developer: selects an authorised CB; submits application with FIT ST, risk assessment, evaluation plan proposal, functional certificate and prerequisite documentation.
  2. Evaluation planning — CB: reviews application; agrees evaluation plan with developer and laboratory; confirms laboratory scope; pins versions of referenced external specifications.
  3. FITCEM evaluation — Evaluation Laboratory: performs tasks per EN 17640:2022 and this document within the fixed time budget, under CB responsibility, including product identity verification (§6.2.1).
  4. Process audit — CB: initial audit of developer operational processes per audit instruction NI003.
  5. Evaluation Review Meeting — CB (optional): reviews findings, resolves open issues, confirms completeness; in person or virtual.
  6. Certification decision — CB certifying function: reviews ETR, any delta assessment and audit reports; takes decision; issues Certificate of Conformity and Certification Report.
  7. Post-certification — (actor not named in the table): periodic surveillance; change management; special evaluations triggered by changes or vulnerabilities; recertification.

Requirements in this document​

  • The document contains no numbered requirements of its own; security requirements are FSR and RSR in the Protection Profile, inserted by reference (§4.2, p. 13).
  • Counts (from the effort table): 22 FSR (7 covering T.USER_IMPERSONATION, 7 covering LEAKED_PRESENTATION_DATA, 8 standard priority), 13 mandatory RSR, 6 recommended RSR; 41 in total (§5.3, p. 15).
  • Required tests and the §4.3 mapping are identified by MASWE identifier (§4.4, p. 14); the mapping is keyed to MASWE and TRnn (§4.3, p. 13); the OWASP MAS EUDI Wallet profile (W) is dual-keyed to CIR 2024/2981 Section IV threat identifiers (§4.4, p. 14).
  • Annex C lists 20 numbered delta-assessment evidence items under Identification (1–3), Description of the change (4–7), Impact analysis (8–12), Reuse justification (13–17) and Conclusion (18–20) (Annex C, p. 26–27).
  • Parent framework NL-SYS-01 to NL-SYS-05 and NL-TL; related documents NL-CS part2, part3, part4, NL-CS-WI & NL-CS-WI-conditions, NL-WSCA & NL-WSCA-conditions (listed on the cover only) (p. 2).
  • Related scheme documents table: NP001-EUDIW-C (this document, "v0.9.4 for review"); NP002 Scheme procedures (Planned); NI002 Evaluation instruction for laboratories (Planned); NI003 Audit instruction for developer operational processes (Planned) (§7, p. 21).
  • [PP-WI-REMOTE] Protection Profile v0.2d (applicable PP) and [TP-WI-BB] Black-Box Penetration Testing Plan for the Wallet Instance v1.0, 16 October 2026 (effort estimate, "not an evaluation test specification") (Annex B, p. 25; §5.3, p. 15).
  • EU legal acts: Reg. (EU) 2024/1183 (European Digital Identity framework); Regulation (EU) 2019/881 (CSA; assurance levels); CIR (EU) 2024/2979 (integrity and core functionalities); CIR (EU) 2024/2981 Annex II (assurance level information requirements), Annex IX (surveillance cycle), Section IV (threat catalogue TRnn); CIR (EU) 2025/848 (registration of wallet-relying parties; bounds relying party interface assumptions); Regulation (EC) No 765/2008 (accreditation) (§1.2, p. 5–6); CIR (EU) 2024/482 (EUCC) (Annex B, p. 24).
  • Standards: EN 17640:2022 (FITCEM); EN 17927:2023 (SESIP); ISO/IEC 15408 and ISO/IEC 18045:2022 (Common Criteria / CEM); EN ISO/IEC 17065:2012 and 17025:2017; EN ISO/IEC 17067:2013 (Type 5); EN ISO/IEC 30111:2019 (vulnerability handling); OWASP MASVS v2.1.0, MASWE v1.0, MASTG, MAS profiles, MAS EUDI Wallet profile (§1.2, p. 5–6; Annex B, p. 24–25).
  • ARF and its FCAF: architecture reference and source of the required functional certificate (§1.2, p. 5; §6.2, p. 17).
  • [ENISA-EUDIW] draft candidate EU cybersecurity certification scheme for EUDI Wallets is listed in the references (Annex B, p. 24).

Notes on this draft​

  • The document does not describe the role or content of NL-CS part3 and part4, NL-CS-WI, NL-CS-WI-conditions, "NL-WSCA" or "NL-WSCA-conditions"; they appear only in the cover field "Related & Subsidiary Documents" (p. 2). The body does not mention NL-CS-WI and does not state whether [PP-WI-REMOTE] is that document (§4.1, p. 13).
  • The cover lists "NL-WSCA & NL-WSCA-conditions" (not "NL-CS-WSCA") (p. 2).
  • The cover box says the document "does not depend on other scheme documents for its normative content" (p. 2), while §4.2 and §4.3 state that requirements and the mapping table "are inserted here ... on issue" of the Protection Profile (§4.2–4.3, p. 13).
  • Dates/versions differ: cover "2026.10.25" (p. 1), Date "25/10/2026" (p. 2), history "24 October 2026" (p. 3); §7 gives this document's status as "v0.9.4 for review" (§7, p. 21) and the Colofon says "EUDI Wallet Scheme v0.9.4 for review" (p. 28), while the cover says RC1.0. Footer reads "NP001-EUDIW-C" (p. 2) while the cover reads "NP001-EUDIW" (p. 1).
  • §7 lists NP002 (Scheme procedures) as "Planned" (§7, p. 21), although NL-CS part2 is titled "Scheme Procedures NP002".
  • TOC contains the instruction "The table of contents is a Word field. Right click and Update Field to populate it." (p. 4).
  • Placeholders: Scheme Owner normative basis "[to be confirmed]" (§3.1, p. 10); Scheme Owner identity "[to be confirmed]" (Annex A, p. 22); Trust Mark "[to be confirmed]" (§3.4, p. 12; Annex A, p. 22); PP "identification and version to be confirmed" (§2.3, p. 8) and "identification to be confirmed" (Annex B, p. 25); "8 hours per person day [assumption, to be confirmed]" (§5.3, p. 15); ARF "[Version to be pinned.]" (Annex B, p. 24); laboratory licensing floor marked "(proposed)" (§3.3, p. 11).
  • "see the note below" (§4.1) and "[FOR REVIEW, see note below.]" (§4.4) refer to notes that are not present (§4.1, p. 13; §4.4, p. 14).
  • §5.2 is titled "Fixed time evaluation and the finding termination rule" but does not state the finding termination rule (§5.2, p. 15).
  • §6.4 refers to "other changes and vulnerabilities per the timeline in this document", but no such further timeline is given (§6.4, p. 18).
  • §6.5 refers to "the required timeframe" for remediation without specifying it (§6.5, p. 19).
  • §6.2 defines the functional certificate as the output of the ARF's FCAF (§6.2, p. 17); the document does not mention NL-FS.
  • Glossary term "TR1: The certification system against which the scheme is admitted and supervised" is not used elsewhere in the document (Annex A, p. 22).
  • §6.3 states no surveillance intervals; it states that surveillance "follows the periodic cycle consistent with Annex IX of Commission Implementing Regulation (EU) 2024/2981" (§6.3, p. 18).

Sources​