Skip to main content

NL-CS-WI requirements

This page lists every requirement of NL-CS-WI (EN 17640 FITCEM Protection Profile for EUDI Wallet Instance in a remote HSM architecture, version RC1.1) as published on 6 November 2026. The PDF is authoritative: each requirement links to the page it is on. You can also read the full text or search all requirements.

41 entries: 22 functional security requirements (FSR), 19 resilience security requirements (RSR). Obligation: 35 mandatory, 6 recommended.

Legal basis of the document: eIDAS Art. 5a, CIR 2024/2979, CIR 2024/2981.

Referenced in the document but not defined in it: FSP_REMOTE_AUTH, FSR_SELECTIVE_DISC.

3.1 WI-(TOE) Functional Security Requirements​

Read section 3.1 in the full text

FSR_WI_INSTALL — Wallet Instance Installation and Activation​

The WI-(TOE) shall be installed through an official application distribution channel (e.g. Google Play Store or Apple App Store) or through another distribution mechanism providing equivalent protection for the authenticity and integrity of the TOE. The WI-(TOE) shall:

  • During installation and activation, the TOE shall establish the required association with the Wallet Provider and shall securely provide the required initial information to the Wallet Provider. This information shall include, where applicable:
    • a unique identifier for the Wallet Instance;
    • the device model and operating-system version; and
    • the characteristics of the available keystores and WSCDs required to determine their suitability.
  • The TOE shall protect the confidentiality, integrity and authenticity of the initial information exchanged with the Wallet Provider.
  • The TOE shall verify that the installed TOE version and the underlying operating-system environment meet the applicable minimum-security requirements before activating the Wallet Instance.
  • If the TOE or operating-system environment does not meet the applicable security requirements, the TOE shall prevent activation or security-sensitive Wallet Unit operations and shall inform the User.
  • During activation, the TOE shall establish the required User authentication mechanisms in accordance with FSR_LOCAL_AUTH and FSP_REMOTE_AUTH. The WI-(TOE) shall provide a User-initiated factory reset function. Upon factory reset, the TOE shall:
  • delete the PIDs and electronic attestations held by the Wallet Instance;
  • delete transaction logs and Wallet Instance configuration and settings;
  • request secure deletion of associated cryptographic assets from the WSCA/WSCD and applicable secure keystores;
  • prevent the deleted Wallet Unit data and cryptographic assets from being subsequently used by the Wallet Instance; and
  • inform the User of the consequences of performing the factory reset before the reset is executed.

Functional security requirement (FSR) · obligation: mandatory · PDF page 31

FSR_WIA — Wallet Instance Attestation​

The WI-(TOE) maintains and protects the Wallet Instance Attestation (WIA) and presents the WIA to PID Providers and Attestation Providers as required, enabling them to verify the security properties and status of the Wallet Unit. The TOE shall:

  • obtain the WIA from the Wallet Provider through an authenticated and integrity-protected communication channel;
  • verify the authenticity and integrity of the WIA before using or presenting it;
  • ensure that the WIA applies to the corresponding Wallet Instance;
  • verify that the WIA is technically valid and has not expired before use;
  • verify the revocation status of the Wallet Instance as indicated by the WIA before use, where required by the applicable ARF and technical specifications;
  • protect the WIA against unauthorized disclosure, modification, replacement and replay; and
  • use the WIA only for the applicable issuance processes and in accordance with the applicable OID4VCI requirements. The TOE shall provide the Wallet Instance Attestation together with the required Proof-of-Possession (PoP) during issuance, as specified by OID4VCI. The technical validity period of a WIA shall be less than 24 hours, measured from the time at which the Wallet Provider verified the integrity of the Wallet Instance to the expiry time indicated in the WIA. The technical validity period shall not be confused with the period for which the Wallet Provider maintains the revocation status of the Wallet Instance. If a WIA is stored in the private storage of the TOE, the WIA shall be protected against unauthorized access, modification and deletion. The TOE shall verify its integrity and validity before use. The TOE must prove its integrity to the Wallet provider before the Wallet provider generates a WIA.

Functional security requirement (FSR) · obligation: mandatory · PDF page 33

FSR_KEY_ATTEST — Key Attestation​

The WI-(TOE) maintains and protects Key Attestations (KA) and presents KAs to PID Providers and Attestation Providers, where required, to provide evidence of the security properties of the keys used by the Wallet Unit. The TOE shall:

  • verify the authenticity and integrity of a KA before using or presenting it;
  • ensure that a KA is associated with the WSCD in which the corresponding private key is stored;
  • ensure that the public key(s) attested by a KA correspond to private key(s) stored in the referenced WSCD;
  • use a KA only for the applicable issuance or re-issuance process and shall not reuse a KA beyond the permitted issuance process;
  • protect KAs against unauthorized disclosure, modification, replacement and replay; and
  • verify the validity and revocation status of the relevant KA, WSCD before using the KA where required by the applicable ARF and technical specifications. The TOE shall present a KA only to authorised PID Providers or Attestation Providers during applicable issuance processes and shall not present a KA to a Relying Party. If a KA is stored in the private storage of the TOE, the KA shall be protected against unauthorized access, modification and deletion. The TOE shall verify its integrity before use. The KA shall be used in accordance with the applicable OID4VCI proof mechanism and the cryptographic mechanisms specified by the applicable EU technical specifications.

Functional security requirement (FSR) · obligation: mandatory · PDF page 33

FSR_PROTOCOL — Secure Wallet Protocol Processing​

The WI-(TOE) implements or supports the applicable OpenID4VCI, OpenID4VP, ISO/IEC 18013-5, ISO/IEC 18013-7 and Digital Credentials API flows. The TOE shall protect the Wallet User and the Wallet Unit during these flows against phishing, relay, session-hijacking, replay and transaction-manipulation attacks. The TOE shall:

  • verify the authenticity and integrity of security-relevant protocol messages before processing them;
  • ensure that security-sensitive messages are bound to the applicable transaction and communication session;
  • prevent replay or reuse of security-sensitive protocol messages;
  • ensure that the transaction presented to the User corresponds to the transaction actually processed and transmitted; and
  • terminate or reject the affected transaction if the required security checks fail. The TOE shall implement the applicable protocol flows in accordance with the relevant ARF and technical specifications.

Functional security requirement (FSR) · obligation: mandatory · PDF page 34

FSR_TRUST_ANCHOR — Trusted Anchor Management​

The WI-(TOE) maintains and protects the applicable trusted anchors (CA) required for verification of certificates and signed objects used by the Wallet Unit. The TOE shall:

  • use only trusted anchors obtained from authorised and applicable trust sources;
  • protect trusted anchors against unauthorized modification, deletion, replacement.;
  • verify the integrity and authenticity of trusted-anchor information before using it;
  • use the applicable trusted anchor to verify the authenticity and integrity of certificates and signed objects;
  • ensure that the trusted anchor used for verification is applicable to the type of certificate or signed object being verified; and
  • use trusted-anchor and certificate status information in accordance with the applicable ARF, Trusted List and technical specifications. If trusted-anchor information cannot be successfully authenticated or its integrity cannot be verified, the TOE shall not use that information for security-sensitive verification.

Functional security requirement (FSR) · obligation: mandatory · PDF page 34

FSR_ACC_REG_CERT — Relying Party Access and Registration Certificate Validation​

The WI-(TOE) verifies the Wallet-Relying Party Access Certificate (RP_ACC_CERT) and Wallet-Relying Party Registration Certificate (RP_REG_CERT) before processing a request for disclosure of a PID or electronic attestation from a Relying Party. The TOE shall:

  • authenticate and validate the RP_ACC_CERT, including its certificate chain, validity and applicable trust anchor;
  • authenticate and validate the RP_REG_CERT;
  • verify that the request is associated with the authenticated Relying Party;
  • verify that the requested attributes are consistent with the information contained in the RP_REG_CERT, where applicable; and
  • inform the User of the relevant information contained in the RP_ACC_CERT and RP_REG_CERT before disclosure, where required.
  • inform the User when authentication or validation of the Relying Party fails;
  • ensure that the authenticated Relying Party and the applicable Service are identified before the User approves a presentation; and
  • ensure that the Relying Party and Service information presented to the User corresponds to the authenticated RP Access Certificate and applicable RP Registration Certificate. If validation or authentication of the RP_ACC_CERT or RP_REG_CERT fails, the TOE shall not disclose the requested PID or electronic attestation.

Functional security requirement (FSR) · obligation: mandatory · PDF page 34

FSR_ISSUANCE — Credential Issuance and Re-Issuance​

The WI-(TOE) shall securely process the issuance and re-issuance of PIDs and electronic attestations in accordance with the applicable ARF and technical specifications. The TOE shall:

  • request issuance only from an authenticated and authorised PID Provider or Attestation Provider;
  • provide the applicable WIA and KA information required for the issuance process;
  • verify that the received PID or electronic attestation corresponds to the credential requested;
  • verify the authenticity and integrity of the received PID or electronic attestation using the applicable trusted anchor;
  • verify the validity of the received PID or electronic attestation before storing it;
  • require User approval before storing the received PID or electronic attestation;
  • delete a received PID or electronic attestation if a required issuance verification fails and inform the User of the failure;
  • securely handle failed or refused issuance and re-issuance operations; and
  • ensure that obsolete credentials are no longer used for presentation where required by the applicable ARF and technical specifications.

Functional security requirement (FSR) · obligation: mandatory · PDF page 35

FSR_PRESENTATION — Credential Presentation​

The WI-(TOE) maintains and protects PIDs and electronic attestations of attributes and presents them to authorised Relying Parties and other authorised entities in accordance with the applicable ARF requirements. The TOE shall:

  • verify the authenticity and integrity of a PID or electronic attestation before storing or using it;
  • ensure that the PID or electronic attestation is associated with the corresponding Wallet Unit and, where applicable, the WSCA/WSCD;
  • protect stored PIDs and electronic attestations against unauthorized disclosure, modification, replacement and deletion;
  • verify the validity and revocation status of a PID or electronic attestation before presentation, where required by the applicable ARF and technical specifications;
  • ensure that a PID or electronic attestation is presented only to an authorised entity and only after the applicable authentication and authorization requirements have been satisfied;
  • allow the User to delete held PIDs and electronic attestations and inform the User of the deletion; and
  • allow the User to initiate deletion requests towards Relying Parties for PIDs and electronic attestations held by those Relying Parties, where supported by the applicable protocol. The TOE shall not present a PID or electronic attestation if its authenticity, integrity or validity cannot be successfully verified, or if the applicable Relying Party or other recipient has not been successfully authenticated. The TOE shall preserve the cryptographic binding of device-bound PIDs and electronic attestations to the corresponding Wallet Unit and shall ensure that such credentials cannot be used with an unauthorized or different Wallet Unit.

Functional security requirement (FSR) · obligation: mandatory · PDF page 35

FSR_REVOCATION​

The TOE shall regularly check the validity and revocation status of the security-relevant data objects used by the Wallet Unit, including:

  • PIDs and electronic attestations;
  • the Wallet Instance Attestation (WIA);
  • Key Attestations (KA);
  • the WSCD used by the Wallet Unit; and
  • the Wallet Unit, where its revocation status is available. The TOE shall perform such checks before using a data object for a security-sensitive operation where required by the applicable ARF and technical specifications. The TOE shall use the applicable revocation or status information provided by the authorised provider and shall verify the authenticity and integrity of that information before relying on it. If the TOE determines that a PID, electronic attestation, WIA, KA, WSCD, or Wallet Unit has been revoked or suspended, the TOE shall:
  • prevent the affected data object or security function from being used where required by the applicable ARF and technical specifications; and
  • inform the User of the relevant revocation or suspension and its consequences. If the TOE cannot obtain or validate the required revocation or status information, it shall follow the applicable offline/failure-handling rules and shall not incorrectly treat an unverifiable status as valid where this would compromise the security of the Wallet Unit.

Functional security requirement (FSR) · obligation: mandatory · PDF page 37

FSP_Q_SIGNATURE — Qualified Electronic Signature and Seal Creation​

The Wallet Unit shall support qualified electronic signature and seal creation using a local, external or remotely managed Qualified Signature Creation Device (QSCD), as applicable. The Wallet Unit shall:

  • securely interface with the applicable Signature Creation Application (SCA) and QSCD;
  • ensure that signature or seal creation is performed only for the data approved by the User;
  • protect the integrity and confidentiality of the data and transaction information exchanged with the SCA/QSCD;
  • ensure that the signature or seal creation request is bound to the data approved by the User and cannot be replaced or manipulated;
  • where a remote QSCD is used, verify that the signature creation service is provided by an authorised QTSP, as applicable; and
  • provide the User with the result of the signature or seal creation, including notification of a failed operation. The WI-(TOE) shall support the mandatory signature and seal formats and interfaces applicable to the selected signature creation mechanism.

Functional security requirement (FSR) · obligation: mandatory · PDF page 38

FSR_W2W — Wallet-to-Wallet Interaction​

The WI-(TOE) supports Wallet-to-Wallet (W2W) interactions between Wallet Units in accordance with the applicable ARF and technical specifications. The TOE shall:

  • establish an authenticated and protected communication channel with the other Wallet Unit;
  • verify the authenticity of the other Wallet Unit before processing a W2W request;
  • ensure that the User is informed of the requested attributes or electronic attestations before disclosure;
  • require User approval before disclosing any attributes or electronic attestations to the other Wallet Unit;
  • ensure that only the attributes or electronic attestations approved by the User are disclosed;
  • protect the W2W transaction against eavesdropping, modification, replay and transaction manipulation; and
  • log the W2W transaction in accordance with FSR_LOG_DATA. The TOE shall support both Holder Wallet Unit mode and Verifier Wallet Unit mode, where these functions are supported by the Wallet Unit. The TOE shall:
  • enter Holder Wallet Unit mode only following explicit User selection;
  • enter Verifier Wallet Unit mode only following explicit User selection;
  • inform the User when entering Holder Wallet Unit mode that this mode is intended for interaction with another natural person using a Wallet Unit;
  • return to normal Wallet Unit operation when the Wallet Unit is closed or after the applicable period of inactivity;
  • support W2W attestation presentation only through the applicable ISO/IEC 18013-5 proximity communication mechanisms;
  • when acting as a Verifier Wallet Unit, authenticate the Verifier and obtain the Verifier's approval before sending a presentation request;
  • limit the rate at which presentation requests can be sent in accordance with the applicable technical specification;
  • when acting as a Verifier Wallet Unit, verify received attestations and display the verified attributes to the Verifier;
  • not persistently store received attestations or attributes when acting as a Verifier Wallet Unit; and
  • when acting as a Holder Wallet Unit, authenticate the Verifier Wallet Unit before presenting the requested attributes, where the applicable cryptographic proof mechanism is available. If authentication of the Verifier Wallet Unit fails or cannot be performed, the TOE shall inform the User and shall prevent disclosure or allow the User to explicitly decide whether disclosure may proceed, in accordance with the applicable ARF and technical specification.

Functional security requirement (FSR) · obligation: mandatory · PDF page 38

FSR_MIGRATION — Wallet Unit Migration​

The WI-(TOE) shall support migration of the Wallet Unit in accordance with the applicable ARF and Technical Specification 10. The TOE shall:

  • maintain an up-to-date Migration Object containing the transaction log information and the information required to restore the PIDs and electronic attestations present in the Wallet Unit;
  • ensure that the Migration Object does not contain WIA or KA;
  • for each PID and device-bound attestation, store in the Migration Object the information required to request re-issuance, including the attestation type, the PID Provider or Attestation Provider and the applicable service supply points;
  • ensure that the Migration Object does not contain attribute identifiers, attribute values or private keys associated with a PID or device-bound attestation;
  • for non-device-bound attestations, support the migration mechanism defined by the applicable ARF, including, where applicable, storing the information required for direct transfer or re-issuance;
  • allow the User to choose whether attribute identifiers and attribute values associated with a non-device-bound attestation are included in the Migration Object, where applicable;
  • delete the corresponding entry from the Migration Object when the User deletes a PID or attestation from the Wallet Unit;
  • store or export the Migration Object to an external or remote storage location supported by the Wallet Unit and selected by the User;
  • protect the confidentiality, integrity and authenticity of the Migration Object and prevent its use by anyone other than the User;
  • after installation of a new Wallet Instance, allow the User to import a Migration Object from a supported storage location;
  • allow the User to select the PIDs and attestations to be restored;
  • request re-issuance of selected PIDs and device-bound attestations from the respective PID Provider or Attestation Provider, using the normal issuance process;
  • request issuance of the PID before requesting issuance of other selected attestations;
  • for non-device-bound attestations, either restore the attestation directly from the Migration Object or request re-issuance, as applicable to the contents of the Migration Object;
  • ask the User whether the transaction log contained in the Migration Object shall be restored and, where approved, restore the log and append subsequent transactions to it; and
  • ensure that the migration and re-issuance processes use the applicable security mechanisms and interfaces defined for normal issuance. The TOE shall protect the Migration Object during creation, storage, export, import and processing against unauthorized disclosure, modification, replacement and replay.

Functional security requirement (FSR) · obligation: mandatory · PDF page 39

FSR_DATA_DELETION — User Data Deletion Requests​

The WI-(TOE) shall support User-initiated requests for deletion of User attributes previously presented to Relying Parties in accordance with the applicable ARF and technical specifications. The TOE shall:

  • allow the User to select one or more Relying Parties for which an attribute deletion request shall be submitted;
  • generate and transmit the deletion request using the applicable protocol and security mechanisms;
  • ensure that the deletion request identifies the relevant Relying Party and the data to which the request applies;
  • protect deletion requests against unauthorized modification and replacement; and
  • log the initiation and outcome of deletion requests in accordance with FSR_LOG_DATA.

Functional security requirement (FSR) · obligation: mandatory · PDF page 41

3.2 WI-(TOE) Resilience Security Requirements​

Read section 3.2 in the full text

RSR_USERDEVICE — Minimum User Device Security Platform​

The User Device hosting the Wallet Instance shall provide a hardware-supported security platform consisting, at minimum, of a Trusted Execution Environment (TEE) or Secure Element (SE), integrated with a security-maintained operating system, to provide the security services required by the Wallet Instance. The TOE shall check that the User Device and OS shall at minimum:

  • provide a TEE or SE providing an isolated execution and storage environment for security-relevant Wallet Instance assets;
  • ensure that security-relevant device-bound private keys used by the Wallet Instance cannot be exported or cloned from the TEE/SE;
  • ensure that cryptographic operations using such keys are performed within the protected environment and that the key material is not exposed to the normal OS or other applications;
  • provide hardware-supported isolation between the protected security environment, the OS kernel and user applications;
  • provide a trusted boot mechanism that ensures that only authenticated and authorized firmware and OS components are executed with privileged access;
  • provide OS-enforced application isolation/sandboxing preventing one application from accessing another application's data, memory or processes without authorization;
  • provide protection against unauthorized privilege escalation, including execution of unauthorized code with OS or kernel privileges;
  • provide mechanisms for secure and timely security updates of the OS, firmware and security-critical platform components;
  • provide hardware-backed integrity/attestation mechanisms allowing the security state of relevant platform components to be established; and
  • provide a secure device-access mechanism protecting the User Device and the protected security environment against unauthorized local access.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 41

RSR_OPER_MOD — Secure Operating Mode​

The WI (TOE) shall establish that it is operating in a security state supported by the Wallet Instance. At a minimum, the TOE shall detect conditions indicating that the security properties of the underlying User Device or OS may have been compromised, including rooting/jailbreaking, unauthorized developer or debug mode, execution in an emulator or app-virtualization environment, or other conditions that invalidate the security assumptions of the TOE. When such a condition is detected, the TOE shall terminate or disable all security-critical Wallet Instance functionality and shall not perform security-critical operations until an acceptable security state has been restored.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 43

RSR_SEC_CLR — Secure Clearing of Sensitive Data​

The WI (TOE) shall securely clear sensitive assets from memory when they are no longer required. Secure clearing shall use an explicit and effective mechanism appropriate to the asset and execution environment, such as zeroization, and shall not depend solely on garbage collection, memory deallocation or eventual reuse of the memory. The implementation shall ensure that the clearing operation is not removed, optimized away or otherwise altered by the compiler, runtime environment or platform. Where sensitive data may exist in multiple representations or memory areas, all relevant representations shall be appropriately cleared.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 44

RSR_CRPTO — Use of Approved Cryptography​

The WI (TOE) shall use cryptographic mechanisms that provide adequate security for the intended protection period and security strength of the protected assets. At a minimum:

  • cryptographic keys shall be generated using an approved cryptographically secure random source;
  • key derivation shall use approved key-derivation functions and appropriate parameters and key sizes;
  • encryption, decryption, digital signatures, MACs and hashing shall use approved cryptographic algorithms and security parameters;
  • deprecated, broken or insufficiently secure algorithms and parameter sets shall not be used for security-critical functions; and
  • cryptographic mechanisms shall be selected and configured in accordance with the applicable ECCG Agreed Cryptographic Mechanisms. Where a cryptographic mechanism required by the TOE is not yet included in the ECCG Agreed Cryptographic Mechanisms, its use shall be subject to an appropriate security assessment and documented justification demonstrating that the mechanism provides sufficient security for the intended purpose and security strength. Such a mechanism shall only be used where its security has been established in accordance with the applicable certification or evaluation framework, and shall be replaced or updated when an applicable ECCG mechanism becomes available. The use of cryptographic mechanisms not yet included in the ECCG Agreed Cryptographic Mechanisms shall therefore be explicitly identified, justified and subject to approval by the applicable certification/evaluation process.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 45

RSR_RNG — Cryptographically Secure Random Number Generation​

The WI-(TOE) must generate random numbers using either:

  • A hardware RNG through an SE or TEE, and that RNG must be assessed as suitable for cryptographically strong random-number generation.
  • Or implement a DRBG compliant to NIST SP 800-90A or ISO/IEC 18031. This DRBG must be seeded by at least two sources of entropy:
    • One external trusted source, (e.g. Wallet Provider HSM/WSCD) o A source from the mobile device The combined entropy must be at least equal to the intended cryptographic key strength, and the entropy must be authenticated before use. Combining of entropy must preserve the entropy strength. The RNG (or DRNG) must be reseeded at least:
  • when the integrity/confidentiality of its state cannot be assured, such as at launch or after a halted state; and
  • at least every 24 hours of continuous operation. The reseeding process must add entropy to the existing RNG state, rather than simply replacing it. The DRNG shall generate random values with sufficient entropy and without statistically significant correlation, and shall be demonstrated to be fit for cryptographic purposes using an industry-recognized statistical test suite such as NIST SP 800-22 or AIS-31.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 45

RSR_SEC_COD — Secure Software Development and Supply Chain​

The WI-(TOE) is developed using Secure coding practices, at a minimum:

  • The TOE shall protect sensitive data and secrets by ensuring that secrets are not hardcoded in the TOE source code or package, and sensitive data is stored encrypted, and only in private storage.
  • The TOE shall securely handle untrusted or externally supplied data, including intents, deep links, WebView content, and dynamically loaded code, such that:
    • untrusted content cannot access sensitive native functionality;
    • does not expose sensitive native functionality to WebView content and does not allow WebViews to load untrusted content;
    • deep links and intents cannot be abused to bypass security controls;
    • dynamic code is loaded safely, and only from trusted sources.
  • The TOE shall use platform-provided security mechanisms, including compiler-provided security features, and shall not use deprecated APIs or functionality that could weaken the TOE's security.
  • The TOE shall adequately manage platform permissions according to the principle of least privilege and shall use only trusted and appropriately maintained libraries for security-critical functionality.
  • The TOE package shall not contain malicious or unauthorized code and third party components are regularly checked for known vulnerabilities.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 45

RSR_OBF_COD — Code and Resource Obfuscation​

The WI-(TOE) may apply code and resource obfuscation to hinder reverse engineering and analysis of security-sensitive functionality and assets. At a minimum, obfuscation shall cover:

  • control-flow obfuscation of code implementing security mechanisms or handling security-sensitive assets;
  • symbol renaming of functions, methods, classes and other symbols associated with security-sensitive code; and data and string obfuscation of sensitive data, embedded secrets, strings and other security-relevant resources. Obfuscation shall also cover security-sensitive interfaces, including interfaces to cryptographic functionality and inter-library calls, where exposure of the implementation could facilitate compromise of the TOE. The TOE may additionally implement anti-deobfuscation and anti-analysis techniques to increase the resistance of the obfuscation against automated or manual reverse engineering.

Resilience security requirement (RSR) · obligation: recommended · PDF page 46

RSR_PYL_ENC — Application-Level Payload Encryption​

The WI-(TOE) may protect security-sensitive assets transmitted between the TOE and external entities using application-level encryption in addition to transport-layer protection, where such assets require protection against compromise of the underlying communication channel. Application-level encryption shall provide confidentiality and integrity protection for the protected payload and shall ensure that the payload cannot be disclosed or modified without detection if the underlying transport protection is compromised. Cryptographic keys used for application-level payload protection shall be managed in accordance with the applicable key-management and cryptographic requirements.

Resilience security requirement (RSR) · obligation: recommended · PDF page 46

RSR_ATT — Device Attestation​

The WI-(TOE) may support device and platform attestation sufficient to establish the relevant security state of the User Device on which the TOE operates. Where attestation evidence is used for security decisions, the TOE shall ensure that the evidence is authentic, integrity protected and sufficiently fresh and that it is associated with the corresponding User Device and Wallet Instance. The TOE shall not rely on attestation evidence that cannot be successfully authenticated, integrity verified or associated with the applicable device.

Resilience security requirement (RSR) · obligation: recommended · PDF page 46

RSR_INTG — TOE Integrity Verification​

The WI-(TOE) may periodically verify the integrity and authenticity of its security-relevant software and resources, including executable code, security-sensitive configuration and other resources required for secure operation. The integrity verification mechanism shall detect unauthorized modification, replacement or removal of the verified code or resources. If the integrity or authenticity verification fails, the TOE shall prevent security-critical functionality and shall not continue operation using the affected code or resources.

Resilience security requirement (RSR) · obligation: recommended · PDF page 47

RSR_FOCS — Protection Against Loss of User Interface Focus​

The WI-(TOE) may protect security-sensitive user interactions and displayed sensitive assets against loss or unauthorized transfer of user-interface focus. If the TOE detects that focus has been lost while the User is performing a security-sensitive action or while sensitive information is being displayed, the TOE shall:

  • terminate the affected security-sensitive operation;
  • prevent the operation from continuing without appropriate re-authentication or renewed User interaction, where required; and
  • prevent sensitive information from remaining exposed after focus has been lost.

Resilience security requirement (RSR) · obligation: recommended · PDF page 47

RSR_DYN_TL — Protection Against Dynamic Instrumentation and Runtime Manipulation​

The WI-(TOE) may implement countermeasures against runtime instrumentation and dynamic analysis techniques that could be used to compromise security-sensitive assets or security functionality. Where such countermeasures are implemented, they should detect or resist techniques including runtime code injection, function hooking, API interception, dynamic debugging and manipulation of security-relevant execution flows. Where a detected instrumentation condition could compromise a security-critical operation, the TOE should terminate the affected operation.

Resilience security requirement (RSR) · obligation: recommended · PDF page 47

RSR_MON — Security Monitoring and Attestation​

The WI (TOE) shall collect security-relevant monitoring and attestation information required to detect compromise of the TOE or its supporting User Device and shall securely provide this information to the Wallet Provider. At a minimum, the monitoring information shall include, where applicable:

  • rooted/jailbroken status;
  • emulator, virtualization and developer/debug status;
  • detected modification or tampering attempts, including modification of TOE code, runtime instrumentation and interference with TOE security-relevant interfaces;
  • TOE integrity status;
  • relevant User Device and platform security state;
  • TOE and supported platform versions; and
  • the unique identifier required to associate the information with the corresponding Wallet Instance. Monitoring and attestation information transmitted to the Wallet Provider shall be protected against unauthorized disclosure, modification and replay. It shall contain sufficient freshness information, such as a timestamp and/or nonce, to detect replay of previously generated evidence. The TOE shall not persistently retain monitoring information unless explicitly required for a security purpose.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 43

RSR_DAT_SAN — Sanitization of Sensitive Data​

The TOE shall sanitize sensitive assets, PID attributes and other security-relevant personal data from temporary or secondary storage when they are no longer required. This requirement shall apply, as applicable, to:

  • migration data;
  • backups; logs;
  • caches;
  • temporary files;
  • operational data;
  • crash reports;
  • diagnostic data; and
  • other data generated or retained during operation. Sanitization shall ensure that sensitive assets and PID attributes cannot subsequently be recovered or disclosed through such data, unless their retention is explicitly required for an authorized security or operational purpose and appropriate protection is applied.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 44

RSR_KEY_MNG — Secure Key Management​

The WI (TOE) shall implement key-management mechanisms appropriate to the security strength and intended use of each cryptographic key. At a minimum:

  • secret and private keys shall be generated, imported or injected only through mechanisms that protect their confidentiality, integrity and authenticity;
  • keys requiring hardware-backed protection shall be generated or stored using the User Device's hardware-backed keystore, TEE or SE;
  • security-relevant private keys shall not be exportable from their protected environment;
  • private or secret keys that must temporarily exist outside the hardware-backed security environment shall be unique per session and shall provide appropriate protection against compromise of previous or subsequent sessions;
  • key-encryption keys shall provide security strength equal to or greater than the keys they protect;
  • public keys used for security-critical purposes shall be integrity- and authenticity-protected and authenticated before use;
  • protection of keys in transit shall not rely solely on transport-channel security where compromise of the channel could expose or enable substitution of the key;
  • keys shall have explicitly defined usage restrictions and shall not be used for purposes other than those for which they were generated;
  • cryptographic keys shall be securely destroyed or invalidated when their lifecycle ends; and
  • keys or security credentials dependent on the User Device's biometric enrollment state shall be invalidated or re-established when the relevant biometric enrollment changes, where required by the platform security model. Key-management mechanisms shall conform to the applicable ECCG Agreed Cryptographic Mechanisms and the security strength required by the TOE.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 44

RSR_SCRN_PRT — Protection of Sensitive User Interface Data​

The WI (TOE) shall protect sensitive information presented through the User Device graphical user interface against unauthorized capture, modification or disclosure. At a minimum, the TOE shall:

  • prevent or appropriately restrict screenshots and screen recording while sensitive information is displayed;
  • protect sensitive screens against overlay, tapjacking and other UI-injection attacks;
  • prevent sensitive information from being unnecessarily exposed through the system clipboard;
  • prevent unauthorized accessibility services from accessing sensitive information or user input;
  • prevent sensitive information from being unnecessarily exposed through notifications, previews or other system UI;
  • provide secure handling of authentication input, including support for platform-provided secure authentication mechanisms where applicable; and
  • verify that an appropriate secure device lock mechanism is configured before enabling security-critical functionality.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 42

RSR_PIN_ENTRY — Secure PIN Entry​

The WI (TOE) shall protect the knowledge-based authentication factor used for RUAP against unauthorized disclosure, modification and reuse During PIN entry, the TOE shall provide protection against:

  • screen capture and recording;
  • overlay and tapjacking attacks;
  • side-channel leakage;
  • accessibility-service abuse;
  • malware attempting to intercept or manipulate the PIN; and
  • unauthorized modification or substitution of the PIN-entry interface. The PIN shall not be persistently stored or logged by the TOE. Any PIN and security-sensitive data derived from it shall be securely cleared immediately after use and shall not remain recoverable in memory, temporary storage, caches or other TOE-controlled storage. The TOE shall ensure that the PIN is processed only for the intended authentication operation and shall not expose it to third-party applications or unnecessary platform services.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 42

RSR_NO_DEBG — Protection Against Debugging and Instrumentation​

The WI (TOE) shall not contain production debug functionality or debug artifacts that could weaken its security The TOE shall detect and prevent security-critical operation when an unauthorized debugger, runtime instrumentation framework or equivalent debugging mechanism is attached or enabled. Security controls shall not rely solely on the absence of visible debug functionality and shall protect against commonly available mechanisms for bypassing such controls.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 43

3.1 WI-(TOE) Functional Security Requirements​

Read section 3.1 in the full text

FSR_SEC_CHANNEL — Secure Communication Channels​

The WI-(TOE) establishes and maintains mutually authenticated and protected communication channels with the WSCA and the Wallet Provider. The communication channels shall provide authentication, confidentiality and integrity protection, and shall protect security-relevant communications against replay and modification. All communication between the WI-(TOE) and the WSCA or the Wallet Provider shall use these protected channels.

Functional security requirement (FSR) · obligation: mandatory · PDF page 32

FSR_LOCAL_AUTH — Local User Authentication​

The WI-(TOE) implements local OS-based authentication. The authentication mechanism shall be multi-factor authentication, including possession of the User's device as one factor and an additional knowledge-based or inherence-based factor. This local OS-based authentication shall be enforced at startup of the WI-(TOE) and before security-sensitive actions which require User authentication, as defined in the applicable Regulation and ARF requirements. The TOE shall ensure that authentication is no longer considered valid after the applicable inactivity timeout and shall require the User to authenticate again before performing protected actions.

Functional security requirement (FSR) · obligation: mandatory · PDF page 32

Referenced by: FSR_WI_INSTALL

FSR_REMOTE_AUTH — Remote User Authentication​

The WI-(TOE) implements the WSCA/WSCD-level Remote User Authentication Protocol (RUAP) between the WI-(TOE) and the WSCA/WSCD. The RUAP shall support User authentication meeting the applicable requirements for Level of Assurance High as specified in Commission Implementing Regulation (EU) 2015/1502. In particular, the authentication mechanism shall use at least two authentication factors from different categories and shall implement security controls such that guessing, eavesdropping, replay and manipulation of the authentication communication cannot, with high attack potential, subvert the authentication mechanism. This specific Remote User Authentication Protocol (RUAP), including the use of User Authentication Evidence (UAE) and Authentication Reference Data (ARD), is a PP-specific mechanism defined to implement the required WSCA/WSCD-level User authentication. The protocol shall ensure that:

  • The Wallet Instance WI-(TOE) must demonstrate the User Authentication Evidence (UAE), which is derived both from a knowledge-based authentication factor (derived from the PIN) and a possession-based authentication factor, which are jointly validated to achieve two-factor authentication and to prevent manipulation or forged attempts;
  • Remote User Authentication Protocol (RUAP) ensure PIN Verification and ensure that the User has sole control over the critical assets located in the WSCD, such that these assets cannot be used without the User's involvement through the required authentication factors;
  • The protocol protects the confidentiality and integrity of the authentication data during PIN verification and enrolment, and provides protection against duplication, tampering, eavesdropping and replay attacks, including through freshness and challenge binding;
  • Each PIN verification is performed through a live and fresh interaction between the WI-(TOE) and the WSCA/WSCD, preventing reuse of previously exchanged authentication information;
  • During enrolment, the Wallet Instance WI-(TOE) ensures that both the knowledge and possession factors are securely initialized and cryptographically bound to the Authentication Reference Data (ARD). Authentication Reference Data (ARD) is derived and is shared with the WSCA /WSCD during initial enrolment. This binding preserves confidentiality and integrity of the knowledge-based authentication factor (derived from the PIN) and a possession-based authentication factor and prevents compromise also if the confidentiality of the Authentication Reference Data (ARD) is not preserved.
  • A PUK can be integrated in the protocol to reset the knowledge-based factor in case the PIN was forgotten.
  • Per-key authentication data shall be sent to the Wallet Instance WI-(TOE) at key generation and be provided at every security-sensitive cryptographic operation of the applicable key, to ensure sole control of the Wallet User before the execution by the WSCD. As part of the enrolment process, the Wallet User initializes the WSCA/WSCD-level User Authentication by instructing the WI-(TOE) to generate the required cryptographic keys within the secure keystore. The User shall provide their PIN during this process, from which the knowledge-based factor is derived and securely incorporated into the authentication mechanism. The WSCA/WSCD-level Remote User Authentication shall be performed before security-sensitive operations involving critical assets located in the WSCD, as defined in the applicable Regulation and ARF requirements.

Functional security requirement (FSR) · obligation: mandatory · PDF page 32

FSR_SELECT_DISCLO — Selective Disclosure and User Consent​

The WI-(TOE) enforces selective disclosure by ensuring that only User-approved attributes and electronic attestations are released to authorised Relying Parties, consistent with the principles of user consent, data minimisation and selective disclosure. The TOE shall:

  • display to the User the attributes and electronic attestations requested by the Relying Party before presentation;
  • process and enforce applicable embedded disclosure policies associated with electronic attestations;
  • ensure that the User can approve the requested presentation in full or in part;
  • ensure that no requested attributes or electronic attestations are presented before the applicable disclosure policies have been processed and the User has approved the presentation;
  • ensure that only the attributes and electronic attestations approved by the User are included in the presentation; and
  • prevent disclosure if the applicable disclosure policy is not satisfied or the required User approval has not been obtained.
  • The TOE shall evaluate applicable embedded disclosure policies against the authenticated Relying Party and Service information and shall prevent disclosure if the policy requirements are not satisfied.
  • The TOE shall ensure that the User approval applies to the actual presentation transaction and to the attributes and electronic attestations that are transmitted to the Relying Party.
  • The TOE shall retain control over security-sensitive User approval and disclosure decisions and shall not delegate such decisions to a browser, operating-system component or other intermediary application. The TOE shall ensure that selective disclosure is performed in accordance with the applicable ARF and technical specifications and shall support privacy-preserving mechanisms, including unlinkability where required.

Functional security requirement (FSR) · obligation: mandatory · PDF page 36

FSR_MDOC — mDoc Presentation​

The WI-(TOE) supports ISO/IEC 18013-5 mdoc-based presentation flows in accordance with the applicable ARF and technical specifications. The TOE shall:

  • support the applicable ISO/IEC 18013-5 requirements for mdoc presentation;
  • verify the authenticity and integrity of received mdoc presentation requests before processing them;
  • ensure that the mdoc response contains only the attributes and data elements approved by the User and permitted by the applicable disclosure policies;
  • protect the mdoc presentation against replay, modification and transaction manipulation;
  • ensure that security-relevant mdoc messages are bound to the applicable presentation session and transaction; and
  • verify the authenticity and integrity of received mdoc data before using or presenting it. Where an API-mediated presentation mechanism based on ISO/IEC 18013-7 is used, the TOE shall comply with the applicable ISO/IEC 18013-7 requirements and the corresponding EUDI Wallet technical specifications.

Functional security requirement (FSR) · obligation: mandatory · PDF page 36

FSR_PSEUDONYM — Relying Party-Specific Pseudonyms​

The WI-(TOE) supports the generation, management and presentation of Wallet-Relying Party-specific pseudonyms in accordance with the applicable ARF and technical specifications. The TOE shall:

  • generate a pseudonym that is specific and unique to the requesting Relying Party;
  • ensure that the same pseudonym is not used for different Relying Parties where the applicable pseudonym mechanism requires Relying Party-specific pseudonyms;
  • provide the generated pseudonym to the requesting Relying Party, either standalone or together with the requested PID or electronic attestation;
  • ensure that the pseudonym is generated and presented only after the Relying Party has been authenticated and the User has approved the applicable transaction;
  • protect pseudonyms against unauthorized disclosure, modification and replacement; and
  • allow the User to manage pseudonyms in accordance with the applicable technical specifications.
  • store the cryptographic information required for pseudonym generation and authentication in the WSCA/WSCD;
  • ensure that the same pseudonym is not disclosed to different Relying Parties unless explicitly permitted by the applicable pseudonym mechanism and User choice;
  • allow the User to view, select, manage and delete pseudonyms;
  • provide the User with sufficient information to distinguish pseudonyms associated with different Relying Parties;
  • protect pseudonym authentication data against unauthorized disclosure, modification, replacement and deletion;
  • ensure that User-assigned aliases or other information used by the User to manage pseudonyms are not disclosed to Relying Parties; and
  • ensure that pseudonyms contain sufficient entropy and are generated using the cryptographic mechanisms specified by the applicable technical specifications. The TOE shall ensure that pseudonym generation and presentation do not unnecessarily disclose the User's legal identity or enable the User to be tracked across different Relying Parties. The TOE shall support User-chosen and managed pseudonyms where required by the applicable ARF and technical specifications.

Functional security requirement (FSR) · obligation: mandatory · PDF page 36

FSR_DPA_REPORT — Data Protection Authority Reporting​

The WI-(TOE) shall provide the User with a function to initiate a complaint concerning a suspicious or inappropriate Relying Party presentation request to the competent Data Protection Authority (DPA), in accordance with the applicable ARF and national requirements. The TOE shall:

  • provide access to the applicable Data Protection Authority reporting function through the Wallet Instance;
  • allow the User to identify the relevant Relying Party and presentation request;
  • allow the User to provide the information required to substantiate the complaint;
  • protect the confidentiality and integrity of the report during preparation and transmission; and
  • record the submitted report in the transaction log so that it can subsequently be presented to the User.

Functional security requirement (FSR) · obligation: mandatory · PDF page 40

FSR_TRST_MRK — EU Digital Identity Wallet Trust Mark​

The WI-(TOE) displays the official EU Digital Identity Wallet Trust Mark in the User interface. The Trust Mark view shall:

  • display the official Trust Mark graphics and/or logo;
  • provide information about the certification status of the Wallet Solution; and
  • provide links to the official list of certified EUDI Wallet Solutions and the certification information of the Wallet Solution. The TOE shall obtain and protect the Trust Mark information provided by the Wallet Provider and shall ensure that the displayed Trust Mark information cannot be modified by an unauthorized party. The TOE shall ensure that the Trust Mark and related certification information are only displayed for the applicable Wallet Solution and Wallet Instance.

Functional security requirement (FSR) · obligation: mandatory · PDF page 40

FSR_LOG_DATA — Transaction and Operational Logging​

The WI-(TOE) shall maintain transaction logs for transactions with Wallet-Relying Parties and other Wallet Units, including unsuccessful transactions and electronic signing and sealing transactions. The transaction logs shall contain, as applicable:

  • the date and time of the transaction;
  • the name, contact details and unique identifier of the corresponding Wallet-Relying Party and the Member State in which it is established, or the relevant information from the Wallet Unit Attestation for transactions with another Wallet Unit;
  • the type of data requested and presented; and
  • the reason for an unsuccessful transaction. The TOE shall also log reports sent by the User to a Data Protection Authority through the Wallet Unit. The TOE shall protect transaction logs against unauthorized access, modification and deletion and shall ensure their confidentiality, integrity and authenticity. The TOE shall ensure that transaction logs do not contain the actual values of attributes presented, unless explicitly required by applicable legislation. The TOE shall allow the User to access and export the transaction logs in accordance with the applicable technical specifications. The TOE shall allow the User to delete individual transaction-log entries, where permitted by applicable legislation, and shall inform the User before logs are deleted when deletion is required. Transaction logs shall remain available for the period required by applicable Union or national law. Where access to transaction logs by the Wallet Provider is necessary for the provision of Wallet services, the TOE shall only permit such access based on the explicit prior consent of the User, as required by the applicable Regulation. The TOE shall additionally maintain operational and maintenance logs where required for the secure operation and maintenance of the Wallet Instance. Such logs shall be minimized and shall not contain the actual values of attributes presented.

Functional security requirement (FSR) · obligation: mandatory · PDF page 40

Referenced by: FSR_W2W, FSR_DATA_DELETION

3.2 WI-(TOE) Resilience Security Requirements​

Read section 3.2 in the full text

RSR_MAC — Mandatory Access Control and Application Isolation​

The WI (TOE) shall operate within the security and isolation mechanisms provided by the underlying operating system. The TOE shall not bypass or weaken the OS mandatory access-control, application sandboxing, process-isolation or permission mechanisms. The TOE shall use the principle of least privilege and shall request only the platform permissions required for its intended security and functional purposes.

Resilience security requirement (RSR) · obligation: mandatory · PDF page 43