NL-P-04W requirements
This page lists every requirement of NL-P-04W (EUDI Wallet Lifecycle Specification, version RC1.0) 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.
201 entries: 201 requirements. Obligation: 184 mandatory, 17 conditional.
Legal basis of the document: eIDAS Art. 5a, CIR 2024/2979, CIR 2024/2977.
Referenced in the document but not defined in it: ACT-5.3-03, ACT-5.7-02, ACT-5.7-04, ACT-5.7-05, MAINT-8.4-02, MAINT-8.7-01, MIG-9.2-01.
5.1 Secure Software Distribution and Delivery
Read section 5.1 in the full text
INST-5.1-01
The Wallet Provider shall sign the Wallet Instance software package using a private key associated with the Wallet Provider’s registered identity in the target distribution platform’s certificate infrastructure, such that the distribution platform or device can verify the signature before permitting installation.
Requirement · obligation: mandatory · PDF page 17
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider’s code signing configuration and confirming that the signing key is registered with the Wallet Provider’s identity in the distribution platform. The CAB may also attempt to install a test package signed with an unregistered key and confirm that the target platform refuses installation.
INST-5.1-02
The Wallet Provider shall distribute the Wallet Instance software exclusively through distribution channels that enforce signature verification of the software package as a condition of delivery to the Wallet User’s device.
Requirement · obligation: mandatory · PDF page 17
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider’s documented distribution channels and confirming that each channel enforces signature verification prior to delivery. The CAB examines whether any unapproved distribution paths exist and whether the Wallet Provider has controls to detect and respond to use of unauthorized channels.
INST-5.1-03
The Wallet Provider shall ensure that the Wallet Instance verifies the integrity of its own software prior to initializing any Wallet Unit functionality, by performing a cryptographic check of the installed package against a reference value established at install time and protected within the device's hardware-backed key store or WSCD.
Requirement · obligation: mandatory · PDF page 18
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's technical documentation and confirming that an integrity check is performed at each application launch prior to any Wallet Unit operation. The CAB may corroborate this by inspecting the launch-time integrity-check configuration and, where feasible, by testing that a modified application binary causes the Wallet Instance to refuse to initialise Wallet Unit functionality.
INST-5.1-04
The Wallet Provider shall hold the private signing key used for the Wallet Instance software package in a hardware security module (HSM) that requires multi-person authorisation for each signing operation and that is certified to FIPS 140-3 Level 3, Common Criteria EAL4+, or an equivalent recognised level.
Requirement · obligation: mandatory · PDF page 18
How a CAB verifies this: A CAB verifies this requirement by reviewing the HSM certificate, the configured signing policy, and the access list for operators authorised to release a signature, and by sampling the audit log to confirm that recent signing events were performed under the multi-person policy.
INST-5.1-05
The Wallet Provider shall record, in a tamper-evident log retained for at least 12 months, every administrative action that modifies the Wallet Instance software package, the code-signing infrastructure, or the configuration of the distribution channel, together with the identity of the operators and the time of the action.
Requirement · obligation: mandatory · PDF page 19
How a CAB verifies this: A CAB verifies this requirement by inspecting the log retention configuration and by sampling logs from the most recent 12 months for a selection of administrative event types to confirm they are retained and complete. The CAB may also review the tamper-evidence design and, where feasible, attempt under controlled conditions to alter a logged entry to confirm that tamper evidence is produced.
INST-5.1-06
The Wallet Provider shall verify, before incorporating any third-party software component into a Wallet Instance software build, that the component's distribution origin is authenticated through a cryptographic signature or hash that traces to a publisher identity declared in the Wallet Provider's approved-supplier list.
Requirement · obligation: mandatory · PDF page 19
How a CAB verifies this: A CAB verifies this requirement by reviewing the approved-supplier list, the build configuration that enforces signature or hash verification, and the most recent SBOM produced by a build. Where feasible, the CAB may also attempt to introduce an
5.2 Device Security Pre-Checks
Read section 5.2 in the full text
INST-5.2-01
The Wallet Provider shall ensure that the Wallet Instance, at installation and at each subsequent launch, verifies that the operating system version and security patch level of the host device meets the minimum requirements documented by the Wallet Provider, and refuses to activate Wallet Unit functionality on devices that do not meet those requirements.
Requirement · obligation: mandatory · PDF page 20
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented minimum OS requirements and the implementation that enforces them, confirming that Wallet Unit functionality is not activated on a device that does not meet those requirements. Where feasible, the CAB may also test the Wallet Instance on such a device and confirm that the application refuses to activate Wallet Unit functionality.
INST-5.2-02
The Wallet Provider shall ensure that the Wallet Instance detects the presence of root access or jailbreak conditions on the host device and, where such conditions are detected, refuses to finalize Wallet Instance Installation.
Requirement · obligation: mandatory · PDF page 20
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented root/jailbreak-detection design and confirming that installation is refused on a rooted (Android) or jailbroken (iOS) device. Where feasible, the CAB may also attempt installation on a rooted or jailbroken test device to confirm that the Wallet Instance installation is impossible.
INST-5.2-03
The Wallet Provider shall implement runtime anti-tampering controls in the Wallet Instance that detect attempts to instrument, hook, or modify the application's execution at runtime.
Requirement · obligation: mandatory · PDF page 21
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented instrumentation-detection design and confirming that the application detects attachment of a dynamic instrumentation framework and refuses to process Wallet Unit operations. Where feasible, the CAB may also attach such a framework to a running test instance and confirm the detection and refusal.
INST-5.2-04
The Wallet Provider shall ensure that the Wallet Unit refuses to finalize Wallet Instance installation when the runtime anti-tampering controls detect an attempt to instrument, hook, or modify the application's execution.
Requirement · obligation: mandatory · PDF page 21
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented anti-tampering controls and confirming that installation performed under an instrumentation or hooking framework the controls detect does not finalise. Where feasible, the CAB may also run Wallet Instance installation under such a framework and confirm that installation does not finalise.
INST-5.2-05
The Wallet Provider shall document and enforce minimum security requirements for devices on which the Wallet Instance may be installed and operated, including at minimum: a screen lock mechanism using a PIN, password, or biometric factor; the availability of a hardware-backed key store; and a supported operating system version receiving security updates from the platform vendor.
Requirement · obligation: mandatory · PDF page 21
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented minimum device requirements and by confirming that the Wallet Instance refuses to activate Wallet Unit functionality on a test device that does not satisfy them.
INST-5.2-06
The Wallet Provider shall ensure that the Wallet Secure Cryptographic Device used by the Wallet Unit is operated solely under the Wallet Provider’s control, holds a valid security certification appropriate for the applicable Assurance Level prior to its first use by a Wallet Unit, and remains under the Wallet Provider’s exclusive operational control throughout the entire lifetime of the Wallet Unit.
Requirement · obligation: mandatory · PDF page 22
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider’s documentation of the WSCD used in production, confirming that a valid security certification appropriate for the applicable Assurance Level is current and on record, and verifying that the Wallet Provider’s operational procedures ensure the WSCD remains under their exclusive control. The CAB also confirms that no pathway exists for parties other than the Wallet Provider to operate or access the WSCD.
INST-5.2-07
The Wallet Provider shall implement mechanisms in the Wallet Instance to detect the presence of known malicious applications or anomalous runtime conditions on the host device that could expose Wallet Unit key material or credentials to unauthorised access, and shall, upon detection, prevent Wallet Unit operations involving access to key material until the threat is resolved.
Requirement · obligation: mandatory · PDF page 23
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's threat detection implementation documentation and confirming that the Wallet Instance responds appropriately to a known malicious application signature or anomalous condition. Where feasible, the CAB may also test the Wallet Instance's behaviour when such a condition is simulated on the test device.
5.3 Installation Process Security
Read section 5.3 in the full text
INST-5.3-01
The Wallet Provider shall distribute the Wallet Instance exclusively through the official app store of the operating system of the Wallet User's device; or, where distribution through alternative channels is necessary, shall implement a mechanism enabling even a Wallet User with low digital savviness to verify the authenticity of the Wallet Instance prior to installation and shall provide the Wallet User with clear instructions for completing that verification.
Requirement · obligation: mandatory · PDF page 23
How a CAB verifies this: A CAB verifies this requirement by confirming: (i) the primary distribution channel is the official OS app store, or (ii) the alternative distribution mechanism and the verification instructions are documented and validated during certification.
INST-5.3-02
The Wallet Provider shall ensure that the Wallet Instance requests only those device permissions strictly necessary for the functioning of declared Wallet Unit features, and shall present the Wallet User with a plain-language explanation of the purpose of each permission at the time it is requested.
Requirement · obligation: mandatory · PDF page 24
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's permission manifest and confirming that each declared permission is linked to a documented Wallet Unit feature, and by inspecting the installation flow to confirm that permission request screens include clear plain-language explanations. Where feasible, the CAB may also walk the installation flow on a test device to observe these explanations.
INST-5.3-03
The Wallet Provider shall ensure that the Wallet Instance, at the time of installation, operates within an operating system-enforced isolation boundary that prevents co-located applications from accessing, reading, or modifying data stored by the Wallet Instance, including PID credentials, Electronic Attestations of Attributes, cryptographic key material, and any personal data processed by the Wallet Instance.
Requirement · obligation: mandatory · PDF page 24
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's technical specification to confirm that the Wallet Instance relies on OS-enforced application sandboxing and that installation is refused on devices where sandboxing cannot be confirmed. Where feasible, the CAB may also attempt to read the Wallet Instance's private data storage from a co-located test application on a compliant device and confirm that access is denied by the OS.
INST-5.3-04
The Wallet Provider shall ensure that the Wallet Instance is shipped with a secure default configuration such that no Wallet Unit functionality is accessible prior to completion of the initial activation process and no personal data is transmitted by the Wallet Instance before the Wallet User has accepted all required privacy disclosures.
Requirement · obligation: mandatory · PDF page 25
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented pre-activation behaviour of the Wallet Instance and confirming that, before activation is complete, no Wallet Unit functionality is accessible, no sensitive data is transmitted, and the application does not accept connections from external services. Where feasible, the CAB may also test a freshly installed Wallet Instance prior to completing activation to confirm this behaviour.
5.4 Wallet User Information and Consent
Read section 5.4 in the full text
INST-5.4-01
The Wallet Provider shall present the Wallet User, prior to completing installation of the Wallet Instance, with clear and comprehensible information about the nature of the wallet, the categories of personal data processed, the applicable terms and conditions, and the security responsibilities of the Wallet User.
Requirement · obligation: mandatory · PDF page 25
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documentation to confirm the content of the required disclosures - covering the categories of personal data, terms and conditions, and security responsibilities - and the mechanism for recording Wallet User consent. Where feasible, the CAB may also perform a fresh installation to confirm that all required disclosures are displayed before installation completes and that installation cannot proceed without acknowledgement of them.
INST-5.4-02
The Wallet Provider shall ensure that the Wallet User is presented with the Wallet Provider's terms of service prior to completing installation of the Wallet Instance, that acceptance constitutes an explicit Wallet User action, and that the Wallet Instance is not operable until that acceptance has been recorded.
Requirement · obligation: mandatory · PDF page 26
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented installation flow and confirming that the terms are presented before it completes, that acceptance requires an explicit Wallet User action, and that the Wallet Instance cannot be used if the acceptance step is bypassed. Where feasible, the CAB may also perform a fresh installation to confirm this behaviour.
INST-5.4-03
The Wallet Provider shall ensure that, prior to completing installation of the Wallet Instance, the Wallet User is provided with a clear and complete description of all categories of personal data processed by the Wallet Unit, the purposes for which each category is processed, and the legal basis under Article 6 of the GDPR applicable to each processing activity.
Requirement · obligation: mandatory · PDF page 26
- Legal references: GDPR
How a CAB verifies this: A CAB verifies this requirement by reviewing the data processing disclosure presented during installation and confirming that: all processing activities are described; the purpose and legal basis for each is stated; and the disclosure is presented in plain language prior to completion of installation.
6.1 WSCD/WSCA Initialisation
Read section 6.1 in the full text
ACT-6.1-01
The Wallet Provider shall ensure that all communication between the Wallet Instance (WI) and the Wallet Secure Cryptographic Application (WSCA) during Wallet Unit activation is conducted over a channel that is mutually authenticated and integrity-protected, so that activation data cannot be intercepted, replayed, or tampered with by a third party.
Requirement · obligation: mandatory · PDF page 28
How a CAB verifies this: A CAB verifies this requirement by reviewing the technical specification of the WIWSCA interface and confirming that mutual authentication and integrity protection are documented and implemented for all supported WSCD architecture types.
ACT-6.1-02
The Wallet Provider shall ensure that all private keys attested in a Key Attestation and all private keys of device-bound PIDs and attestations are generated within the Wallet Secure Cryptographic Device (WSCD), and that those private keys are never extracted from the WSCD in the clear at any point during or after activation.
Requirement · obligation: mandatory · PDF page 28
How a CAB verifies this: A CAB verifies this requirement by reviewing the WSCD's certification documentation and confirming that key generation is an on-device operation and that no key extraction path exists in the clear.
ACT-6.1-03
The Wallet Provider shall verify, before signing and issuing a Key Attestation, that the public keys to be included in that Key Attestation correspond to private keys that were generated by and are stored in the WSCA/WSCD described in that attestation, and that those private keys remain under the exclusive control of the Wallet User.
Requirement · obligation: mandatory · PDF page 28
How a CAB verifies this: A CAB verifies this requirement by examining the key attestation mechanism documented in the Wallet Provider's technical specification and confirming that verification occurs prior to each WUA issuance.
6.2 Wallet Instance Attestation and Key Attestation Issuance
Read section 6.2 in the full text
ACT-6.2-01
The Wallet Provider shall, before issuing a Wallet Instance Attestation, verify that the requesting Wallet Instance is a genuine instance of its Wallet Solution and that the attestation request has not been replayed, forged, or submitted by an unauthorised party.
Requirement · obligation: mandatory · PDF page 29
How a CAB verifies this: A CAB verifies this requirement by reviewing the technical design of the WUA issuance protocol and confirming that both app authenticity verification and replay protection mechanisms are implemented and tested.
ACT-6.2-02
The Wallet Provider shall ensure that the Wallet Instance, during Wallet Unit activation, authenticates the Wallet Provider backend before transmitting any device or WSCD information, so that the Wallet Instance can verify it is communicating with the genuine Wallet Provider and not an impostor.
Requirement · obligation: mandatory · PDF page 29
How a CAB verifies this: A CAB verifies this requirement by reviewing the activation protocol specification and confirming that the Wallet Instance performs backend authentication prior to any transmission of device or WSCD data during activation.
ACT-6.2-03
The Wallet Provider shall ensure that each Key Attestation is cryptographically bound to the keystore of the Wallet Unit by including one or more public keys in the Key Attestation whose corresponding private keys are generated by and stored exclusively in the WSCA/WSCD of the Wallet Unit, so that each Key Attestation is tied to a specific, unique WSCD instance.
Requirement · obligation: mandatory · PDF page 30
How a CAB verifies this: A CAB verifies this requirement by examining the WUA issuance protocol and confirming that each WUA contains at least one public key with a corresponding private key provably stored in the described WSCA/WSCD.
ACT-6.2-04
The Wallet Provider shall ensure that each Key Attestation contains, at minimum: (a) information describing the storage type and the security certification of the WSCA/WSCD or keystore in which the attested private keys are stored; and (b) one or more public keys corresponding to private keys generated by and stored in that WSCA/WSCD or keystore.
Requirement · obligation: mandatory · PDF page 30
How a CAB verifies this: A CAB verifies this requirement by inspecting sample WUAs against the mandatory content list above and confirming compliance with the format specified in [5].
ACT-6.2-05
The Wallet Provider shall ensure that each Wallet Instance Attestation contains, at minimum: (a) information enabling PID Providers and Attestation Providers to check the revocation status of that Wallet Instance Attestation; and (b) a Wallet Unit identifier that does not enable tracking of the Wallet User across transactions.
Requirement · obligation: mandatory · PDF page 30
How a CAB verifies this: A CAB verifies this requirement by inspecting the content of Wallet Instance Attestations issued in production, by confirming that a revocation status reference is present and resolvable, and by confirming that the Wallet Unit identifier is not reused in a form that permits correlation between providers.
ACT-6.2-06
The Wallet Provider shall sign each Wallet Instance Attestation and each Key Attestation using only cryptographic algorithms included in the ECCG Agreed Cryptographic Mechanisms [6].
Requirement · obligation: mandatory · PDF page 31
How a CAB verifies this: A CAB verifies this requirement by reviewing the cryptographic algorithm selection documented in the Wallet Provider's security specification and confirming that contextbinding is implemented for all WUA presentations.
ACT-6.2-07
The Wallet Provider shall bind each Key Attestation to the specific issuance context in which it is presented, either by incorporating a nonce provided by the PID Provider or Attestation Provider into the Key Attestation, or by presenting the Key Attestation together with a Proof-of-Possession signed over that nonce using a private key attested in that Key Attestation.
Requirement · obligation: mandatory · PDF page 31
How a CAB verifies this: A CAB verifies this requirement by reviewing the WUA issuance protocol design and confirming that a Key Attestation presented in an exchange other than the one it was
ACT-6.2-08
The Wallet Provider shall ensure that all unique elements of each Wallet Instance Attestation and each Key Attestation — including the attestation identifier used for revocation status checking, the attested public keys, and the Wallet Provider's signature — have a negligible probability of having the same value across all such attestations issued by that Wallet Provider.
Requirement · obligation: mandatory · PDF page 32
How a CAB verifies this: A CAB verifies this requirement by reviewing the WUA generation implementation and confirming that CSPRNGs are used for all unique elements.
ACT-6.2-09
The Wallet Provider shall manage the validity periods of Wallet Instance Attestations and Key Attestations such that a non-revoked Wallet Unit can at all times present a Wallet Instance Attestation and a Key Attestation each with a remaining validity period of at least 31 days, and shall set validity periods taking into account the risk that such an attestation could become a vector for tracking the Wallet User across multiple issuance transactions.
Requirement · obligation: mandatory · PDF page 32
How a CAB verifies this: A CAB verifies this requirement by reviewing the WUA validity period policy and confirming that renewal processes are tested to ensure uninterrupted WUA availability.
ACT-6.2-10
The Wallet Provider shall re-issue Wallet Instance Attestations and Key Attestations to a non-revoked Wallet Unit as needed throughout the lifetime of the Wallet Unit, ensuring continuity of the Wallet Unit's ability to receive PIDs and device-bound attestations without requiring re-activation.
Requirement · obligation: mandatory · PDF page 32
How a CAB verifies this: A CAB verifies this requirement by confirming that the WUA renewal workflow is documented and tested, and that no degradation in security verification occurs during renewal compared to initial activation.
ACT-6.2-11
The Wallet Provider shall ensure that device binding for all PIDs and devicebound attestations is implemented by having the WSCA/WSCD or keystore generate a dedicated public-private key pair for each PID or device-bound attestation, and by ensuring that the corresponding private key is generated within and remains protected by the WSCA/WSCD or keystore throughout the lifetime of the attestation.
Requirement · obligation: mandatory · PDF page 33
How a CAB verifies this: A CAB verifies this requirement by reviewing the issuance protocol documentation for each attestation type and confirming that a new key pair is generated per issuance, by requesting sample issuance transactions and verifying that the public keys differ, and by confirming that the Wallet Provider's WSCA/WSCD architecture prevents key pair reuse across attestation instances.
ACT-6.2-12
The Wallet Provider shall ensure that every public key to which a PID or a device-bound attestation is bound at issuance is a public key attested in a Key Attestation issued to that Wallet Unit.
Requirement · obligation: mandatory · PDF page 33
How a CAB verifies this: A CAB verifies this requirement by comparing, for a sample of issuances, the public key in the issued credential against the set of public keys attested in the Key Attestation presented during that issuance, and by reviewing the issuance logic that enforces this correspondence. Where feasible, the CAB may also attempt an issuance with a key that is absent from the Key Attestation to confirm that it is refused.
ACT-6.2-13
The Wallet Provider shall establish and maintain a documented policy governing the issuance of Wallet Instance Attestations and Key Attestations that satisfies the requirements of clauses 6 and 7 of [9].
Requirement · obligation: mandatory · PDF page 34
How a CAB verifies this: A CAB verifies this requirement by reviewing the attestation issuance policy against clauses 6 and 7 of [9] and by confirming that the version in force corresponds to the practices observed during the assessment.
ACT-6.2-14
The Wallet Provider shall ensure that the revocation-status-maintenance period of each Wallet Instance Attestation and each Key Attestation it issues to a Wallet Unit is at least as long as the longest administrative validity period of any PID or device-bound Electronic Attestation of Attributes issued into that Wallet Unit on the basis of that Wallet Instance Attestation or Key Attestation, and that the revocation status is maintained throughout that period.
Requirement · obligation: mandatory · PDF page 34
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented policy for setting the revocation-status-maintenance period of Wallet Instance Attestations and Key Attestations and confirming that it is at least as long as the longest administrative validity period of the PIDs and device-bound Electronic Attestations of Attributes issued into the Wallet Unit, and by inspecting issuance records to confirm the committed periods. Where feasible, the CAB may issue a device-bound credential with a long administrative validity and confirm that the maintenance period committed in the corresponding Wallet Instance Attestation and Key Attestation is at least as long.
6.3 Wallet Instance – Wallet Unit Binding
Read section 6.3 in the full text
ACT-6.3-01
The Wallet Provider shall establish the binding between the Wallet Instance and the Wallet Unit by issuing a Wallet Unit Attestation only to a Wallet Instance whose installation has been successfully verified through a platform-level attestation mechanism provided by the device operating system.
Requirement · obligation: mandatory · PDF page 35
How a CAB verifies this: A CAB verifies this requirement by reviewing the WUA issuance protocol specification and confirming that a platform attestation step is performed before any WUA is issued. Where feasible, the CAB may also test whether the activation process rejects a modified Wallet Instance or one running on an environment that does not produce a valid platform attestation.
ACT-6.3-02
The Wallet Provider shall not use persistent device fingerprinting for fraud monitoring or risk assessment purposes; where device-specific identifiers are collected during activation for legitimate operational purposes, the Wallet Provider shall limit collection to the minimum necessary, shall not derive or retain a persistent fingerprint for Wallet User tracking, and shall inform the Wallet User in accordance with the requirements of the General Data Protection Regulation.
Requirement · obligation: mandatory · PDF page 35
How a CAB verifies this: A CAB verifies this requirement by reviewing the data processing inventory of the Wallet Provider and confirming that no persistent device fingerprinting mechanism is implemented for fraud or risk monitoring.
ACT-6.3-03
The Wallet Provider shall ensure that each Wallet Instance holds cryptographic material that can be used to identify unambiguously the Wallet Instance in a way that this cryptographic data cannot be cloned to another device.
Requirement · obligation: mandatory · PDF page 36
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's technical architecture for the Wallet Instance cryptographic material and confirming in the design documentation that the material is generated and stored protected at the level specified in the risk analysis. Where feasible, the CAB may also test that the Wallet Instance cannot be successfully authenticated from a device that lacks the required protection or from a copy of the application data restored to a different device.
ACT-6.3-04
The Wallet Provider shall ensure that the WSCA authenticates the Wallet Instance before performing any cryptographic operation on its behalf, by challenging the Wallet Instance to produce a proof of possession of the cryptographic data mentioned in ACT-5.3-03.
Requirement · obligation: mandatory · PDF page 36
How a CAB verifies this: A CAB verifies this requirement by reviewing the WSCA-to-Wallet-Instance interface protocol specification and confirming that a challenge-response step is performed before each WSCA operation. Where feasible, the CAB may also test that the WSCA rejects requests accompanied by an invalid or absent identity signature.
6.4 Wallet User Account Setup with Wallet Provider
Read section 6.4 in the full text
ACT-6.4-01
The Wallet Provider shall offer the Wallet User the opportunity to authenticate to an existing Wallet User account before offering the creation of a new Wallet User account during Wallet Unit activation.
Requirement · obligation: mandatory · PDF page 37
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented activation flow for a Wallet User who already holds an account and confirming that authentication to the existing account is offered before the option to create a new account. Where feasible, the CAB may also walk the activation flow on a test device to confirm this ordering.
ACT-6.4-02
The Wallet Provider shall not collect or process personal identity data about the Wallet User during Wallet Unit activation beyond what is strictly necessary to complete the activation process and to comply with applicable legal obligations.
Requirement · obligation: mandatory · PDF page 37
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's activation data processing inventory and confirming that each data element has a documented necessity and legal basis. Where feasible, the CAB may also test the activation flow to confirm that no personal identity data beyond the documented minimum is requested or stored.
ACT-6.4-03
The Wallet Provider shall ensure that any modification to the Wallet Unit account configuration after activation requires authenticated and authorised proof from the Wallet Unit or, for emergency procedures, a fresh verification of the Wallet User's identity, and cannot be performed unilaterally by the Wallet Provider without the Wallet User's involvement.
Requirement · obligation: mandatory · PDF page 38
How a CAB verifies this: A CAB verifies this requirement by reviewing the account management procedures and confirming that modification requests submitted to the Wallet Provider backend without a valid Wallet Unit proof of possession are rejected and that the emergency recovery procedure requires documented identity re-verification. Where feasible, the CAB may also test that such a modification request without valid proof of possession is rejected.
ACT-6.4-04
The Wallet Provider shall present the Wallet User with configurable privacy settings during activation, and shall ensure that the default configuration of any optional data processing activity is set to the option that minimises data collection unless the Wallet User has explicitly selected otherwise.
Requirement · obligation: mandatory · PDF page 38
How a CAB verifies this: A CAB verifies this requirement by reviewing the activation Wallet User interface flow and confirming that optional data processing settings are presented and default to the most privacy-protective option, and that the post-activation settings interface allows the Wallet User to view and change privacy choices. Where feasible, the CAB may also exercise the settings interface on a test device to confirm this.
ACT-6.4-05
The Wallet Provider shall establish and maintain a Wallet User account mechanism that enables the Wallet User to request revocation of the Wallet Unit independently of physical access to the device on which the Wallet Instance is installed.
Requirement · obligation: mandatory · PDF page 39
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documentation for a Wallet User account facility that enables device-independent revocation and confirming that the account is established during the activation flow rather than on first use after a loss event. Where feasible, the CAB may also test that the revocation mechanism can be successfully invoked from a device other than the one hosting the Wallet Instance.
ACT-6.4-06
The Wallet Provider shall design the Wallet User account for revocation such that the revocation mechanism is accessible to the Wallet User under adverse conditions — including loss of the device, physical displacement, limited access to communications, or a state of stress — while being sufficiently protected against unauthorised use to prevent a third party from revoking the Wallet Unit of another person without that person's authorisation.
Requirement · obligation: mandatory · PDF page 39
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's threat model and design documentation to confirm that the revocation mechanism has been assessed against multiple adverse-condition scenarios, and that the documented design guidelines explicitly acknowledge the risk asymmetry between inaccessibility and unauthorised revocation.
6.5 Wallet User Authentication Setup
Read section 6.5 in the full text
ACT-6.5-01
The Wallet Provider shall ensure that all authentication verification data associated with authentication factors enrolled during activation is stored either within the WSCA/WSCD or in platform-provided hardware-backed key storage, and is not accessible to any application other than the Wallet Instance.
Requirement · obligation: mandatory · PDF page 40
How a CAB verifies this: A CAB verifies this requirement by reviewing the design documentation for authentication credential storage and confirming that the storage location is hardware-
ACT-6.5-02
The Wallet Provider shall ensure that each authentication factor enrolled during Wallet Unit activation is cryptographically bound to that specific Wallet Unit, such that the same factor presented from any other device, copy, or instance cannot authenticate the holder for actions performed by the Wallet Unit.
Requirement · obligation: mandatory · PDF page 41
How a CAB verifies this: A CAB verifies this requirement by reviewing the design documentation of the Wallet Unit's authentication subsystem and inspecting how factor verification material is stored and protected, confirming that a clone cannot authenticate as the original holder. Where feasible, the CAB may also attempt to perform authentication on a clone of an enrolled Wallet Unit on a separate device using captured factor presentation data and confirm that the clone cannot authenticate.
ACT-6.5-03
The Wallet Provider shall ensure that the Wallet Unit limits the number of consecutive unsuccessful authentication attempts for each knowledge-based factor to a value not exceeding ten, beyond which the factor is locked until the Wallet User re-establishes proof of holder identity through an out-of-band procedure operated by the Wallet Provider.
Requirement · obligation: mandatory · PDF page 41
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Unit's design documentation for the attempt counter and the documented out-of-band unlock procedure, confirming
ACT-6.5-04
The Wallet Provider shall ensure that the Wallet User authentication mechanism established during Wallet Unit activation consists of at least two factors of different categories, each verified by the Wallet Secure Cryptographic Application of the Wallet Unit, such that no Wallet Unit operation involving Person Identification Data, the Wallet Unit Attestation, or other attestations at security level High can complete based solely on the Wallet User-device operating-system authentication mechanism.
Requirement · obligation: mandatory · PDF page 42
How a CAB verifies this: A CAB verifies this requirement by reviewing the design documentation for the authentication subsystem and confirming that for PID, WUA, and security-level-High attestation operations the WSCA performs verification of the Wallet User factor itself rather than relying on the OS authentication result alone. Where feasible, the CAB may also attempt on a test Wallet Unit to perform such an operation while supplying only an OS-level authentication and confirm that the operation is rejected.
6.6 Migration Object import
Read section 6.6 in the full text
ACT-6.6-01
The Wallet Provider shall present the Wallet User with the option to restore a Migration Object from another Wallet Unit from the Wallet User.
Requirement · obligation: mandatory · PDF page 42
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented activation flow and confirming that the Wallet User is offered the option to restore from a Migration Object before the Wallet Unit is activated empty. Where feasible, the CAB may also run the activation flow on a test device to confirm the option is offered.
ACT-6.6-02
When the Wallet User provides a Migration Object, the Wallet Unit shall, upon receiving the decryption password from the Wallet User, import all data from the Migration Object.
Requirement · obligation: mandatory · PDF page 43
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented import procedure and confirming that the correct password is required for a Migration Object to be imported. Where feasible, the CAB may also attempt an import without the password to confirm it fails, then supply the correct password and confirm the data is imported.
ACT-6.6-03
After import of the data from a Migration Object, the Wallet Unit shall offer to guide the Wallet User through the re-issuance of the key bound PID and attestations, allowing the Wallet User to select which PID and EAA to have re-issued at that moment.
Requirement · obligation: mandatory · PDF page 43
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented restore procedure and confirming that the Wallet Unit guides the Wallet User through re-issuance and allows a subset of credentials to be selected. Where feasible, the CAB may also import a Migration Object on a test device to confirm this behaviour.
ACT-6.6-04
If the Wallet User has not chosen to re-issue all PID and EAA in one go, the Wallet User should have the opportunity to restart the process at a later stage.
Requirement · obligation: mandatory · PDF page 43
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented restore procedure and confirming that, when only part of the credential set is re-issued, the Wallet Unit offers a way to re-issue the remaining credentials in a later session. Where feasible, the CAB may also re-issue only part of the credential set during a restore and confirm the remaining credentials can be re-issued later.
ACT-6.6-05 — The Wallet Unit shall support all restore mechanisms specified in [7].
The Wallet Unit shall support all restore mechanisms specified in [7].
Requirement · obligation: mandatory · PDF page 44
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented set of supported Migration Object mechanisms and confirming that the Wallet Unit imports an object produced by each. Where feasible, the CAB may also restore Migration Objects produced by each supported mechanism and confirm that the Wallet Unit imports each correctly.
6.7 Migration Object Setup
Read section 6.7 in the full text
ACT-6.7-01
The Wallet Provider shall present the Wallet User with an explicit choice about whether to create a Migration Object during the Wallet Unit activation process, before the activation process is considered complete.
Requirement · obligation: mandatory · PDF page 44
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented activation flow and confirming that: (i) a dedicated Migration Object choice screen is present; (ii) neither
ACT-6.7-02
When presenting the Migration Object choice, the Wallet Provider shall inform the Wallet User in plain language that without a Migration Object: (a) there will be no list of PID and Wallet Bound EAA for the new Wallet Unit to request reissuance; (b) the transaction log will not be preserved, and the Wallet User will have no means to demonstrate past transactions in the event of a dispute, fraud, or security incident; (c) there will be no mechanism for migrating the non Wallet Bound EAA to a new Wallet Unit.
Requirement · obligation: mandatory · PDF page 45
How a CAB verifies this: A CAB verifies this requirement by reviewing the Migration Object choice screen text and confirming that all three consequence items are explicitly and separately stated in Wallet User-facing language. In localised implementations, each language version is assessed for completeness of all three items.
ACT-6.7-03
The Wallet Provider shall not complete Wallet Unit activation until the Wallet User has explicitly confirmed their choice regarding the Migration Object.
Requirement · obligation: mandatory · PDF page 45
How a CAB verifies this: A CAB verifies this requirement by reviewing the activation flow and confirming that: (i) a distinct Migration Object choice screen is present; (ii) the disclosure covers all three items of ACT-5.7-02; (iii) the activation process cannot be completed without a distinct confirmation action by the Wallet User; (iv) the confirmation is recorded in the activation log.
ACT-6.7-04
[CONDITIONAL] Where the Wallet User chooses to create a Migration Object during activation, the Wallet Unit shall require the Wallet User to designate a storage location for the Migration Object before the activation process is considered complete.
Requirement · obligation: conditional · PDF page 46
How a CAB verifies this: A CAB verifies this requirement by confirming that: (i) when the Wallet User selects the option to create a Migration Object, a storage location selection step is present in the activation flow; (ii) activation cannot complete without a storage location being confirmed; (iii) the designated storage location is recorded in the Wallet Unit's activation record.
ACT-6.7-05
The Wallet Provider shall ensure that at least one storage option offered for the Migration Object is EU based and under the Wallet User’s exclusive control and is not a location controlled by the Wallet Provider.
Requirement · obligation: mandatory · PDF page 46
ACT-6.7-06 — The Wallet Unit shall create the Migration Object in accordance with [7].
The Wallet Unit shall create the Migration Object in accordance with [7].
Requirement · obligation: mandatory · PDF page 47
How a CAB verifies this: A CAB verifies this requirement by creating a Migration Object on a test Wallet Unit and confirming that its structure and protection conform and that it imports successfully on a second Wallet Unit.
7.1 Security Requirements for Non-PID Use Cases
Read section 7.1 in the full text
OPS-7.1-01
The Wallet Provider shall ensure that non-identity attestations stored in the Wallet Unit are protected against unauthorised access or modification by mechanisms equivalent to those applied to PID credentials stored in the same Wallet Unit.
Requirement · obligation: mandatory · PDF page 48
How a CAB verifies this: A CAB verifies this requirement by reviewing the storage and access-control design and confirming that non-identity attestations are held under the same protections as PID credentials and that access to them requires the same controls. Where feasible, the CAB may also test that access to non-identity attestations requires the same controls.
OPS-7.1-02
The Wallet Provider shall ensure that the Wallet Unit discloses data from nonidentity attestations only in response to a verified relying party request and only to the minimum extent necessary to fulfil that request.
Requirement · obligation: mandatory · PDF page 48
How a CAB verifies this: A CAB verifies this requirement by issuing presentation requests from verified and unverified test relying parties and confirming that disclosure occurs only for the verified party and is limited to the requested elements.
OPS-7.1-03
The Wallet Provider shall ensure that the Wallet Unit in the operational state without PID does not complete presentations of credentials or attestations whose issuance or validity depends on a PID credential bound to that Wallet Unit.
Requirement · obligation: mandatory · PDF page 48
How a CAB verifies this: A CAB verifies this requirement by reviewing the design of the operational state and confirming that a Wallet Unit without PID refuses to present attestations whose issuance requires PID binding and does not allow the relying party interaction to proceed to the presentation of PID-dependent credentials. Where feasible, the CAB may also deploy a Wallet Unit in the operational state without PID and attempt such a presentation to confirm it is refused.
7.2 Preparedness for PID Issuance
Read section 7.2 in the full text
OPS-7.2-01
The Wallet Provider shall ensure that the Wallet Unit generates and securely stores within the WSCD all key material required for PID issuance before initiating a PID issuance request with a PID Provider.
Requirement · obligation: mandatory · PDF page 49
How a CAB verifies this: A CAB verifies this requirement by inspecting the issuance flow and confirming that the binding key material exists in the secure cryptographic device before the issuance request is sent.
OPS-7.2-02
The Wallet Provider shall ensure that the Wallet Unit presents the Wallet User with a clear description of the PID issuance process and obtains the Wallet User's explicit consent before initiating a PID issuance request with a PID Provider.
Requirement · obligation: mandatory · PDF page 49
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented PID issuance flow and confirming that a description is shown and that issuance does not proceed until the Wallet User has given explicit consent. Where feasible, the CAB may also run the PID issuance flow to confirm the description is shown and consent is required.
8.1 PID Issuance request
Read section 8.1 in the full text
PID-8.1-01
The Wallet Unit shall obtain the registration certificate of a PID Provider exclusively from the credential issuer metadata published by that PID Provider, as profiled in [5].
Requirement · obligation: mandatory · PDF page 51
How a CAB verifies this: A CAB verifies this requirement by reviewing the provider verification logic of the Wallet Unit and confirming that no alternative retrieval is attempted when the registration certificate is absent from the credential issuer metadata. Where feasible, the CAB may also present the Wallet Unit with credential issuer metadata from which the registration certificate has been removed and confirm that no alternative retrieval is attempted.
PID-8.1-02
The Wallet Unit shall verify, prior to submitting a PID issuance request, that the registration certificate and the access certificate of the PID Provider contain the same unique identifier for that PID Provider.
Requirement · obligation: mandatory · PDF page 51
How a CAB verifies this: A CAB verifies this requirement by reviewing the comparison logic and confirming that a mismatched pair of certificates is detected. Where feasible, the CAB may also
Referenced by: PID-8.1-03
PID-8.1-03
The Wallet Unit shall not submit a PID issuance request where the verification specified in PID-8.1-02 does not confirm that both certificates contain the same unique identifier.
Requirement · obligation: mandatory · PDF page 52
How a CAB verifies this: A CAB verifies this requirement by reviewing the issuance logic and confirming that no issuance request is transmitted when a mismatched pair of certificates is present. Where feasible, the CAB may also present the Wallet Unit with a mismatched pair of certificates and confirm, by observing the network traffic, that no issuance request is transmitted.
PID-8.1-04
The Wallet Unit shall inform the Wallet User where verification of the PID Provider's registration certificate does not confirm that the PID Provider is registered and explain the danger to the Wallet User.
Requirement · obligation: mandatory · PDF page 52
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented handling of a failed registration verification and the message it presents to the Wallet User. Where feasible, the CAB may also trigger a failed registration verification on a test Wallet Unit and inspect the message presented to the Wallet User.
8.2 Binding Wallet Unit to Wallet User Identity Verification
Read section 8.2 in the full text
PID-8.2-01
The Wallet Provider shall ensure that the Wallet Unit accepts PID only after the PID Provider has confirmed, through identity proofing at Level of Assurance High as specified in [2], that the Wallet User is the natural person to whom the PID data uniquely and unambiguously corresponds.
Requirement · obligation: mandatory · PDF page 52
PID-8.2-02
The Wallet Provider shall ensure that the identity proofing result presented by the PID Provider refers unambiguously to the same Wallet User session and Wallet Unit that initiated the PID issuance request, such that the result of identity proofing performed for one Wallet User cannot be redirected to a different Wallet Unit.
Requirement · obligation: mandatory · PDF page 53
How a CAB verifies this: A CAB verifies this requirement by reviewing the technical design of the PID issuance flow and confirming that a valid identity proofing result cannot be redirected to a different Wallet Unit. Where feasible, the CAB may also attempt, in a test environment, to redirect a valid identity proofing result to a different Wallet Unit and confirm that this fails.
PID-8.2-03
The Wallet Provider shall implement controls to detect and interrupt PID issuance flows that exhibit patterns inconsistent with legitimate first-time or renewal issuance for a single Wallet Unit, including repeated rapid issuance attempts and concurrent issuance sessions for the same Wallet Unit.
Requirement · obligation: mandatory · PDF page 53
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented ratelimiting and anomaly detection policy for PID issuance and confirming that the Wallet Provider has a documented process for responding to detected anomalous issuance patterns. Where feasible, the CAB may also test the issuance flow with rapid repeated attempts on a single Wallet Unit to confirm that the rate limit is enforced and further attempts are interrupted.
PID-8.2-04
The Wallet Provider shall ensure that PID binding is initiated only upon verified and cryptographically confirmed successful completion of the required identity verification steps, and that any PID issuance session associated with a failed, interrupted, or unverifiable identity verification result is rejected and cancelled prior to PID storage.
Requirement · obligation: mandatory · PDF page 54
How a CAB verifies this: A CAB verifies this requirement by reviewing the PID issuance protocol specification and confirming that the protocol includes a step in which the Wallet Provider validates a session-bound assertion before initiating binding. Where feasible, the CAB may also test the scenario in which the identity verification service returns an error or no response and confirm that no PID credential is bound to the Wallet Unit in this case.
PID-8.2-05
The Wallet Provider shall ensure that the Wallet Unit does not simultaneously store more than one active PID credential purporting to identify the same natural person, and shall require the Wallet User to remove any existing active PID credential issued by a different PID Provider before a new PID credential from that different PID Provider can be accepted and stored.
Requirement · obligation: mandatory · PDF page 55
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented issuance procedure and status handling and confirming that, when a Wallet Unit already holds an active PID credential, a second PID from a different PID Provider is handled by either (i) prompting the Wallet User to remove the existing PID before the new one can be accepted, or (ii) rejecting the second PID credential if the first is still present, and that the second PID is accepted once the first has been removed. Where feasible, the CAB may also test this scenario on a Wallet Unit that already holds an active PID credential.
8.3 Secure PID Reception Process
Read section 8.3 in the full text
PID-8.3-01
The Wallet Unit shall verify, prior to accepting a PID credential, that the signing certificate of the PID Provider that issued the credential traces to a trust anchor published by the European Commission in the list of trusted entities applicable to PID Providers.
Requirement · obligation: mandatory · PDF page 55
How a CAB verifies this: A CAB verifies this requirement by reviewing the credential validation logic and confirming that a PID credential signed by a key not registered in the trusted list is rejected without being accepted or stored. Where feasible, the CAB may also present such a credential to the Wallet Unit and confirm that it is rejected without being accepted or stored.
PID-8.3-02
The Wallet Unit shall reject a PID credential whose signing certificate traces to a trust anchor other than a trust anchor published by the European Commission in the list of trusted entities applicable to PID Providers, established in accordance with [12].
Requirement · obligation: mandatory · PDF page 56
How a CAB verifies this: A CAB verifies this requirement by reviewing the trust anchor validation logic and confirming that a credential signed under an anchor not sourced from the trusted list is rejected. Where feasible, the CAB may also install an additional trust anchor on a test device, present a credential signed under that anchor, and confirm that the Wallet Unit rejects the credential.
PID-8.3-03
The Wallet Provider shall ensure that, for each PID issuance, the Wallet Unit generates a dedicated asymmetric key pair (the PID binding key pair) within the Wallet Secure Cryptographic Device (WSCD), and that the PID issuance request submitted to the PID Provider includes a cryptographic proof of possession of the PID binding private key together with a Key Attestation from the Wallet Provider confirming that the PID binding private key is generated, stored within, and non-extractable from the WSCD.
Requirement · obligation: mandatory · PDF page 56
How a CAB verifies this: A CAB verifies this requirement by reviewing the technical specification of the PID issuance flow and confirming the presence of proof of possession and Key Attestation in the issuance request.
PID-8.3-04
The Wallet Provider shall ensure that the PID Provider binds the issued PID credential to the PID binding public key, such that the credential can only be presented by the Wallet Unit holding the corresponding PID binding private key.
Requirement · obligation: mandatory · PDF page 57
How a CAB verifies this: A CAB verifies this requirement by reviewing the presentation validation logic and confirming that a PID credential cannot be presented from a Wallet Unit that does not hold the PID binding private key corresponding to the public key in the credential.
PID-8.3-05
The Wallet Provider shall ensure that, upon any PID issuance or re-issuance, the Wallet Unit generates a PID binding key pair that is unique to that issuance event and has not been used as the PID binding key pair for any other PID credential issued to the same Wallet Unit, so that the compromise of one PID binding private key does not affect the security of any other PID credential.
Requirement · obligation: mandatory · PDF page 57
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's technical specification and confirming that it mandates fresh key generation for every PID issuance event. Where feasible, the CAB may also initiate two successive PID issuances for the same Wallet Unit and compare the PID binding public keys included in the respective proof of possession claims, expecting the two public keys to be different.
PID-8.3-06
The Wallet Unit shall verify the cryptographic integrity and authenticity of a received PID credential before storing it, including verification of the PID Provider's digital signature over the credential, the credential's validity period, and conformance of the credential format with the applicable technical specification.
Requirement · obligation: mandatory · PDF page 58
How a CAB verifies this: A CAB verifies this requirement by reviewing the credential validation logic and confirming that a PID credential with a tampered payload that invalidates the issuer signature is detected and rejected without being stored. Where feasible, the CAB may also present such a tampered credential and confirm that the Wallet Unit detects the invalid signature and rejects the credential without storing it.
PID-8.3-07
The Wallet Provider shall ensure that the delivery of a PID credential from the PID Provider to the Wallet Unit takes place in conformance with the requirements specified in ETSI TS 119 472-3 [5], applying any additional protective measures required to prevent observation, modification, or interception of the credential payload by parties intermediating the communication path.
Requirement · obligation: mandatory · PDF page 58
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's technical documentation to confirm that the PID issuance protocol implemented by the Wallet Instance conforms to the requirements defined for the Wallet in ETSI TS 119 472-3 [5]. The CAB verifies that the solution passed the OpenID Foundation self-certification positively. The CAB additionally examines functional test results for the issuance flow, covering the authorisation code flow and, where applicable, the pre-authorised code flow, and confirms correct handling of the WIA, WUA, and access certificate verification steps specified in ETSI TS 119 472-3 [5].
PID-8.3-08
The Wallet Provider shall ensure that, before the Wallet Unit signs the proof of possession that binds a PID credential to the Wallet Unit, the Wallet User has successfully authenticated to the Wallet Unit using the authentication mechanism established during Wallet Unit activation.
Requirement · obligation: mandatory · PDF page 59
How a CAB verifies this: A CAB verifies this requirement by reviewing the issuance flow documentation and confirming that the Wallet Unit signing event for the proof of possession is gated by Wallet User authentication. Where feasible, the CAB may also attempt on a test Wallet Unit to trigger PID binding from a state in which no recent authentication has occurred and confirm that the binding does not proceed without prompting the Wallet User to authenticate.
8.4 PID Storage and Protection
Read section 8.4 in the full text
PID-8.4-01
The Wallet Provider shall ensure that the PID binding private key associated with each issued PID credential is generated within the WSCD of the Wallet Unit, stored exclusively within that WSCD, and protected from extraction in plaintext form throughout the lifecycle of that PID credential.
Requirement · obligation: mandatory · PDF page 60
How a CAB verifies this: A CAB verifies this requirement by reviewing the technical architecture documentation for the Wallet Unit, confirming that PID binding key pairs are generated using the WSCD’s internal key generation functionality, and confirming that the WSCD enforces non-extractability of private key material through its access control and export policy mechanisms.
PID-8.4-02
The Wallet Provider shall ensure that all personal data stored by the Wallet Instance, including Person Identification Data, Electronic Attestations of Attributes, transaction log entries, and any other personal data of the Wallet User, is encrypted at rest using a cryptographic key whose use is authorized only after successful Wallet User authentication via the authentication mechanism established during Wallet Unit activation.
Requirement · obligation: mandatory · PDF page 60
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Instance's storage layout and the key-derivation or key-release path, confirming that PID credential data on disk is ciphertext and that the path requires Wallet User authentication. Where feasible, the CAB may also inspect the storage in a controlled environment and attempt to read the PID credential from the device's file system without supplying Wallet User authentication, confirming that no readable PID payload is recoverable.
PID-8.4-03
The Wallet Provider shall ensure that the Wallet Unit requires successful Wallet User authentication before presenting any PID credential to a relying party, using the authentication mechanism established during Wallet Unit activation at the assurance level applicable to the Wallet Unit.
Requirement · obligation: mandatory · PDF page 61
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented presentation flow and confirming that a PID presentation cannot complete without Wallet User authentication on the Wallet Unit and that a session established for device unlock alone does not bypass this gate. Where feasible, the CAB may also attempt to initiate a PID presentation without first completing Wallet User authentication and confirm that the Wallet Unit refuses to complete the presentation.
PID-8.4-04
The Wallet Provider shall ensure that the Wallet Unit requires successful Wallet User authentication, using the authentication mechanism established during Wallet Unit activation, before rendering any value of a Person Identification Data attribute in its Wallet User interface.
Requirement · obligation: mandatory · PDF page 61
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented PID credential view behaviour and confirming that credential values are not rendered until the Wallet User supplies the wallet authentication factor, even after operating-system unlock without prior wallet authentication. Where feasible, the CAB may also open the Wallet Unit on a test device after operating-system unlock, navigate to the PID credential view, and confirm that the values are not rendered until the wallet authentication factor is supplied.
8.5 Wallet User Activation of PID
Read section 8.5 in the full text
PID-8.5-01
The Wallet Provider shall ensure that the PID activation process verifies, through the authentication mechanism established during Wallet Unit Activation, that the Wallet User completing the activation is the same individual who initiated PID issuance, before the Wallet Unit transitions to a state in which PID presentation is permitted.
Requirement · obligation: mandatory · PDF page 62
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's technical documentation of the activation flow and confirming that it requires a fresh authentication event bound to the Wallet Unit's established authentication mechanism and that no alternative pathway to activation exists. Where feasible, the CAB may also attempt to activate a PID on a test Wallet Unit while bypassing or substituting the
PID-8.5-02
The Wallet Provider shall ensure that the Wallet Unit requires the Wallet User's explicit confirmation before marking a received PID credential as active and available for presentation to relying parties.
Requirement · obligation: mandatory · PDF page 63
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented activation behaviour and confirming that a delivered PID cannot be presented until the Wallet User has explicitly confirmed activation. Where feasible, the CAB may also deliver a test PID to a Wallet Unit and confirm that it cannot be presented until the Wallet User has explicitly confirmed activation.
9.1 Software Updates and Patches
Read section 9.1 in the full text
MAINT-9.1-01
The Wallet Provider shall apply the same documented change-control, codesigning, and distribution-channel controls to every Wallet Instance software update as those required for initial deployment, such that no update bypasses or relaxes the controls established for the original software release.
Requirement · obligation: mandatory · PDF page 64
How a CAB verifies this: A CAB verifies this requirement by reviewing the update history of the previous 12 months, by sampling change-records to confirm that signing, supply-chain, and operator-logging controls were applied to each, and by interviewing release engineers to confirm no informal expedited path exists outside the documented process.
MAINT-9.1-02
The Wallet Provider shall ensure that each update to the Wallet Instance is verified, before deployment, to confirm that the update does not remove or reduce the operating system-level isolation mechanisms that protect data stored by the Wallet Instance from access by co-located applications, and shall refuse to apply an update that would reduce the Wallet Instance's isolation capabilities below the level verified during installation.
Requirement · obligation: mandatory · PDF page 64
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's update verification procedure and confirming that the procedure explicitly includes a check for changes to application storage configuration, permissions, and inter-process communication interfaces. The CAB may additionally apply a test update that introduces an intentional weakening of isolation and confirm that the Wallet Provider's verification process detects and rejects such an update.
MAINT-9.1-03
[CONDITIONAL] Where the Wallet Provider permits rollback to a previous software version of the Wallet Instance, the Wallet Provider shall ensure that the rollback does not result in the reinstatement of a version with known security vulnerabilities or a reduction of the security baseline established by the version in force before the rollback.
Requirement · obligation: conditional · PDF page 65
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented rollback controls and confirming that rollback to a version with a known vulnerability is refused or constrained to a version that preserves the security baseline. Where feasible, the CAB may also attempt to roll back a test Wallet Instance to a version with a known vulnerability and confirm that the rollback is refused or so constrained.
MAINT-9.1-04 — The Wallet Provider shall notify the Wallet User when an update to the Wallet Instance is available.
The Wallet Provider shall notify the Wallet User when an update to the Wallet Instance is available.
Requirement · obligation: mandatory · PDF page 65
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's update-notification process and confirming that Wallet Users are informed when an update is available, for instance by examining the notification design and records of past notifications, and, where feasible, by observing a notification on a test device.
MAINT-9.1-05
[CONDITIONAL] Where an update to the Wallet Instance remediates a security vulnerability or is necessary to maintain the security baseline of the Wallet Unit, the Wallet Provider shall make the installation of that update a precondition for continued use of the Wallet Unit.
Requirement · obligation: conditional · PDF page 66
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's update policy and its classification of security-remediating updates, and confirming that such an update is made a precondition for continued use, for instance by examining the enforcement design and records of a past mandatory update, and, where feasible, by confirming on a test device that the Wallet Unit does not continue to operate on the superseded version once such an update is available.
9.2 Re-authentication and Session Management
Read section 9.2 in the full text
MAINT-9.2-01
The Wallet Provider shall define and enforce a maximum inactivity period after which an authenticated session within the Wallet Unit is automatically invalidated and the Wallet User is required to re-authenticate before any Wallet Unit operation may proceed.
Requirement · obligation: mandatory · PDF page 66
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented session timeout design and confirming that an operation after the defined idle period requires reauthentication. Where feasible, the CAB may also leave a test Wallet Unit idle past the defined period and confirm that a subsequent operation requires re-authentication.
MAINT-9.2-02
The Wallet Provider shall ensure that the Wallet Unit requires Wallet User re-authentication before performing any sensitive operation, including presentation of credentials to a relying party, modification of enrolled authentication factors, and access to stored PID or attestation data following session expiry.
Requirement · obligation: mandatory · PDF page 67
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented session handling and confirming that each listed operation on a Wallet Unit with an expired session requires re-authentication before it proceeds. Where feasible, the CAB may also attempt each listed operation on a Wallet Unit with an expired session and confirm that reauthentication is required before it proceeds.
MAINT-9.2-03
The Wallet Provider shall ensure that the Wallet Unit does not retain PID data or other personal data in unprotected memory or storage beyond the scope of a single presentation transaction, and that any temporary copies of such data created during a transaction are securely erased upon completion or termination of that transaction.
Requirement · obligation: mandatory · PDF page 67
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Unit’s data handling implementation for presentation flows and confirming that personal data is not retained in application-layer storage after the transaction. The CAB also tests this by inspecting device memory state or application storage after a completed presentation transaction.
9.3 Key Rotation and Renewal
Read section 9.3 in the full text
MAINT-9.3-01
The Wallet Provider shall ensure that all cryptographic key material subject to rotation is generated within the WSCD and remains within the WSCD throughout the key rotation process, and that superseded key material is irrevocably deleted from the WSCD upon successful completion of rotation.
Requirement · obligation: mandatory · PDF page 68
How a CAB verifies this: A CAB verifies this requirement by reviewing the key rotation implementation and confirming that key generation occurs within the WSCD, that key material does not pass through application-layer code in plaintext during rotation, and that completion of rotation is confirmed before the superseded key is deleted.
MAINT-9.3-02
The Wallet Provider shall ensure that key rotation and Wallet Unit software update operations are performed in a manner that preserves the security level of the Wallet Unit throughout the operation, such that no transient or permanent reduction in cryptographic strength occurs, and that any operation that cannot be completed without reducing security is automatically aborted and the Wallet Unit restored to its pre-operation security state.
Requirement · obligation: mandatory · PDF page 68
How a CAB verifies this: A CAB verifies this requirement by reviewing the key rotation and update procedure documentation and confirming that the procedure specifies the conditions under which a rollback is triggered and how the restoration of the pre-operation state is verified. Where feasible, the CAB may also test failure scenarios, such as interrupting the rotation at different stages, and confirm that the Wallet Unit remains fully operational at the original security level after each aborted attempt.
MAINT-9.3-03
The Wallet Provider shall implement and document procedures for renewing Wallet Instance Attestations and Key Attestations before their expiry date and shall ensure that the expiry of such an attestation does not cause an unplanned interruption to Wallet Unit availability.
Requirement · obligation: mandatory · PDF page 69
How a CAB verifies this: A CAB verifies this requirement by reviewing the renewal procedure and its timing and by confirming, on a test Wallet Unit, that an attestation approaching expiry is renewed before availability is affected.
MAINT-9.3-04
The Wallet Provider shall ensure that renewal of the Wallet Instance Attestation and the Key Attestation and re-issuance of PID credentials and Electronic Attestations of Attributes during the maintenance phase applies the same security controls, cryptographic key generation procedures, and assurance requirements as the initial issuance process for the same credential type, and shall not implement a renewal path that bypasses or reduces any security requirement that applied during initial issuance.
Requirement · obligation: mandatory · PDF page 69
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented renewal procedures for each credential type and confirming that each renewal step is equivalent to the corresponding initial issuance step with no steps omitted or simplified. The CAB may additionally perform a renewal in a test environment, inspect the resulting credential and audit log, and confirm that all required security steps were completed and logged at the same level of evidence as an initial issuance.
9.4 PID and EAA Lifecycle Management
Read section 9.4 in the full text
MAINT-9.4-01
The Wallet Provider shall ensure that, upon expiry of the validity period of a PID credential or Electronic Attestation of Attributes, the Wallet Unit refuses to present the expired credential to any Relying Party.
Requirement · obligation: mandatory · PDF page 70
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented validity-checking behaviour and confirming that the Wallet Unit refuses to present an expired credential to a Relying Party. Where feasible, the CAB may also issue a test credential with a short validity period, advance the system clock past the expiry date, and confirm that the Wallet Unit refuses to present the expired credential to a test Relying Party.
MAINT-9.4-02
The Wallet Provider shall ensure that, upon revocation of a PID credential or Electronic Attestation of Attributes by its Provider, the Wallet Unit refuses to present the revoked credential to any Relying Party, and shall implement a mechanism to check and maintain awareness of the revocation status of all PID credentials and Electronic Attestations of Attributes stored in the Wallet Unit.
Requirement · obligation: mandatory · PDF page 70
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented revocation-checking architecture and confirming it is appropriate for each credential format and Provider in use and that a revoked credential is detected within the documented maximum staleness interval and no longer presented. Where feasible, the CAB may also revoke a test PID credential or Electronic Attestation of Attributes on the Provider's system while the Wallet Unit holds a valid copy and confirm that the Wallet Unit detects the revocation within that interval and subsequently refuses to present the credential.
MAINT-9.4-03
The Wallet Provider shall ensure that the Wallet Unit clearly indicates the expired or revoked status of any PID credential or Electronic Attestation of Attributes in any Wallet User interface that displays the credential.
Requirement · obligation: mandatory · PDF page 71
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Unit's user interface design and confirming that expired and revoked states are each clearly indicated to the Wallet User and that the indicators distinguish between expired and revoked status. Where feasible, the CAB may also issue a test credential with a short validity period and separately revoke a test credential and confirm that both states are clearly and distinctly indicated in the Wallet User interface.
MAINT-9.4-04
The Wallet Provider shall apply, to every renewal or re-issuance of a PID credential or Electronic Attestation of Attributes to the Wallet Unit, the same authentication, identity-proofing, and cryptographic-binding requirements as those required for the initial issuance of that credential type.
Requirement · obligation: mandatory · PDF page 72
How a CAB verifies this: A CAB verifies this requirement by reviewing the renewal flow documentation, comparing the implementation steps of renewal and initial issuance to confirm equivalence, and sampling renewal records to confirm that fresh proofing assertions and fresh binding keys are present. Where feasible, the CAB may also attempt on a test Wallet Unit to initiate renewal of an expired PID without supplying fresh proofing and confirm that the renewal is refused.
MAINT-9.4-05
The Wallet Provider shall ensure that the Wallet Unit provides the Wallet User with the ability to delete individual attestations, and that deletion results in the removal of the credential data from the Wallet Unit.
Requirement · obligation: mandatory · PDF page 72
How a CAB verifies this: A CAB verifies this requirement by deleting a test attestation and confirming that its data no longer resides in the Wallet Unit.
MAINT-9.4-06
The Wallet Provider shall ensure that, upon deletion of a PID credential or an Electronic Attestation of Attributes from the Wallet Unit, every registration of that credential with an operating system interface through which relying parties can request its presentation is removed.
Requirement · obligation: mandatory · PDF page 73
How a CAB verifies this: A CAB verifies this requirement by deleting a credential on a test device and then querying the operating system presentation interface to confirm that the credential is no longer offered.
9.5 Wallet User Support
Read section 9.5 in the full text
MAINT-9.5-01
The Wallet Provider shall ensure that all Wallet User support processes for Wallet Unit-related requests include verification of the Wallet User's identity before any action affecting the Wallet Unit account is taken by support staff.
Requirement · obligation: mandatory · PDF page 73
How a CAB verifies this: A CAB verifies this requirement by reviewing the support procedures and confirming that a support action affecting an account is refused until the Wallet User's identity has been verified. Where feasible, the CAB may also test that such a support action is refused until the Wallet User's identity has been verified.
MAINT-9.5-02
The Wallet Provider shall ensure that any process by which a Wallet User who is unable to authenticate using an existing enrolled authentication factor resets that authentication factor requires identity re-verification at an assurance level equivalent to the assurance level of the Wallet Unit before the reset is permitted.
Requirement · obligation: mandatory · PDF page 74
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented factor-reset process and confirming that it requires identity re-verification at an assurance level equivalent to the Wallet Unit's before the reset completes. Where feasible, the CAB may also exercise the factor-reset process and confirm that it requires such identity reverification before completing.
MAINT-9.5-03
The Wallet Provider shall establish, maintain, and communicate to the Users a clear and accessible procedure through which a Wallet User can report the confirmed or suspected loss or theft of the device hosting the Wallet Unit without requiring physical access to the original device.
Requirement · obligation: mandatory · PDF page 74
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented notification procedure and confirming that: the procedure does not require the original device; the procedure is communicated to Users at Wallet Unit activation; and the procedure leads to revocation of the Wallet Unit without unreasonable delay.
MAINT-9.5-04
The Wallet Provider shall, upon receiving a credible report of loss or theft of the device hosting a Wallet Unit, revoke that Wallet Unit promptly and prior to establishing any replacement Wallet Unit for the same Wallet User.
Requirement · obligation: mandatory · PDF page 74
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented revocation procedure for lost and stolen devices and confirming that: revocation precedes any replacement issuance; the defined maximum revocation interval is respected; and revocation is verified in a conformance test scenario.
MAINT-9.5-05
The Wallet Provider shall ensure that the process for establishing a replacement Wallet Unit following a confirmed or suspected compromise of the existing Wallet Unit or its authentication factors applies the same security requirements as the initial installation and activation process, including identity verification at the applicable Assurance Level for each credential type to be re-issued.
Requirement · obligation: mandatory · PDF page 75
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider’s documented replacement procedure and confirming that each step required during initial activation is also required during replacement. The CAB may also simulate a replacement scenario and verify that the Wallet Provider does not offer any shortcut path to reissuance that would omit required verification steps.
Referenced by: MAINT-9.5-06
MAINT-9.5-06
The Wallet Provider shall ensure that a revocation of a Wallet Unit, or the establishment of a replacement Wallet Unit under MAINT-9.5-05, that support staff carry out on behalf of a Wallet User takes effect only after a second member of staff has approved it.
Requirement · obligation: mandatory · PDF page 75
How a CAB verifies this: A CAB verifies this requirement by reviewing the support procedure and the tooling and by examining a sample of cases.
Referenced by: MAINT-9.5-07, MAINT-9.5-08
MAINT-9.5-07
The Wallet Provider shall record the two approvals under MAINT-9.5-06 in a log that is protected against undetected modification.
Requirement · obligation: mandatory · PDF page 76
How a CAB verifies this: A CAB verifies this requirement by reviewing the logging design and by examining log samples.
MAINT-9.5-08
The Wallet Provider shall determine, as part of its risk assessment, the maximum time within which the second approval under MAINT-9.5-06 is given.
Requirement · obligation: mandatory · PDF page 76
How a CAB verifies this: A CAB verifies this requirement by reviewing the risk assessment and the documented maximum time.
Referenced by: MAINT-9.5-09
MAINT-9.5-09
The Wallet Provider shall ensure that the second approval under MAINT9.5-06 is given within the maximum time determined under MAINT-9.5-08.
Requirement · obligation: mandatory · PDF page 76
How a CAB verifies this: A CAB verifies this requirement by reviewing the monitoring and by examining records of approval times.
9.6 Backup and Restore
Read section 9.6 in the full text
MAINT-9.6-01
The Wallet Provider shall document the scope and limitations of the Wallet Unit backup mechanism (the Migration Object), including which data elements are included in and excluded from the backup, and shall communicate these limitations to the Wallet User before the Wallet User activate the automated backup creation.
Requirement · obligation: mandatory · PDF page 76
How a CAB verifies this: A CAB verifies this requirement by reviewing the backup documentation and confirming, in the Wallet User flow, that the limitations are communicated before automated backup is activated.
MAINT-9.6-02
The Wallet Provider shall ensure that any backup is encrypted before being stored or transmitted outside the Wallet Unit, using an encryption password that is known only to the Wallet User.
Requirement · obligation: mandatory · PDF page 77
How a CAB verifies this: A CAB verifies this requirement by reviewing the backup implementation and confirming that PID and attestation data is encrypted before being stored or transmitted outside the Wallet Unit, that the backup encryption key is stored separately from the backup data, and that the encryption key itself is protected with access controls appropriate to its sensitivity.
MAINT-9.6-03
The Wallet Provider shall inform the Wallet User that the encryption password should be stored separately from the backup in a location that is only accessible to the Wallet User.
Requirement · obligation: mandatory · PDF page 77
How a CAB verifies this: A CAB verifies this requirement by confirming that the Wallet User is informed, as part of the backup flow, to store the encryption password separately from the backup.
MAINT-9.6-04
The Wallet Provider shall ensure that the confidentiality of the backup data does not depend on the storage location, such that the backup remains unreadable to the Wallet Provider and to the operator of any storage location offered or used, and the ability to decrypt it rests solely on a secret held by the Wallet User.
Requirement · obligation: mandatory · PDF page 77
How a CAB verifies this: A CAB verifies this requirement by reviewing the backup key-management design and confirming that decryption depends only on a Wallet-User-held secret and that neither the Wallet Provider nor any offered storage operator holds that secret, for instance by inspecting the key-management documentation and, where feasible, by retrieving a stored backup and confirming no plaintext is recoverable without the user secret.
MAINT-9.6-05
The Wallet Provider shall ensure that when a Wallet User restores a backup to a different device the target Wallet Unit will remind the Wallet User to revoke the source Wallet Unit if it will no longer be used by the Wallet User and provide him with any information that the Wallet Provider may collect that would help the Wallet User to do so.
Requirement · obligation: mandatory · PDF page 78
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented restore flow and confirming that, on restoring a backup to a new device, the Wallet User is reminded to revoke the old Wallet Unit and given the available supporting information. Where feasible, the CAB may also restore a backup to a new test device and confirm that the reminder and supporting information are provided.
MAINT-9.6-06
The Wallet Provider shall update the Migration Object to reflect the current state of all PID credentials, attestations, and transaction log entries after every transaction performed by the Wallet Unit. A transaction for the purposes of this requirement includes any presentation of a PID or EAA to a relying party, any issuance or deletion of an attestation, and any key rotation event.
Requirement · obligation: mandatory · PDF page 78
MAINT-9.6-07
The Wallet Provider shall not present a Migration Object to the Wallet User as current if the Migration Object does not reflect the most recently confirmed wallet state, without displaying an accompanying notification that the Migration Object is outdated.
Requirement · obligation: mandatory · PDF page 79
How a CAB verifies this: A CAB verifies this requirement by examining a test Wallet Unit whose Migration Object update timestamp predates the most recently confirmed transaction, and confirming that: (i) the object is not displayed to the Wallet User as current or up to date; (ii) the staleness notification is displayed and includes the last update timestamp; (iii) the notification cannot be dismissed in a way that causes the object to subsequently appear as a current backup.
MAINT-9.6-08
[CONDITIONAL] The Wallet Provider shall ensure that, where the Wallet Unit cannot update the Migration Object because the storage location selected by the Wallet User is no longer accessible to it, the Wallet Unit prompts the Wallet User to restore access to that location or to select a new storage location.
Requirement · obligation: conditional · PDF page 79
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Unit's handling of a failed Migration Object update and confirming that an inaccessible location leads to a Wallet User prompt to restore access or choose a new location, for instance by inspecting the error-handling design and, where feasible, by making the selected location unreachable on a test device and observing the prompt.
9.7 Security and Compliance Monitoring
Read section 9.7 in the full text
MAINT-9.7-01
The Wallet Provider shall monitor the continued adequacy of the authentication factors associated with each Wallet Unit for the applicable Assurance Level and shall require the Wallet User to establish new or updated authentication factors — through a process that meets the same security requirements as the initial activation — where the operating system, Wallet Secure Cryptographic Device, or applicable conformity framework indicates that existing factors no longer meet the requirements for the applicable Assurance Level.
Requirement · obligation: mandatory · PDF page 80
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's monitoring procedures and confirming that the procedure covers all conditions under which authentication factors may become inadequate, that the procedure triggers an update requirement when any monitored condition is detected, and that the update process applies the same security requirements as initial activation. The CAB may additionally present a Wallet Unit whose WSCD attestation has expired (if available) and confirm that the Wallet Unit requires re-attestation before presentations are permitted.
MAINT-9.7-02
The Wallet Provider shall conduct documented periodic reviews of the security controls and procedures governing the Wallet Unit infrastructure, at intervals not exceeding twelve months, to verify that the controls remain effective and continue to satisfy the requirements for the applicable Assurance Level, and shall document identified findings and implement remediation within a timeframe commensurate with the severity of each finding.
Requirement · obligation: mandatory · PDF page 81
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documentation of recent security reviews and confirming that: (i) reviews have been conducted at intervals not exceeding twelve months; (ii) findings are documented with severity ratings; (iii) remediation has been completed within the defined timeframes or escalated with documented justification. The CAB also reviews the most recent security review report to assess its scope and confirm that it covers the areas specified in this requirement.
9.8 Data Management and Retention
Read section 9.8 in the full text
MAINT-9.8-01
The Wallet Provider shall maintain a documented data management policy that specifies, for each category of operational record generated during the Wallet Unit's active lifetime, the legal basis for retention, the defined retention period, the storage protection requirements, and the deletion or anonymisation mechanism, and shall implement and consistently apply this policy across all Wallet Units and associated backend systems.
Requirement · obligation: mandatory · PDF page 81
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented data management policy and confirming that: (i) all operational record categories are enumerated with documented legal basis, retention period, storage protection requirements, and deletion mechanism for each; (ii) the policy is implemented and consistently applied across all systems. The CAB may additionally inspect records for a sample of active Wallet Units to verify that retention periods and protection requirements are applied in accordance with the documented policy.
9.9 Trust Anchor Management
Read section 9.9 in the full text
MAINT-9.9-01
The Wallet Provider shall retrieve, at intervals not exceeding 24 hours, the current version of each trusted list as specified in [8] and of each list of trusted entities established in accordance with [12] that is applicable to the parties with which its Wallet Units interact.
Requirement · obligation: mandatory · PDF page 82
How a CAB verifies this: A CAB verifies this requirement by reviewing the retrieval schedule and its monitoring, and by sampling the retrieval logs over a representative period to confirm that the interval was respected and that failures were followed up.
Referenced by: MAINT-9.9-02, MAINT-9.9-03
MAINT-9.9-02
The Wallet Provider shall distribute to every non-revoked Wallet Unit each trust anchor that has been newly published in a list retrieved under MAINT-9.9-01.
Requirement · obligation: mandatory · PDF page 82
How a CAB verifies this: A CAB verifies this requirement by observing, on a test Wallet Unit, that an anchor newly added to a source list becomes available to the Wallet Unit, and by reviewing the distribution mechanism and its integrity protection.
Referenced by: MAINT-9.9-04
MAINT-9.9-03
The Wallet Provider shall withdraw from every valid Wallet Unit each trust anchor that has been removed from, or invalidated in, a list retrieved under MAINT-9.9-01.
Requirement · obligation: mandatory · PDF page 83
How a CAB verifies this: A CAB verifies this requirement by removing an anchor from a source list, confirming on a test Wallet Unit that credentials authenticated under it are subsequently refused, and by reviewing the records of Wallet Units that have not yet confirmed the withdrawal.
MAINT-9.9-04
The Wallet Provider shall ensure that a Wallet Unit accepts only the trust anchors distributed to it by the Wallet Provider under MAINT-9.9-02.
Requirement · obligation: mandatory · PDF page 84
How a CAB verifies this: A CAB verifies this requirement by adding an anchor to the operating system trust store of a test device and confirming that material authenticated under that anchor is not accepted by the Wallet Unit.
10.1 Migration Initiation and Authorisation
Read section 10.1 in the full text
MIG-10.1-01
The Wallet Provider shall ensure that migration of a Wallet Unit is initiated solely by the Wallet User from the source Wallet Unit, including where the target Wallet Unit is operated by a different Wallet Provider, and that no authorisation, approval, or notification by the Wallet Provider is required as a precondition for initiating migration.
Requirement · obligation: mandatory · PDF page 85
How a CAB verifies this: A CAB verifies this requirement by inspecting the Wallet Unit Wallet User interface for a Wallet User-accessible migration trigger and reviewing the Wallet Provider's documentation for any policy or procedure that would gate Wallet User-initiated migration, confirming that no Wallet-Provider-side authorisation or approval step is required. Where feasible, the CAB may also initiate migration on a test Wallet Unit and confirm that no such authorisation or approval step is encountered.
10.2 Secure Data Transfer Mechanisms
Read section 10.2 in the full text
MIG-10.2-01
The Wallet Provider shall ensure that at all times an updated Migration Object will be available in the storage location selected by the Wallet User.
Requirement · obligation: mandatory · PDF page 85
How a CAB verifies this: A CAB verifies this requirement by changing the contents of a test Wallet Unit and confirming that the Migration Object in the selected storage location is updated to reflect the change.
MIG-10.2-02
The Wallet Provider shall ensure that the Migration Object is stored in external or remote storage only in an encrypted form that protects its confidentiality, integrity, and authenticity, and that only the Wallet User holds the cryptographic material required to decrypt it.
Requirement · obligation: mandatory · PDF page 86
How a CAB verifies this: A CAB verifies this requirement by retrieving a stored Migration Object from the external or remote storage location and confirming that it is stored in an encrypted form from which no plaintext data is recoverable without the Wallet User's secret. The CAB additionally reviews the Wallet Provider's documentation to confirm that the decryption key is not stored on or derivable by the Wallet Provider's infrastructure, and that no Wallet Provider-side pathway exists to access the plaintext content of the Migration Object.
MIG-10.2-03
Prior to presenting the Wallet User with the option to finalise migration and revoke the source Wallet Unit, the Wallet Provider shall verify that the target Wallet Unit is in an active state.
Requirement · obligation: mandatory · PDF page 86
MIG-10.2-04
The Wallet Provider shall revoke the source Wallet Unit upon the Wallet User’s explicit decision to finalise the migration.
Requirement · obligation: mandatory · PDF page 87
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented migration flow and its logging and confirming that: (1) the finalisation screen describes the revocation consequence in clear terms; (2) revocation is recorded in the migration log with the authenticated Wallet User session timestamp. Where feasible, the CAB may also test the migration flow to confirm this behaviour.
MIG-10.2-05
The Wallet Provider shall not prevent or delay revocation of the source Wallet Unit on the grounds that the Wallet User has not yet requested reissuance of some or all Electronic Attestations of Attributes held in the source Wallet Unit.
Requirement · obligation: mandatory · PDF page 87
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented finalisation behaviour and confirming that, when a test Wallet Unit has at least one EAA not yet reissued on the target device: (i) the Wallet Provider does not prevent the Wallet User from selecting the finalisation action; (ii) revocation of the source Wallet Unit proceeds upon the Wallet User's finalisation decision regardless of the EAA reissuance status on the target device. Where feasible, the CAB may also attempt to finalise migration in this state and confirm this behaviour.
10.3 New Device Security Verification
Read section 10.3 in the full text
MIG-10.3-01
The Wallet Provider shall ensure that, before completing Wallet Unit reestablishment on the target device, the target device undergoes the same device security assessment as is required during Wallet Instance installation, including verification that the device meets the minimum hardware and software security requirements defined in the Wallet Provider's security policy and that a WSCD meeting the applicable security certification requirements is available on the target device.
Requirement · obligation: mandatory · PDF page 88
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented migration security criteria and confirming that the migration flow refuses to complete Wallet Unit reestablishment on a target device that fails one or more of the security criteria required during installation - for example, a device with a non-certified WSCD or a device showing indicators of operating system compromise - and that the source Wallet Unit remains active. Where feasible, the CAB may also present such a target device and confirm that re-establishment is refused and the source Wallet Unit remains active.
10.4 Wallet Unit Re-establishment on New Device
Read section 10.4 in the full text
MIG-10.4-01
The Wallet Provider shall issue a new Wallet Instance Attestation and a new Key Attestation for the new device following the same security verification process applied during their initial issuance, including WSCD certification verification and platform attestation.
Requirement · obligation: mandatory · PDF page 89
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented migration flow and confirming that new attestations are issued only after the same verification steps as initial issuance. Where feasible, the CAB may also perform a migration to a test device and confirm that new attestations are issued only after those same verification steps.
MIG-10.4-02
The Wallet Provider shall ensure that device binding on the new device is established using a key pair newly generated within the WSCD of the new device and that no device-bound private key is transferred from the old device to the new device.
Requirement · obligation: mandatory · PDF page 89
How a CAB verifies this: A CAB verifies this requirement by inspecting a migration and confirming that the new device's binding keys were generated on that device and that no device-bound private key was transferred from the old device.
MIG-10.4-03
The Wallet Provider shall require the Wallet User to establish authentication factors on the target device through a procedure that meets the same security requirements as the initial setup of authentication factors during Wallet Unit activation, prior to the migration process being considered complete.
Requirement · obligation: mandatory · PDF page 89
How a CAB verifies this: A CAB verifies this requirement by reviewing the technical specification of the migration flow and confirming that authentication factor setup on the target device is a mandatory, documented step subject to the same security controls as initial activation. The CAB also tests that authentication on the target device uses factors freshly established on that device, and not any credentials transferred from the source device.
10.5 Old Device Decommissioning
Read section 10.5 in the full text
MIG-10.5-01
The Wallet Provider shall point out the dangers to the Wallet User of a valid Wallet Unit that is not under control of the Wallet User and ask the Wallet User if the old Wallet Unit should be revoked.
Requirement · obligation: mandatory · PDF page 90
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented decommissioning flow and confirming that the risk is explained and that the Wallet User is asked whether to revoke the old Wallet Unit. Where feasible, the CAB may also run the decommissioning flow and confirm that the risk is explained and the Wallet User is asked whether to revoke the old Wallet Unit.
MIG-10.5-02
[CONDITIONAL] If the Wallet User has indicated a need for the old Wallet Unit to be revoked and the old Wallet Unit is managed by the same Wallet Provider, the Wallet Provider shall start the process to revoke the old Wallet Unit.
Requirement · obligation: conditional · PDF page 90
How a CAB verifies this: A CAB verifies this requirement by requesting revocation of an old Wallet Unit managed by the same Wallet Provider during decommissioning and confirming that revocation is initiated.
MIG-10.5-03
[CONDITIONAL] If the Wallet User has indicated a need for the old Wallet Unit to be revoked and the old Wallet Unit is not managed by the same Wallet Provider, the Wallet Provider shall give the best possible instructions to the Wallet User what actions the Wallet User should undertake in order to get the old Wallet Unit revoked.
Requirement · obligation: conditional · PDF page 91
How a CAB verifies this: A CAB verifies this requirement by requesting revocation of an old Wallet Unit managed by a different provider and confirming that the Wallet User is given actionable instructions on how to obtain that revocation.
MIG-10.5-04
The Wallet Provider shall ensure that all key material held by the WSCD, all PID credentials and Electronic Attestations of Attributes, and all personal data stored by the Wallet Instance are permanently and irrecoverably deleted from the device before the Wallet Instance uninstallation process completes.
Requirement · obligation: mandatory · PDF page 91
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's uninstallation procedure documentation and confirming that it specifies a defined deletion step for each category of stored data. Where a forensic examination is feasible, the CAB may also perform a guided uninstallation of a test Wallet Unit and conduct a forensic examination of the device storage to confirm that no recoverable credential data, key material, or personal data attributable to the wallet remains after uninstallation.
MIG-10.5-05
[CONDITIONAL] If the Wallet User has indicated a need for the old Wallet Unit to be revoked and the old Wallet Unit is managed by the same Wallet Provider, the Wallet Provider shall ensure that that all cryptographic key material and personal data stored in the old Wallet Unit are irrecoverably deleted from the old device and that the Wallet Instance is uninstalled from the old device the next time when the Wallet Instance connects again with the WSCA.
Requirement · obligation: conditional · PDF page 92
How a CAB verifies this: A CAB verifies this requirement by revoking an old Wallet Unit and confirming that, on the old device's next reconnection, its key material and personal data are deleted and the Wallet Instance is uninstalled.
10.6 Secure Deletion of Keys and Attestations on Old Device
Read section 10.6 in the full text
MIG-10.6-01
The Wallet Provider shall verify that the deletion of all cryptographic key material and personal data from the source Wallet Unit has completed, and shall record the outcome of that verification.
Requirement · obligation: mandatory · PDF page 92
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented deletion-confirmation handling and confirming that the recorded verification outcome is marked unconfirmed when the source device is disconnected during deletion. Where feasible, the CAB may also complete a migration on test devices, inspect the recorded verification outcome, and repeat the migration with the source device disconnected during deletion to confirm that the outcome is recorded as unconfirmed.
Referenced by: MIG-10.6-03
MIG-10.6-02
[CONDITIONAL] Where the deletion of key material and personal data from the source Wallet Unit has not been confirmed within a period defined and documented by the Wallet Provider, the Wallet Provider shall revoke the source Wallet Unit irrespective of that confirmation.
Requirement · obligation: conditional · PDF page 93
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented period and confirming that a source Wallet Unit is revoked once the period has elapsed without the source device being reconnected. Where feasible, the CAB may also complete a migration in which the source device is never reconnected and confirm that the source Wallet Unit is revoked once the period has elapsed.
MIG-10.6-03
[CONDITIONAL] Where the deletion of key material and personal data from the source Wallet Unit has been confirmed under MIG-10.6-01, the Wallet Provider shall revoke the source Wallet Unit if it has not already been revoked.
Requirement · obligation: conditional · PDF page 93
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented decommissioning path in clause 10.5 and confirming that, once deletion on the source device is confirmed, the source Wallet Unit's status changes to revoked without further Wallet User action, and that where the source Wallet Unit was already revoked no conflicting or duplicate revocation attempt is made. Where feasible, the CAB may also complete a migration through the clause 10.5 decommissioning path and confirm this behaviour.
10.7 Recovery to a New Device When the Source Device Is Unavailable
Read section 10.7 in the full text
MIG-10.7-01
[CONDITIONAL] Where the source Wallet Unit is no longer accessible to the Wallet User, the Wallet Provider shall enable the Wallet User to re-establish the Wallet Unit on a new device by restoring a Migration Object, without requiring any participation by the source device.
Requirement · obligation: conditional · PDF page 94
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented recovery flow and confirming that a Wallet Unit can be re-established from a Migration Object with no action by the source device, for instance by inspecting the flow design and, where feasible, by performing a recovery on a new device while the source device is kept offline.
MIG-10.7-02
The Wallet Provider shall require identity proofing at the assurance level applicable to initial PID issuance before any PID credential is re-issued during a recovery performed under this clause.
Requirement · obligation: mandatory · PDF page 94
How a CAB verifies this: A CAB verifies this requirement by reviewing the recovery flow and confirming that PID re-issuance is preceded by identity proofing at the initial-issuance assurance level, for instance by inspecting the flow and proofing records and, where feasible, by attempting a recovery without valid proofing and confirming that no PID is re-issued.
MIG-10.7-03
[CONDITIONAL] Where a recovery under this clause is performed and the source Wallet Unit is managed by the same Wallet Provider, the Wallet Provider shall revoke the source Wallet Unit, treating the Wallet User’s assertion that the source device is no longer under their control as the trigger for that revocation.
Requirement · obligation: conditional · PDF page 94
How a CAB verifies this: A CAB verifies this requirement by reviewing the recovery flow and confirming that completing a recovery revokes a source Wallet Unit managed by the same Wallet Provider without waiting for source-device confirmation, for instance by inspecting the flow and revocation records and, where feasible, by performing a recovery and confirming the source unit’s status becomes revoked.
MIG-10.7-04
[CONDITIONAL] Where a recovery under this clause is performed and the source Wallet Unit is managed by a different Wallet Provider, the Wallet Provider shall give the Wallet User the best possible instructions on the actions the Wallet User should undertake in order to get the source Wallet Unit revoked.
Requirement · obligation: conditional · PDF page 95
How a CAB verifies this: A CAB verifies this requirement by performing a recovery in which the source Wallet Unit is managed by a different provider and confirming that the Wallet User is given actionable instructions on how to obtain that revocation, for instance by inspecting the recovery flow and the guidance presented to the Wallet User.
MIG-10.7-05
The Wallet Provider shall apply to the re-establishment of the Wallet Unit on the new device under this clause the same new device security verification and reestablishment controls that apply to a migration, as set out in clauses 10.3 and 10.4.
Requirement · obligation: mandatory · PDF page 95
How a CAB verifies this: A CAB verifies this requirement by reviewing the recovery flow and confirming that the new device security verification and the re-establishment controls of clauses 10.3 and 10.4 are applied before a Wallet Unit is re-established through recovery, for instance by inspecting the recovery flow design and, where feasible, by attempting a recovery onto a device that fails the security verification and confirming that re-establishment does not complete.
11.1 Wallet User-Initiated Uninstallation
Read section 11.1 in the full text
UNINST-11.1-01
The Wallet Provider shall ensure that the Wallet Unit requires an explicit confirmation step from the Wallet User before proceeding with uninstallation and presents the Wallet User with a clear statement of the consequences of uninstallation, including the irreversible loss of all key bound credentials stored in the Wallet Unit.
Requirement · obligation: mandatory · PDF page 97
How a CAB verifies this: A CAB verifies this requirement by starting uninstallation on a test Wallet Unit and confirming that a consequence statement and an explicit confirmation step are presented before it proceeds.
UNINST-11.1-02
The Wallet Provider shall, prior to completing the Wallet Instance uninstallation process, inform the Wallet User that all PID credentials, attestations and transaction logs stored in the Wallet Unit will be permanently deleted and are not recoverable after uninstallation, and shall require explicit Wallet User confirmation before proceeding.
Requirement · obligation: mandatory · PDF page 97
How a CAB verifies this: A CAB verifies this requirement by reviewing the uninstallation flow and confirming that a data loss warning with an explicit confirmation step is present, and that cancellation of the confirmation halts the uninstallation process without deleting any credentials.
UNINST-11.1-03
The Wallet Provider shall ensure that, prior to completing the Wallet Instance uninstallation process, an updated Migration Object is available in the storage location selected by the Wallet User, that the Wallet User confirms to still have access to that location and verify that the Wallet User still has knowledge of the Migration Object.
Requirement · obligation: mandatory · PDF page 98
How a CAB verifies this: A CAB verifies this requirement by running uninstallation with each check satisfied and confirming completion, and by removing access to the stored object and confirming the check detects it.
Referenced by: UNINST-11.1-04
UNINST-11.1-04
[CONDITIONAL] If one of the checks in UNINST-11.1-03 is not met, the Wallet Provider shall ensure that Wallet Unit uninstallation only proceeds after renewed confirmation by the Wallet User.
Requirement · obligation: conditional · PDF page 98
How a CAB verifies this: A CAB verifies this requirement by forcing one of the recovery checks to fail and confirming that uninstallation halts until the Wallet User provides a renewed confirmation.
11.2 Pre-Uninstallation Security Measures
Read section 11.2 in the full text
UNINST-11.2-01
The Wallet Provider shall ensure that all active sessions and pending transactions within the Wallet Unit are terminated before the uninstallation process begins.
Requirement · obligation: mandatory · PDF page 98
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented uninstallation behaviour and confirming that an active session or transaction is terminated before deletion
UNINST-11.2-02
The Wallet Provider shall ensure that the Wallet Provider backend is notified of the uninstallation event before or upon completion of the uninstallation process, enabling the Wallet Provider to initiate appropriate deregistration or revocation actions.
Requirement · obligation: mandatory · PDF page 99
How a CAB verifies this: A CAB verifies this requirement by uninstalling a test Wallet Unit and confirming that the backend receives the uninstallation notification and can act on it.
11.3 Data Cleanup and Deletion
Read section 11.3 in the full text
UNINST-11.3-01
The Wallet Provider shall ensure that all private keys associated with the Wallet Unit, including keys attested in a Key Attestation, credential-binding keys, and Wallet User authentication keys, are irrecoverably deleted from the WSCD and from all application storage locations during uninstallation.
Requirement · obligation: mandatory · PDF page 99
How a CAB verifies this: A CAB verifies this requirement by uninstalling a test Wallet Unit and confirming, by inspection of the device, that no associated private key material remains recoverable.
UNINST-11.3-02
The Wallet Provider shall ensure that all PID credentials and attestations stored in the Wallet Unit are irrecoverably deleted during uninstallation.
Requirement · obligation: mandatory · PDF page 99
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented deletion steps of the uninstallation procedure and the storage locations they cover for held credentials,
UNINST-11.3-03
The Wallet Provider shall ensure that all cached data, temporary files, session tokens, and application state related to Wallet Unit operations are irrecoverably deleted during uninstallation.
Requirement · obligation: mandatory · PDF page 100
How a CAB verifies this: A CAB verifies this requirement by uninstalling a test Wallet Unit and confirming that cached data, temporary files, session tokens, and application state have been removed.
UNINST-11.3-04
The Wallet Provider shall ensure that the WSCA and WSCD are cleared of all key material, configuration data, and application-specific data stored within them as part of the uninstallation process.
Requirement · obligation: mandatory · PDF page 100
How a CAB verifies this: A CAB verifies this requirement by uninstalling a test Wallet Unit and confirming that the secure cryptographic application and device no longer hold any Wallet-Unit key material, configuration, or data.
UNINST-11.3-05
The Wallet Provider shall ensure that, upon Wallet Instance uninstallation, all operational records and transaction logs associated with the uninstalled Wallet Unit that are held in the Wallet Provider's backend systems are either deleted or anonymised in accordance with the applicable data protection requirements, except where those records are required to be retained under a legal obligation, in which case the retained records shall be limited to what is strictly necessary, retained only for the minimum required period, and access-controlled to prevent use for any purpose other than compliance with that obligation.
Requirement · obligation: mandatory · PDF page 100
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented data management policy and confirming that it includes procedures for handling transaction logs and operational records upon uninstallation, with enumerated record categories, documented legal bases, defined retention periods, and deletion mechanisms. The CAB may additionally verify the policy's implementation by reviewing records relating to previously uninstalled test Wallet Units and confirming deletion or anonymisation in accordance with the stated policy.
11.4 Revocation and Deregistration
Read section 11.4 in the full text
UNINST-11.4-01
The Wallet Provider shall revoke the Wallet Instance Attestation and the Key Attestation associated with a Wallet Unit at the time of Wallet Instance uninstallation regardless of whether the Wallet User intends to install the Wallet Instance again on the same or a different device.
Requirement · obligation: mandatory · PDF page 101
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documentation to confirm that the maximum revocation publication delay is defined and monitored, and by checking the Wallet Unit Attestation status list to confirm that a WUA revocation is published within the defined maximum delay. Where feasible, the CAB may also uninstall the Wallet Instance from a test device and attempt to make a presentation using key material from the uninstalled Wallet Unit, confirming that the WUA is rejected as revoked by the status check.
11.5 Verification of Complete Removal
Read section 11.5 in the full text
UNINST-11.5-01
The Wallet Provider shall provide the Wallet User with confirmation that the uninstallation process has completed, including confirmation that the Wallet Unit has been deregistered with the Wallet Provider and has been revoked.
Requirement · obligation: mandatory · PDF page 102
How a CAB verifies this: A CAB verifies this requirement by completing uninstallation and confirming that the Wallet User is shown confirmation covering deregistration and revocation.
UNINST-11.5-02
The Wallet Provider shall ensure that the uninstallation process results in no recoverable Wallet Unit data remaining on the device, including private keys, credentials, cached data, and application configuration files.
Requirement · obligation: mandatory · PDF page 102
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented deletion steps of the uninstallation procedure and the Wallet Unit data they cover, confirming that no recoverable Wallet Unit data remains. Where a forensic examination is feasible, the CAB may also inspect the device after uninstallation to confirm that no recoverable Wallet Unit data remains.
12.1 Revocation Triggers and Conditions
Read section 12.1 in the full text
REV-12.1-01
The Wallet Provider shall implement mechanisms to detect security breaches affecting Wallet Units, including monitoring for indicators of device compromise, and shall initiate revocation procedures upon confirmed detection of a breach affecting a Wallet Unit.
Requirement · obligation: mandatory · PDF page 103
How a CAB verifies this: A CAB verifies this requirement by reviewing the detection mechanisms and confirming that a confirmed breach affecting a test Wallet Unit triggers revocation.
REV-12.1-02
The Wallet Provider shall revoke a Wallet Unit when required to do so by applicable law or by a competent supervisory authority, within the timeframes mandated by the applicable legal requirement.
Requirement · obligation: mandatory · PDF page 103
How a CAB verifies this: A CAB verifies this requirement by reviewing the process for handling legally mandated revocations and confirming that it provides for action within the applicable statutory timeframes.
REV-12.1-03
The Wallet Provider shall establish and maintain a documented procedure for accepting and processing requests for permanent revocation of a Wallet Unit submitted by an authorised party other than the Wallet Unit holder, including requests submitted in consequence of the death or legal incapacity of the natural person to whom the Wallet Unit is issued, and shall provide a mechanism that enables such requests to be submitted and verified without requiring participation of the Wallet Unit holder.
Requirement · obligation: mandatory · PDF page 103
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented procedure for third-party revocation requests and confirming that: (i) the procedure exists and covers the death and legal incapacity scenarios; (ii) it specifies acceptable verification instruments; (iii) it does not require participation by the Wallet Unit holder. The CAB may additionally submit a simulated third-party revocation request with appropriate documentation and verify that the request is processed and the Wallet Unit is revoked.
Referenced by: REV-12.1-08
REV-12.1-04
The Wallet Provider shall establish processes for Wallet Users or other competent parties to notify suspected device compromise.
Requirement · obligation: mandatory · PDF page 104
How a CAB verifies this: A CAB verifies this requirement by confirming that documented reporting routes exist for Wallet Users and other competent parties and that a submitted report reaches the Wallet Provider's revocation process.
REV-12.1-05
The Wallet Provider shall revoke a Wallet Unit for which credible evidence of fraudulent use or sufficient indication of suspected compromise has been identified and shall record the basis and supporting evidence for the revocation decision.
Requirement · obligation: mandatory · PDF page 104
How a CAB verifies this: A CAB verifies this requirement by reviewing revocation records and confirming that revocations on grounds of fraud or suspected compromise are supported by a recorded basis and evidence.
REV-12.1-06
The Wallet Provider shall ensure that a Wallet User can initiate revocation of their own Wallet Unit through a means that does not depend on access to the Wallet Unit’s device, on authentication factors or credentials that are typically kept or carried together with that device, or on any secret or credential that the Wallet User would typically only store in a fixed location such as their home.
Requirement · obligation: mandatory · PDF page 105
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet User-initiated revocation design and confirming that at least one route does not depend on the device, on credentials typically lost with it, or on a secret the Wallet User would keep only at a fixed location such as home, for instance by inspecting the design and, where feasible, by initiating revocation from a different device, and from a different location, without the original authentication means.
REV-12.1-07
The Wallet Provider shall, after authenticating the PID Provider as the sender, revoke a Wallet Unit when the PID Provider forwards a request for revocation of that Wallet Unit on behalf of the person in whose name a PID was issued to it.
Requirement · obligation: mandatory · PDF page 105
How a CAB verifies this: A CAB verifies this requirement by reviewing the interface and its authentication and by examining records of requests received and the revocations that followed.
REV-12.1-08
The Wallet Provider shall treat a notice from the PID Provider of the decease of a Wallet Holder as a request under REV-12.1-03 for permanent revocation of the Wallet Unit to which the notice relates.
Requirement · obligation: mandatory · PDF page 105
How a CAB verifies this: A CAB verifies this requirement by reviewing the procedure and by examining records of past notices.
12.2 Revocation Procedures
Read section 12.2 in the full text
REV-12.2-01
The Wallet Provider shall ensure that revocation requests submitted by parties other than the Wallet User are subject to verification of the authority of the requesting party to trigger revocation before the request is acted upon.
Requirement · obligation: mandatory · PDF page 106
How a CAB verifies this: A CAB verifies this requirement by submitting third-party revocation requests with and without demonstrated authority and confirming that only the authorised request is acted upon.
REV-12.2-02
The Wallet Provider shall ensure that a revoked Wallet Unit is disabled within a defined maximum timeframe following the revocation decision.
Requirement · obligation: mandatory · PDF page 106
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented revocation mechanism and confirming that a triggered revocation disables the Wallet Unit within the defined maximum timeframe, corroborating this against revocation records. Where feasible, the CAB may also trigger a revocation and confirm that the Wallet Unit is disabled within the defined maximum timeframe.
REV-12.2-03
The Wallet Provider shall document and enforce that maximum permissible delay between the revocation decision and the effective disabling of the Wallet Unit.
Requirement · obligation: mandatory · PDF page 107
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented maximum delay and confirming, against revocation records, that the effective disabling times observed fall within it.
REV-12.2-04
The Wallet Provider shall ensure that, upon revocation of a Wallet Unit, the revocation status of the associated Wallet Instance Attestation and Key Attestation is published to the applicable revocation status mechanism without undue delay, enabling parties interacting with the Wallet Unit to detect the revocation prior to accepting transactions with the revoked Wallet Unit.
Requirement · obligation: mandatory · PDF page 107
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented maximum publishing delay and corroborating, against revocation records, that revocation status becomes observable through the applicable status mechanism within that delay. Where feasible, the CAB may also revoke a Wallet Unit and measure the time until the revocation status is observable, confirming it falls within the documented maximum publishing delay.
REV-12.2-05
The Wallet Provider shall ensure that the Wallet Instance ceases to display the European Digital Identity Wallet Trust Mark referred to in [13] from the moment the Wallet Instance Attestation of that Wallet Unit is revoked.
Requirement · obligation: mandatory · PDF page 107
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented Trust Mark behaviour and confirming that the Trust Mark is no longer displayed once a Wallet Unit is revoked. Where feasible, the CAB may also revoke a test Wallet Unit and confirm, on the device, that the Trust Mark is no longer displayed.
REV-12.2-06
The Wallet Provider shall ensure that revocation of a Wallet Unit is permanent and irreversible, and shall not provide any mechanism, interface, process, or administrative function through which a permanently revoked Wallet Unit can be restored to an active or operational state.
Requirement · obligation: mandatory · PDF page 108
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's system documentation and confirming the absence of any functionality that permits reversal of permanent revocation. The CAB also attempts to re-activate a test Wallet Unit that has been permanently revoked and confirms that no pathway — including administrative or technical — allows this. The CAB additionally reviews the Wallet Provider's access control documentation to confirm that no personnel role has the capability to reverse a permanent revocation.
REV-12.2-07
The Wallet Provider shall ensure that the Wallet Instance Attestation issued to each Wallet Unit contains a reference to the revocation status mechanism maintained by the Wallet Provider, enabling relying parties and PID Providers to determine the current revocation status of the Wallet Unit at the time of any transaction.
Requirement · obligation: mandatory · PDF page 109
How a CAB verifies this: A CAB verifies this requirement by inspecting the WUA of a test Wallet Unit and confirming the presence of a revocation status mechanism reference. The CAB then uses that reference to query the revocation status of the Wallet Unit and confirms that the response correctly reflects the Wallet Unit's current status, including after the test Wallet Unit has been permanently revoked. The CAB also confirms that the revocation status endpoint is publicly accessible without requiring authentication.
REV-12.2-08
The Wallet Provider shall, whenever it revokes the Wallet Instance Attestation of a Wallet Unit — on revocation of the Wallet Unit under this clause, on uninstallation of the Wallet Instance, or on revocation of a source Wallet Unit during migration — set to revoked the revocation status of every Wallet Instance Attestation it has issued to that Wallet Unit, including any such attestation whose technical validity period has expired but whose revocation status the Wallet Provider still maintains, so that the revocation status reference recorded by a PID Provider or Attestation Provider at issuance reflects the revocation throughout the lifetime of the PID or attestation issued against it.
Requirement · obligation: mandatory · PDF page 109
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented revocation procedure and confirming that a single revocation action sets to revoked the status of every Wallet Instance Attestation issued to the Wallet Unit, including those past their technical validity period whose status is still maintained, and by inspecting revocation records for a revoked Wallet Unit to confirm that the status list entries of its earlier, expired Wallet Instance Attestations were also set. Where feasible, the CAB may issue to a test Wallet Unit more than one Wallet Instance Attestation, allow the earlier attestation to expire, revoke the Wallet Unit, and confirm that both the expired and the current entries reflect revocation within the maximum publication delay documented under REV-12.3-01.
12.3 Impact on PIDs and Attestations
Read section 12.3 in the full text
REV-12.3-01
The Wallet Provider shall ensure that the revocation status of the Wallet Instance Attestation and of the Key Attestation is published to the applicable attestation status list within a defined and documented maximum time period following the triggering event for revocation, and shall make that attestation status list available in a format and at a location that enables PID Providers and Attestation Providers to query the revocation status of any such attestation without requiring authenticated access to the status service.
Requirement · obligation: mandatory · PDF page 110
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented maximum revocation publication delay for each trigger type and confirming, against revocation records, that the updated revocation status is published on the status list within that delay and that the status list is accessible without authentication. Where feasible, the CAB may also trigger a test revocation, measure the time between the trigger event and publication of the updated status, and attempt to access the status list without authentication, confirming that the query succeeds and returns the correct status for the revoked Wallet Unit Attestation.
Referenced by: REV-12.2-08
REV-12.3-02
[CONDITIONAL] Where the Wallet Instance Attestation or the Key Attestation is issued in the mobile document format specified in [11], the Wallet Provider shall publish its revocation status by means of an attestation status list or an attestation revocation list as specified in [12].
Requirement · obligation: conditional · PDF page 111
How a CAB verifies this: A CAB verifies this requirement by determining the format of the attestations issued in production, retrieving the published status information, and confirming that its representation is the one specified for that format.
REV-12.3-03
[CONDITIONAL] Where the Wallet Instance Attestation or the Key Attestation is issued in the selectively disclosable JSON Web Token verifiable credential format, the Wallet Provider shall publish its revocation status by means of an attestation status list as specified in [10].
Requirement · obligation: conditional · PDF page 111
How a CAB verifies this: A CAB verifies this requirement by retrieving the status information referenced by an attestation issued in this format and confirming that it is a status list in the specified representation.
12.4 Data Deletion Requirements
Read section 12.4 in the full text
REV-12.4-01
The Wallet Provider shall ensure that all private keys stored in the remote WSCD that are associated with a revoked Wallet Unit are irrecoverably deleted and that the revocation event is recorded in a tamper-evident audit log.
Requirement · obligation: mandatory · PDF page 112
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented server-side key handling and confirming that revocation of a Wallet Unit whose keys are held server-side deletes those keys and that a tamper-evident log entry records the revocation. Where feasible, the CAB may also revoke a test Wallet Unit whose keys are held server-side and confirm that those keys are deleted and that a tamper-evident log entry records the revocation.
REV-12.4-02
The Wallet Provider shall ensure that, following permanent revocation of a Wallet Unit, all personal data associated with the revoked Wallet Unit that is held in the Wallet Provider's backend systems is deleted or anonymised in accordance with the applicable data protection requirements, except where those records are required to be retained under a legal obligation, in which case the retained data shall be limited to what is strictly necessary, retained only for the minimum required period, and access-controlled to prevent use for any purpose other than compliance with that obligation.
Requirement · obligation: mandatory · PDF page 112
How a CAB verifies this: A CAB verifies this requirement by reviewing the Wallet Provider's documented data retention policy for the post-revocation period and confirming that: (i) categories of retained data are enumerated with a documented legal basis and defined retention period for each; (ii) deletion or anonymisation is triggered at the end of the retention period; (iii) access to retained data is restricted to the specific compliance purpose. The CAB may additionally review records relating to previously revoked test Wallet Units to confirm that retention and deletion are applied in accordance with the documented policy.
REV-12.4-03
The Wallet Provider shall retain audit logs related to Wallet Unit revocation for a period sufficient to support legal proceedings, supervisory audit, and incident investigation, and shall ensure that the retention period does not exceed the maximum period permitted under applicable data protection law.
Requirement · obligation: mandatory · PDF page 113
How a CAB verifies this: A CAB verifies this requirement by reviewing the retention policy for revocation logs and confirming that the period is sufficient for the stated purposes and does not exceed the maximum permitted by applicable data protection law.
13.1 General Monitoring and Fraud Detection
Read section 13.1 in the full text
MON-13.1-01
The Wallet Provider shall operate a monitoring capability that detects, across every lifecycle state of a Wallet Unit, patterns indicative of compromise or fraudulent use in the backend interactions it receives from that Wallet Unit, including a frequency of those interactions inconsistent with normal operation and a device or Wallet Secure Cryptographic Device profile presented in an interaction that is inconsistent with the profile recorded for that Wallet Unit at activation or at a subsequent re-attestation.
Requirement · obligation: mandatory · PDF page 114
How a CAB verifies this: A CAB verifies this requirement by reviewing the monitoring design and the backend interactions it consumes, and by reproducing each listed condition — an abnormal interaction frequency and a mismatched device profile — against a test Wallet Unit and confirming that the monitoring capability records it.
Referenced by: MON-13.1-02, MON-13.2-01, MON-13.2-02
MON-13.1-02
The Wallet Provider shall document, for each anomaly condition detected under MON-13.1-01, the investigation procedure applied and the response available, up to and including revocation of the Wallet Unit.
Requirement · obligation: mandatory · PDF page 114
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented conditions and responses, and by sampling recorded anomalies to confirm that the response actually applied was the documented one.
MON-13.1-03
The Wallet Provider shall provide the Wallet User with a means of reporting suspected compromise or misuse of a Wallet Unit that does not require the Wallet User to authenticate to that Wallet Unit.
Requirement · obligation: mandatory · PDF page 115
How a CAB verifies this: A CAB verifies this requirement by locating the reporting channel as a Wallet User would, submitting a test report without authenticating to the Wallet Unit, and confirming that the report reaches the monitoring or support function.
13.2 State-Specific Monitoring Inputs
Read section 13.2 in the full text
MON-13.2-01
[CONDITIONAL] For a Wallet Unit that holds no PID credential, the Wallet Provider shall base the monitoring required under MON-13.1-01 on the Wallet Instance Attestation and Key Attestation status queries, the software update check-ins, and the reports of suspected compromise that it receives from the Wallet Unit at that stage.
Requirement · obligation: conditional · PDF page 115
How a CAB verifies this: A CAB verifies this requirement by reproducing each listed condition — an abnormal query frequency and a mismatched device profile — against a test Wallet Unit that holds no PID credential and confirming that the monitoring capability records it.
MON-13.2-02
[CONDITIONAL] For a Wallet Unit that holds a PID credential, the Wallet Provider shall extend the monitoring required under MON-13.1-01 to the trust anchor distribution channel, the software update check-ins, and any migration-initiation request it receives from the Wallet Unit.
Requirement · obligation: conditional · PDF page 116
How a CAB verifies this: A CAB verifies this requirement by reproducing an anomalous condition — an abnormal trust anchor distribution or migration-initiation pattern — on a test Wallet Unit that holds a PID credential and confirming that the monitoring capability records it.
13.3 Monitoring of the Application and Web Ecosystem
Read section 13.3 in the full text
MON-13.3-01
The Wallet Provider shall monitor the application distribution channels through which the Wallet Instance is made available for counterfeit, modified, or look-alike applications that impersonate the Wallet Instance.
Requirement · obligation: mandatory · PDF page 116
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented monitoring process and its coverage of the distribution channels through which the Wallet Instance is offered, and by reviewing records of counterfeit applications identified over a representative period.
Referenced by: MON-13.3-02
MON-13.3-02
The Wallet Provider shall, upon identifying a counterfeit, modified, or lookalike application that impersonates the Wallet Instance, pursue its removal from the application distribution channel on which it is offered.
Requirement · obligation: mandatory · PDF page 117
How a CAB verifies this: A CAB verifies this requirement by reviewing records of counterfeit applications identified under MON-13.3-01 and confirming that a removal request was raised for each and pursued to a recorded outcome.
MON-13.3-03 — The Wallet Provider shall monitor for websites that impersonate the Wallet Provider in order to deceive Wallet Users.
The Wallet Provider shall monitor for websites that impersonate the Wallet Provider in order to deceive Wallet Users.
Requirement · obligation: mandatory · PDF page 117
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented monitoring process and reviewing records of impersonation websites identified over a representative period.
Referenced by: MON-13.3-04
MON-13.3-04
The Wallet Provider shall, upon identifying a website that impersonates the Wallet Provider or the Wallet Instance, pursue its takedown.
Requirement · obligation: mandatory · PDF page 117
How a CAB verifies this: A CAB verifies this requirement by reviewing records of impersonation websites identified under MON-13.3-03 and confirming that a takedown request was raised for each and pursued to a recorded outcome.
13.4 Wallet User Warning Channel
Read section 13.4 in the full text
MON-13.4-01
The Wallet Provider shall maintain a means of contacting the Wallet User over a push channel that the Wallet User will see without opening the Wallet Instance and that is independent of the Wallet Instance, for use in warning the Wallet User when compromise of the Wallet Unit is suspected.
Requirement · obligation: mandatory · PDF page 118
How a CAB verifies this: A CAB verifies this requirement by reviewing the documented contact channel and confirming it is independent of the Wallet Instance and that it actively pushes a warning rather than waiting to be read, so that a suspected compromise warning reaches the Wallet User without the Wallet Instance being opened and without the Wallet User having to open a portal or inbox to find it. Where feasible, the CAB may also trigger a test suspected-compromise warning and confirm that it reaches the Wallet User in this way.