Skip to main content

NL-CS-WSCA conditions: Conditions for the Underlying Platform Supporting AVA_VAN.5 Evaluation

NL-CS-WSCA conditions: Conditions for the Underlying Platform Supporting AVA_VAN.5 Evaluation

Download PDF (2.4 MB, 31 pages)Read the full text110 requirements
Cover page of the document, as printed
Document referenceNL-WSCA-condtions
VersionRC1.1
StatusRelease Candidate
Date29/10/2026
Document typeConditions in support of a WSCA for the Underlying Platform Supporting AVA_VAN.5 Evaluation
Parent frameworkNL-CS (parts1/2/3/4)
Scheme OwnerKingdom of the Netherlands Minister of Economic Affairs
Certification targetEuropean Digital Identity Wallets
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​

The document defines the security requirements and protection principles for the underlying platform on which the Wallet Secure Cryptographic Application (WSCA) operates (§1.1, p. 6). Because the WSCA is a software-only product evaluated against AVA_VAN.5, its security depends on the underlying operating platform, and a weakness in that platform could let an attacker bypass the WSCA's security mechanisms and undermine the AVA_VAN.5 assurance claim (Abstract, p. 4); (§1.1, p. 6). The document "establishes the security conditions that the underlying platform must satisfy so that vulnerabilities or weaknesses in the platform do not undermine the security objectives or the overall assurance level of the WSCA" (Abstract, p. 4). The requirements establish "the minimum-security conditions for the underlying platform and operational environment to support the WSCA's AVA_VAN.5 evaluation" (§1.1, p. 6).

Scope and object of certification​

  • The WSCA is described as "the security-critical software component of the EUDI Wallet responsible for protecting and performing cryptographic operations and managing security-sensitive assets" (Abstract, p. 4).
  • Under Commission Implementing Regulation (EU) 2024/2981 the WSCA is subject to a high level of vulnerability analysis, "with AVA_VAN.5 defined as the default assessment level" (Abstract, p. 4).
  • The object of this document is not the WSCA itself but (a) the operational environment in which the WSCA is deployed (Section 2) and (b) the underlying platform, defined as "the complete software and hardware environment required to execute and protect the software-only WSCA" (§2, p. 8); (§3, p. 10).
  • The underlying platform consists of layers, each providing functionality and security mechanisms required by the layers above it: Hardware / Host System, Boot and Initialisation Layer, Operating System Kernel, Operating System / System Services, Application Space, Container / Isolation Layer, and WSCA Execution Environment (§3, p. 10); (§3.1–3.7, p. 10–11).
  • The requirements cover, as applicable, minimal configuration, restricted execution, least privilege, process isolation, memory protection, controlled interfaces, platform integrity and vulnerability management (§1.1, p. 6).
  • The operational environment shall provide physical, administrative and operational controls, including as applicable physical protection of the servers and WSCD, controlled access to the environment, and protection of supporting infrastructure and network connections; it forms "an additional layer of protection" (§1.1, p. 6).
  • Section 6 applies the requirements to a Linux-based underlying platform (§6, p. 22).

Who it applies to​

  • Scheme Owners, Evaluation Laboratories, CABs and EUDI Wallet providers are named as primary audience; EUDI Wallet ecosystem stakeholders as secondary audience (metadata table, p. 2).
  • Administrators: are "appropriately trained, follow established policies and guidance, and are trusted to act without malicious intent"; they ensure passwords and credentials have sufficient strength and entropy (ENV-TRUSTED-ADMIN, §2, p. 9). Access to firmware and boot configuration shall be restricted to authorised administrators (Linux) (BOOT-03, §6.3, p. 26).
  • Authorised personnel: physical access to the environment of the TOE and its underlying platform shall be restricted to authorised personnel (ENV-ENVIRONMENT, §2, p. 9); access to firmware configuration, boot interfaces and hardware configuration functions is restricted to authorised personnel or authorised management mechanisms (BOOT-06, §5.2, p. 16).
  • The developer: "shall select an appropriate combination of mechanisms based on the platform architecture", and the selected mechanisms "shall be properly justified as providing the required security properties" (§6, p. 22).
  • The underlying platform: each of the 13 security principles is phrased as an obligation on it ("The underlying platform shall …") (§4, Table 2, p. 12–13).
  • SGS Brightsight (ITSEF and CB) is named as author (§1.2, p. 6).

Contents​

  • Cover, metadata table, history of changes — p.1–3 (p. 1–3).
  • Abstract — why the platform under a software-only WSCA needs defined security requirements to support AVA_VAN.5; starts p.4 (Abstract, p. 4).
  • Table of Contents — p.5 (ToC, p. 5).
  • 1 Introduction — security problem definition (1.1), document identification (1.2) and structure of the document (1.3); starts p.6 (§1, p. 6).
  • 2 Security requirements Operational Environment — Figure 1 and Table 1 with the six ENV-requirements for the environment around the WSCA and its platform; starts p.8 (§2, p. 8).
  • 3 High-Level layered Design of the Underlying Platform — Figure 2 and a description of the seven platform layers (3.1–3.7); starts p.10 (§3, p. 10).
  • 4 Security Principles for the Underlying Platform — Table 2 with 13 numbered security principles (01–13); starts p.12 (§4, p. 12).
  • 5 Requirements for the Underlying Platform — per layer, 13 requirements (one per principle) in seven tables: 5.1 Hardware (p.14), 5.2 Boot and Initialisation Layer (p.15), 5.3 Operating System Kernel (p.16), 5.4 Operating System / System Services (p.17), 5.5 Application Space (p.18), 5.6 Container / Isolation Layer (p.19), 5.7 WSCA Execution Environment (p.20); starts p.14 (§5, p. 14); (§5.1–5.7, p. 14–20).
  • 6 Application of the Requirements for the Linux-Based Underlying Platform — 6.1 Table 3 mapping Linux and hardware security mechanisms to purposes and layers (p.22), then 6.2–6.8 giving a Linux implementation for each requirement per layer: 6.2 Hardware / Host System (p.24), 6.3 Boot and Initialisation (p.26), 6.4 Operating System Kernel (p.26), 6.5 Operating System / System Services (p.28), 6.6 Application Space (p.28), 6.7 Container / Isolation Layer (p.29), 6.8 WSCA Execution Environment (p.30); starts p.22 (§6, p. 22); (§6.1–6.8, p. 22–30).
  • The Table of Contents lists no annexes (ToC, p. 5).

Key points​

  • The document uses a "step-by-step, layered approach": operational environment first, then platform components, then security principles, then detailed security requirements (§1.3, p. 6–7).
  • "No applications, services, workloads or processing functions unrelated to the WSCA shall be installed or operated on the hardened platforms and on top dedicated hardware. Consequently, deployment of the WSCA as a shared cloud application is not permitted." (ENV-DEDICATED_PLATFROM, §2, p. 8).
  • The platform enforces dual control for administrative tasks so that a single administrator cannot perform sensitive or potentially malicious actions alone (ENV-TRUSTED-ADMIN, §2, p. 9).
  • The WSCA platform shall not be directly exposed to the Internet; external communication is mediated through a gateway platform that implements at least DDoS protection, intrusion detection, antivirus functionality and firewall functionality (ENV-GATEWAY, §2, p. 9).
  • The WSCD and security-relevant databases shall be located in the same protected operational environment as the WSCA platform and shall not be directly accessible from untrusted networks (ENV-DATABASE, §2, p. 9).
  • Channels between the WSCA and the WSCD and between the WSCA and the gateway platform shall be authenticated and encrypted and prevent unauthorised interception, modification, replay or impersonation; the WSCA–WSCD channel "shall use a dedicated physical connection, isolated from all other computer systems" (ENV-WSCD-CHANNEL, §2, p. 9).
  • The TOE and its underlying platform shall be in a physically secured environment; physical security measures shall protect the WSCA, WSCD, the databases and the gateway, "including attacks within the scope of the AVA_VAN.5 vulnerability assessment" (ENV-ENVIRONMENT, §2, p. 9).
  • The 13 security principles are: 01 Minimal Configuration, 02 Limited Execution, 03 Least Privilege, 04 Process Isolation, 05 Memory Protection, 06 Controlled Interfaces, 07 Platform Integrity, 08 Network Protection, 09 WSCA Data Protection, 10 Privilege Escalation Protection, 11 Security-Relevant Logging, 12 Vulnerability Management, 13 Cyber Security Monitoring (§4, Table 2, p. 12–13).
  • Each Section 5 requirement is derived from a Section 4 principle; the requirements "translate these principles into concrete security objectives and controls for the individual platform layers" (§5, p. 14).
  • Hardware: where supported, a hardware root of trust, TPM, measured boot or Secure Boot shall be used to support verification of platform integrity during initialisation (HW-07, §5.1, p. 14); firmware and microcode are subject to a defined vulnerability-management process (HW-12, §5.1, p. 15).
  • Boot: the boot process shall verify the authenticity and/or integrity of firmware, bootloader and operating system components before execution; where supported, Secure Boot, measured boot or equivalent shall be enabled (BOOT-07, §5.2, p. 16); network functionality during the boot and initialisation process shall be disabled unless required for a defined platform function (BOOT-08, §5.2, p. 16).
  • Kernel: the kernel shall prevent unauthorised kernel modules, drivers or other privileged code from being loaded or executed (KERN-02, §5.3, p. 17) and enforce memory isolation, with hardware-assisted memory protection enabled where available (KERN-05, §5.3, p. 17).
  • System services: only services required for the secure operation, administration and maintenance of the WSCA shall be installed and enabled (OS-01, §5.4, p. 18); unneeded network-facing services shall be disabled and their ports not exposed (OS-08, §5.4, p. 18).
  • Application space: only applications and utilities required for operation, administration and maintenance of the WSCA environment shall be installed (APP-01, §5.5, p. 18); application allow-listing or equivalent controls shall be applied where technically feasible (APP-02, §5.5, p. 19).
  • Containers: privileged containers shall not be used "unless explicitly justified and authorised" (CONT-03, §5.6, p. 19); container processes shall be prevented from escaping their isolation boundary (CONT-10, §5.6, p. 20).
  • WSCA execution environment: the WSCA shall execute with the minimum operating system and platform privileges required (WSCA-03, §5.7, p. 20) and network communication from the WSCA shall be restricted to explicitly authorised endpoints and protocols (WSCA-08, §5.7, p. 21).
  • Every layer has a Cyber Security Monitoring requirement (xx-13) under which detected or collected security-relevant events are reported or made available to the platform's security monitoring mechanisms (with the purposes worded per layer, e.g. analysis and alerts for HW-13, investigation and response for BOOT-13, analysis, alerting and incident response for OS-13) (HW-13, p. 15); (BOOT-13, p. 16); (KERN-13, p. 17); (OS-13, p. 18); (APP-13, p. 19); (CONT-13, p. 20); (WSCA-13, p. 21).
  • For Linux: "Not all mechanisms must be used. The developer shall select an appropriate combination of mechanisms based on the platform architecture"; selected mechanisms shall be properly justified and "equivalent mechanisms may be used where appropriate" (§6, p. 22).
  • For Linux the WSCA shall run under a dedicated non-root Linux account with only the required capabilities (WSCA-03, §6.8, p. 31); services shall run under dedicated non-root accounts (OS-03, §6.5, p. 28).
  • For Linux, "Privileged containers shall not be used. CAP_SYS_ADMIN and other unnecessary capabilities shall be removed." (CONT-10, §6.7, p. 30).
  • For an AVA_VAN.5 evaluation "the container boundary should therefore not be treated as an independent security mechanism. Its security depends substantially on the correct configuration of the Linux kernel and container runtime." (§6.7, p. 29).
  • The WSCA execution environment layer "should provide the closest and most direct protection of the WSCA" and is "particularly relevant when demonstrating that the underlying platform does not introduce an attack path that would undermine the WSCA's AVA_VAN.5 assessment" (§6.8, p. 30).
  • Table 3 lists 49 Linux and hardware security mechanisms (e.g. UEFI Secure Boot, TPM 2.0, SELinux, AppArmor, seccomp, namespaces, cgroups, systemd controls, nftables, LUKS2/dm-crypt, auditd, SIEM integration), each with its primary security purpose and relevant platform layer (§6.1, Table 3, p. 22–24).

Figures​

  • Figure 1 — WSCA in Its Environment (§2, p. 8): a dashed box labelled "Secure Environment" contains the WSCD, a "Hardened Platform" box with the WSCA inside it, a "Gateway server" and a "Data base". A two-way arrow connects the WSCD with the Hardened Platform; a two-way arrow connects the Data base with the Hardened Platform. A line from the "Wallet Provider Backend" (outside the Secure Environment, arrowhead at the Backend) runs down into the Gateway server box and ends in an arrow into the Hardened Platform; a "Wallet Instance" (outside) is connected, via a cloud symbol, by a two-way arrow drawn across the Gateway server box to the Hardened Platform (Figure 1, p. 8).
  • Figure 2 — High-Level Design of the Underlying Platform (§3, p. 10): the same environment, with the platform box labelled "Hardened Server" showing a stack (top to bottom) of WSCA, Container / Isolation Layer, Application Space, Operating System / System Services, Operating System Kernel, Boot and Initialisation Layer, Hardware; WSCD, Gateway server, Data base, Wallet Provider Backend and Wallet Instance are connected as in Figure 1 (Figure 2, p. 10).

Process​

The document describes the step-by-step, layered approach by which it identifies the security measures: (1) consider the operational environment, (2) identify the components of the underlying platform, (3) establish the security principles for these components, (4) translate the principles into detailed security requirements (§1.3, p. 6–7); Section 6 then shows how these can be implemented on Linux (§1.3, p. 7).

Requirements in this document​

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

  • NL-CS (parts1/2/3/4): parent framework (metadata table, p. 2).
  • NL-WSCA and NL-WI (-conditions): related documents (metadata table, p. 2).
  • Commission Implementing Regulation (EU) 2024/2981: basis for the WSCA being subject to a high level of vulnerability analysis with AVA_VAN.5 as default assessment level (Abstract, p. 4).
  • CIR 2015/1502 (identity proofing) and EU Regulation 2019/881 (evaluation): cited for the assurance level High/High (metadata table, p. 2).
  • AVA_VAN.5: the vulnerability assessment level the platform conditions support (Abstract, p. 4); (§1.1, p. 6).
  • Technologies such as UEFI, TPM 2.0, SELinux, AppArmor, seccomp, systemd, nftables and LUKS2 are named as mechanisms in Table 3 (§6.1, Table 3, p. 22–24).

Notes on this draft​

  • Document reference on p.2 is spelled "NL-WSCA-condtions" (sic); the cover header reads "NL-WSCA-conditions" (p. 1); (p. 2).
  • Dates and versions differ: cover "2026.10.29" (p. 1); metadata Date "29/10/2026" (p. 2); history RC1.1 dated "2026-10-31" (p. 3); §1.2 gives "Version: 0.7" and "Date: Tuesday, 27 October 2026" (§1.2, p. 6).
  • The §1.2 title "Security Requirements for the Underlying Platform of the WSCA Supporting AVA_VAN.5 Evaluation" differs from the cover title "Conditions for the Underlying Platform Supporting AVA_VAN.5 Evaluation" (§1.2, p. 6); (p. 1).
  • The history table on p.3 contains a third row rendered collapsed, with clipped text; its extractable text duplicates the RC1.1 row (Release Candidate, 2026-10-31) (history table, p. 3).
  • Identifier "ENV-DEDICATED_PLATFROM" is spelled with "PLATFROM" and an underscore, unlike the hyphenated other ENV identifiers (§2, p. 8).
  • ENV-ENVIRONMENT refers to "The TOE and its underlying platform"; this is the only occurrence of "TOE" in the document (§2, p. 9).
  • ENV-WSCD-CHANNEL reads (with no "and" between "the WSCA" and "the gateway platform"): "Communication channels between the WSCA and the WSCD and the WSCA the gateway platform shall be authenticated and encrypted" (§2, p. 9).
  • Table 2 column heading reads "Security Principal description" (sic) (§4, p. 12–13).
  • §1.3 repeats the Section 3 title: "Section 3 —High-Level layered Design of the Underlying Platform: High-Level layered Design of the Underlying Platform: describes …" (§1.3, p. 7).
  • Figure 1 labels the platform "Hardened Platform" while Figure 2 labels it "Hardened Server" (Figure 1, p. 8); (Figure 2, p. 10). In Figure 2 the top box of the stack is labelled "WSCA"; no box is labelled "WSCA Execution Environment", the layer described in §3.7 (Figure 2, p. 10); (§3.7, p. 11).
  • §6 says "Not all mechanisms must be used" and "equivalent mechanisms may be used where appropriate", while the Linux implementation rows in §6.2–6.8 are phrased with "shall" (e.g. "Linux disk encryption, such as LUKS2, shall be used where protection of data at rest is required") (§6, p. 22); (HW-09, §6.2, p. 25).

Sources​