Skip to main content

NL-CS-WI conditions: Conditions on the Underlying Mobile System for Wallet Instances in a remote HSM architecture

NL-CS-WI conditions: Conditions on the Underlying Mobile System for Wallet Instances in a remote HSM architecture

Download PDF (2.1 MB, 14 pages)Read the full text12 requirements
Cover page of the document, as printed
Document referenceNL-WI
VersionRC1.1
StatusRelease Candidate
Date20/10/2026
Document typeCertification Scheme Conditions on the Underlying Mobile System for Wallet Instances in a remote HSM architecture
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 lists the requirements, following a risk analysis, that a mobile device, referred to as the User Device, must fulfil to provide an adequately secure operating environment for an EUDI Wallet Instance (§1, p. 5). It exists because the security of the Wallet Instance cannot be established solely through evaluation of the wallet application; it also depends on the security capabilities, configuration and lifecycle support of every mobile device on which the Wallet Instance is permitted to run (§1, p. 5). Collectively, the controls are intended to protect the Wallet Instance against attackers with high attack potential, including attackers capable of remote exploitation or physical access to the device (§1, p. 5).

Scope and object of certification​

  • Object of the conditions: the User Device (UD), the mobile device on which an EUDI Wallet Instance operates and which forms the foundational security layer of the Wallet Unit (§1, p. 5).
  • Architecture context: critical cryptographic operations and long-term key material may be protected by remotely operated Wallet Secure Cryptographic Applications and Devices, but the Wallet Instance still relies on its mobile device to protect locally processed authentication factors, personal data, attestations, transaction information and security-relevant application data (§1, p. 5).
  • Topics covered: vulnerability management, protection against exploitation, trusted firmware, secure generation of random values, secure cryptographic implementations, hardware-backed isolation of cryptographic keys, application sandboxing, integrity attestation, device access control, protection of stored data, secure networking and preservation of user privacy (§1, p. 5).
  • The word "Conditions" appears in the title and document type; the body uses "requirements" and "security controls", each control having a "Requirements" and an "Evaluation criteria" subsection (cover, p. 1; Document control, p. 2; §1, p. 5; §2, p. 6).

Who it applies to​

  • User Device (UD): the subject of every "Requirements" clause ("The UD shall …") (§2.1–2.12, p. 6–11).
  • Wallet Instance (WI): the WI shall obtain integrity attestations for the app and possibly OS at runtime (§2.8.2, p. 10); SC-04 criteria address RNGs used under control of the WI or whose outputs are accessible to the WI (§2.4.2, p. 7); known-answer testing covers primitives provided by the UD and used by the WI (§2.5.2, p. 8). Other runtime checks (e.g. OS version / security patch level, secure lock screen) are stated without naming an actor (§2.1.2, p. 6; §2.9.2, p. 11).
  • The wallet's design / Wallet Provider Backend: the wallet's design shall be capable of revoking WIs when the associated UD can no longer ensure its security, for example by associating the WI with device information in the Wallet Provider Backend (§2.1.2, p. 6).
  • Trusted environment ("never in the UD itself"): validates key attestations and integrity attestations (§2.6.2, p. 8; §2.8.2, p. 10).
  • Opposite connection end of the WI: shall perform server-side checks that the correct protocols are used in a standard-compliant way (§2.11.2, p. 11).
  • Audiences named in the Document control table: Scheme Owners, Evaluation Laboratories, CABs, EUDI Wallet providers, and EUDI Wallet ecosystem stakeholders (Document control, p. 2). The document does not state which actor performs the "due diligence" criteria.

Contents​

Key points​

  • SC-01: the UD shall receive regular, timely security updates addressing disclosed vulnerabilities in its first- and third-party components (§2.1.1, p. 6); the OS version / security patch level shall be checked at runtime, and the wallet's design shall be capable of revoking WIs when the UD can no longer ensure its security (e.g. known exploits or significantly out of date) (§2.1.2, p. 6).
  • SC-02: the UD shall follow best practices to protect against hardware and software vulnerabilities, like memory corruption attacks and supply chain attacks; evaluated by due diligence, e.g. review of platform documentation (§2.2, p. 6).
  • SC-03: code executed with elevated privileges (bootloader, kernel, OS, TEE) shall be trusted and cannot be rolled back to a less secure version (§2.3.1, p. 6); where secure boot is not always enforced, its activation status shall be checked at runtime; unpatchable exploits, e.g. in the boot-up sequence, may make this control unenforceable (§2.3.2, p. 7).
  • SC-04: the UD shall implement an RNG providing unpredictable randomness to generate cryptographic keys and nonces, with each output of the RNG being only accessible to a single app (§2.4.1, p. 7). Evaluation criteria: (1) for RNGs under control of the WI, where available, UD APIs shall be used to determine that the security strength is sufficient (e.g. at least 128 bits); (2) where no strength information is available at runtime but outputs are accessible to the WI, runtime health tests shall be performed; (3) where runtime checks are not available, where possible, primitives and protocols that do not rely on strong randomness shall be used (e.g. nonce-reuse resistant block cipher modes, deterministic signature schemes); (4) where runtime checks and deterministic schemes are not possible, due diligence shall be done, e.g. via platform documentation and available security certifications (§2.4.2, p. 7).
  • SC-05: the UD shall provide standard-compliant and vulnerability-free implementations of cryptographic primitives not implemented by the wallet app; known-answer testing shall be performed for all UD primitives used by the WI (§2.5, p. 7–8).
  • SC-06: the UD shall provide an isolated environment for keys with key generation, storage, deletion/zeroization and use; no export; key attestations; and purposeful design against physical and logical tamper and side-channel attacks (§2.6.1, p. 8).
  • SC-06: the environment shall be a dedicated SE or a hardware-backed TEE; for TEEs three additional requirements apply: only trusted code with secure boot, strongly isolated memory, and retention of security properties if the rich OS is compromised (§2.6.1, p. 8).
  • SC-06 evaluation: runtime checks that critical key material is in an SE or TEE; key attestations obtained at runtime and validated in a trusted environment, never in the UD itself; if considered necessary for additional assurance, due diligence via an off-device analysis of whether the SE/TEE meets the security level required by the considered attacker model (§2.6.2, p. 8).
  • SC-06 assurance guidance: a valid certificate traceable to the UD (named examples: EUCC, FIPS 140-3, SESIP, GlobalPlatform) (§2.6.2, p. 8–9); for SEs, a composite certificate covering the hardware platform and a concrete application is ideal, and for the highest assurance the hardware itself should have a valid EUCC certificate against PP0084 or PP0117 (§2.6.2, p. 9); without a certificate, assurance can be obtained e.g. via independent functional and penetration testing and other publicly available information (§2.6.2, p. 9); for TEEs, ten properties (a–j), "among others", may be used as additional indicators, such as hardware isolation, small auditable code base, vendor support and vulnerability history (§2.6.2, p. 9).
  • The document notes that the required non-exportability of keys is usually not covered by certifications of the hardware platform but is rather a property of composite certifications (§2.6.2, p. 9), and that "independent security certifications provide assurance in the fulfilment of security requirements, but do not necessarily result in a more secure product overall" (§2.6.2, p. 9).
  • SC-07: the UD shall be able to or provide means to isolate app processes, memory, cryptographic keys and data from unauthorized accesses by other apps or system services, including side channels, drawing on top of other running apps, abuse of accessibility services, and unwanted use by the UD itself (backups, personalization) (§2.7.1, p. 10); where applicable to the UD, runtime measures against other processes drawing on top of the wallet UI and against access to sensitive wallet data by other apps, plus due diligence on a non-bypassable app sandbox (§2.7.2, p. 10).
  • SC-08: the UD shall implement a hardware-supported attestation mechanism proving app integrity at runtime, and, where OS modifications are likely, provide support in obtaining OS integrity attestations; the WI shall obtain integrity attestations for the app and possibly OS at runtime, validated in a trusted environment (§2.8, p. 10).
  • SC-09: the UD shall implement a hardware-backed lock screen requiring authentication before granting full access to the device that is resistant to bypass; runtime checks shall enforce that it is activated (§2.9, p. 10–11).
  • SC-10: the UD shall protect app data stored at rest from extraction in plaintext by use of a secure memory encryption algorithm; on UDs whose OS does not always enforce memory encryption, its activation status shall be checked at runtime on every storage media where WI data is stored persistently; where information about the security strength of the algorithm (e.g. "use of at least XTS-AES with at least 128-bit keys") is not available at runtime, due diligence shall be done instead (§2.10, p. 11).
  • SC-11: the UD shall provide mechanisms preventing all unencrypted/plaintext networking and secure implementations of current network protocols (e.g. TLS 1.3) used for transactions, when not implemented by the wallet app itself; runtime checks plus server-side checks by the opposite connection end (§2.11, p. 11).
  • SC-12: the UD shall not monitor apps or provide means to track app users in a way that discloses sensitive information about the wallet to the UD's vendor or third parties; evaluated by due diligence (§2.12, p. 11–12).
  • Platform API examples are given for iOS (e.g. UIDevice.current.systemVersion, CryptoKit, App Attest, LocalAuthentication, Network.framework) and Android (e.g. android.os.Build.*, SecureRandom, KeyInfo, HIDE_OVERLAY_WINDOWS, filterTouchesWhenObscured, isAccessibilityDataSensitive, Play Integrity API, KeyguardManager, DevicePolicyManager, NetworkSecurityPolicy) as illustrations ("for example") (§2.1.2, p. 6; §2.4.2, p. 7; §2.6.2, p. 8; §2.7.2, p. 10; §2.8.2, p. 10; §2.9.2, p. 11; §2.10.2, p. 11; §2.11.2, p. 11).

Requirements in this document​

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

  • Parent framework: NL-CS (parts1/2/3/4) (Document control, p. 2).
  • Related Documents: NL-WI; NL-WSCA (-conditions) (Document control, p. 2).
  • Reference [1]: Android 17 Compatibility Definition, Google (§4, p. 14). Reference [2]: TEE Protection Profile v1.3 | GPD_SPE_021, GlobalPlatform, v1.3, 2020-09 (§4, p. 14).
  • In the text, "[1]" is attached to "the GlobalPlatform TEE Protection Profile" (TEE certifications) and "[2, 9.11.2]" to the statement that for Android 17 the CDD requires any StrongBox KeyMint to be evaluated/certified according to PP0084/PP0117 or a similar scheme (§2.6.2, p. 9).
  • Certification schemes and Protection Profiles named as sources of assurance: EUCC, FIPS 140-3, SESIP, GlobalPlatform; PP0084, PP0117 (§2.6.2, p. 8–9).
  • Cover: CIR 2015/1502 and EU Regulation 2019/881 (assurance level High/High) (Document control, p. 2). No other EU legal act is cited in the body (§1–4, p. 5–14).

Notes on this draft​

  • Identifier inconsistency: cover "NL-WI-conditions" but Document reference "NL-WI"; Related Documents also lists "NL-WI"; footer reads "Requirements for Wallet Instances | RC1.1" (cover, p. 1; Document control, p. 2; footer, p. 2–14).
  • Date inconsistency: cover "2026.10.20" and Document control "20/10/2026", while the history of changes dates RC1.0 "2026-10-27" and RC1.1 "2026-10-31", both later than the document date (cover, p. 1; Document control, p. 2; history of changes, p. 3).
  • The history table's text layer contains a third, overlapping "RC1.1 … Release Candidate 2026-10-31" row that is not legible in the rendered page (history of changes, p. 3).
  • Reference numbering does not match the reference list: the text cites "the GlobalPlatform TEE Protection Profile [1]" and "[2, 9.11.2]" for the Android 17 CDD, whereas [1] is the Android 17 Compatibility Definition and [2] is the GlobalPlatform TEE Protection Profile (§2.6.2, p. 9; §4, p. 14).
  • Typos/wording: "This document list the requirements" (§1, p. 5); heading "SC-10 – Stored data confidentially" (§2.10, p. 11); "proving the required security properties that traceable to the UD" (§2.6.2, p. 8); "implemented mechanisms protection from local and remote attacks" (§2.2.2, p. 6).
  • The guidance in SC-06 starts with "1. Presence of a valid … certificate" and then interposes "Examples of certification schemes … a./b." and a note before items 2 and 3 (§2.6.2, p. 8–9).
  • SC-03 evaluation criterion 2 uses wording close to SC-02 evaluation criterion 1 (due diligence via review of platform documentation related to implemented mechanisms for protection against local and remote exploits, regarding new or unpatchable exploits) (§2.2.2, p. 6; §2.3.2, p. 7).
  • Several criteria are conditional or optional ("If considered necessary for additional assurance" (§2.6.2, p. 8); "where available", "where possible" (§2.4.2, p. 7)); the document does not state who decides.
  • The document does not state which party (evaluator, wallet provider or other) performs the evaluation criteria; "remote HSM architecture" appears only in the title and document type and is not further described (cover, p. 1; Document control, p. 2; §1, p. 5).
  • Abbreviation "IOT" is listed and SESIP expanded as "Security Evaluation Standard for IOT Platforms" (§3, p. 13).

Sources​