Commission Implementing Regulation (EU) 2024/2981 of 28 November 2024 laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and the Council as regards the certification of European Digital Identity Wallets

TT1. Physical attacks
1.1   Theft Theft is defined as the theft of devices that may alter the wallet’s proper functioning (in case the device is stolen and the wallet unit is not adequately protected). This may contribute to many risks, including Identity theft (R4), Data theft (R5), and Unauthorised transactions (R9).
1.2   Information leakage Information leakage is defined as unauthorised access, information exposure, or sharing after physical access to the wallet. This may contribute in particular to Data Disclosure (R6) and Data theft (R5).
1.3   Tampering Tampering is defined as violating the integrity of one or multiple components of the wallet unit, or of the components the wallet unit relies on, e.g., the user device or its operating system. This may contribute in particular to Data manipulation (R7), Data loss (R8) and Transaction manipulation (R10). When tampering targets software components, it may contribute to many risks.
TT2. Errors and misconfigurations
2.1   Errors made when managing an IT system Errors made when managing an IT system are defined as information leakage, sharing or damage caused by misuse of IT assets by users (lack of awareness of application features) or by improper configuration or management of IT assets.
2.2   Application-level errors or usage errors Application-level errors or usage errors are defined as dysfunctions of the application due to an error in the application itself or to an error by one of the users (wallet users and relying parties).
2.3   Development-time errors and system misconfigurations Development-time errors and system misconfigurations are defined as dysfunction or vulnerabilities caused by improperly developed or configured IT assets or business processes (inadequate specifications of IT products, inadequate usability, insecure interfaces, improper policy and procedure flows, design errors).
TT3. Use of unreliable resources
The use of unreliable resources is defined as an activity leading to unintentional damage due to ill-defined trust relationships, such as trusting a third-party provider without sufficient assurance.
3.1   Erroneous use or configuration of wallet components An erroneous use or configuration of wallet components is defined as unintentional damage to wallet components due to an erroneous use or misconfiguration by wallet users or by insufficiently trained developers, or due to lack of adaptation to changes in the threat landscape, typically the use of vulnerable third-party components or runtime platforms.
TT4. Failure and outages
4.1   Failure or dysfunction of equipment, devices or systems A failure or dysfunction of equipment is defined as unintentional damage to IT assets due to a failure or dysfunction of equipment, including the provider’s infrastructure and the user devices.
4.2   Loss of resources The loss of resources is defined as an outage or dysfunction due to unavailability of such resources, e.g., as maintenance parts.
4.3   Loss of support services The loss of support services is defined as an outage or dysfunction due to unavailability of support services required for proper operation of the system, including network connectivity of the provider’s infrastructure and of the user device.
TT5. Malicious actions
5.1   Interception of information The interception of information is defined as the capture of information improperly secured in transmission, including man-in-the-middle attacks.
5.2   Phishing and spoofing Phishing is defined as the capture of information provided by the user following a deceptive interaction, often associate to the spoofing of legitimate communication means and websites. These threats target the user and typically contribute to Identity theft (R4) and Unauthorised transactions (R9), often through Data theft (R5) or Data disclosure (R6).
5.3   Replay of messages Replay of messages is defined as the reuse of previously intercepted messages to perform unauthorised transactions, often at protocol level. This technical threat mainly contributes to unauthorised transactions, which may then lead to other risks, depending on the transaction.
5.4   Brute-force attack Brute-force attack is defined as a breach of security, often confidentiality, by performing a large number of interactions until the responses provide valuable information.
5.5   Software vulnerabilities The threat related to software vulnerabilities is a breach of security through exploitation of a software vulnerability in the components of the wallet or in the software and hardware components used in the implementation of the wallet, including published vulnerabilities and unpublished (0-day) vulnerabilities.
5.6   Supply chain attacks A supply chain attack is defined as a breach of security through attacks perpetrated on the supplier of the wallet provider or of its users to enable further attacks on the wallet itself.
5.7   Malware Malware is defined as a breach of security through malicious applications performing unwanted and illegitimate actions on the wallet.
5.8   Random number prediction Random number prediction is defined as the enablement of brute-force attacks through partial or complete prediction of generated random numbers.

SECTION IV

Threats to the wallets

This last section presents a selection of typical threat scenarios specific to the wallets, which are mapped to the key related high-level risks, as listed above. This list indicates threats that need to be covered, but it does not constitute an exhaustive list of threats, which depends greatly on the architecture of the selected wallet solution and on the evolution of the threat environment. Additionally, in the risk assessment and proposed measures, the wallet provider can only be responsible for those components in scope of certification (*).

ID Identifier	Threat description Description of the identified threat (*)	Risk title Related risks
TR1	An attacker can revoke pseudonyms without justified reason.	Creation or use of a fake electronic identity (R2)
TR2	An attacker can issue fabricated electronic identities that do not exist.	Creation or use of a fake electronic identity (R2)
TR3	An attacker can start to issue unauthorised PIDs.	Creation or use of a fake electronic identity (R2)
TR4	An attacker can get an administrator to enter a wrong PID provider into the PID provider trusted list.	Creation or use of a fake electronic identity (R2)
TR5	An attacker can bypass the remote identity proofing service.	Creation or use of an existing electronic identity (R1) / Creation or use of a fake electronic identity (R2)
TR6	An attacker can bypass the physical identity proofing service.	Creation or use of an existing electronic identity (R1) / Creation or use of a fake electronic identity (R2)
TR7	An attacker can bypass the identity proofing services related to the use of a remote (qualified) certificate.	Creation or use of an existing electronic identity (R1) / Creation or use of a fake electronic identity (R2)
TR8	An attacker can get access to a wallet that is not bound to a person.	Creation or use of an existing electronic identity (R1) / Creation or use of a fake electronic identity (R2)
TR9	An attacker can defeat technical and procedural controls to create wrong PIDs.	Creation or use of an existing electronic identity (R1) / Creation or use of a fake electronic identity (R2)
TR10	An attacker can activate a new wallet on an invalid WSCD.	Creation or use of an existing electronic identity (R1) / Creation or use of a fake electronic identity (R2)
TR11	An attacker can bypass the identity proofing service related to the use of existing eID means.	Creation or use of an existing electronic identity (R1) / Identify theft (R4) / Unauthorised transaction (R9)
TR12	An attacker can circumvent the verification by the PID provider that the wallet is controlled by the user and have a PID issued into a compromised wallet under the attacker’s control.	Creation or use of an existing electronic identity (R1) / Identify theft (R4) / Unauthorised transaction (R9)
TR13	An attacker can get a valid PID into an invalid wallet unit.	Creation or use of an existing electronic identity (R1) / Identify theft (R4) / Unauthorised transaction (R9)
TR14	A PID provider can issue fabricated identities where the identity is related to an existing person.	Creation or use of an existing electronic identity (R1) / Identity theft (R4) / Unauthorised transaction (R9)
TR15	An attacker can link a PID with the wrong wallet because the PID provider is not able to link the PID to the correct wallet.	Creation or use of an existing electronic identity (R1) / Identify theft (R4) / Unauthorised transaction (R9)
TR16	An attacker can make the user approving the activation of a new wallet unit/instance under the attacker’s control – with subsequent control of attestations as well.	Creation or use of an existing electronic identity (R1) / Creation or use of a fake electronic identity (R2) / Identify theft (R4) / Unauthorised transaction (R9)
TR17	An attacker can issue a PID of another state to access data / digital assets of targeted citizens.	Creation or use of an existing electronic identity (R1) / Identity theft (R4) / Unauthorised transaction (R9)
TR18	An attacker can defeat technical and procedural controls to create fake (Q)EAAs.	Creation or use of fake attributes (R3)
TR19	An attacker can present (Q)EAAs that are not validly issued to them.	Creation or use of fake attributes (R3)
TR20	An attacker can attack the cryptographic linking mechanism of the wallet between the PID and a (Q)EAA that should not be issued to them.	Creation or use of fake attributes (R3)
TR21	An attacker can use a (Q)EAA in a wallet, although the physical counterpart of the (Q)EAA is expired or invalid.	Creation or use of fake attributes (R3)
TR22	An attacker can circumvent the verification by the (Q)EAA provider that the wallet is in control of the user and have a (Q)EAA issued into a compromised wallet under the attacker’s control.	Creation or use of fake attributes (R3)
TR23	An attacker can forge electronic attestations of attributes.	Creation or use of fake attributes (R3)
TR24	An attacker can inject forged electronic attestations of attributes into a wallet.	Creation or use of fake attributes (R3)
TR25	The wallet can present attributes to a relying party without the approval of a user.	Data disclosure (R6)
TR26	PID, (Q)EAAs or pseudonyms can be presented to a wrong relying party.	Data disclosure (R6)
TR27	An attacker can initiate a malicious renewal of EAA.	Data disclosure (R6)
TR28	An attacker can get a user into wrongfully approving a request for electronic attestations of attributes (phishing or other).	Data disclosure (R6)
TR29	An attacker can leak attributes from the wallet and identify the wallet user where identification is not required/allowed.	Data disclosure (R6)
TR30	An attacker can defeat technical and procedural controls to extract data.	Data disclosure (R6)
TR31	A request can be leaked to an attacker.	Data disclosure (R6)
TR32	An attacker can obtain knowledge on the embedded disclosure policy for attributes and present attributes contained in the current request by wallet units.	Data disclosure (R6)
TR33	An attacker can extract logs, or parts of them.	Data disclosure (R6)
TR34	An attacker can know whether a wallet is installed on the same device he is using, or on another one, and get information on it.	Data disclosure (R6)
TR35	An attacker can obtain a knowledge factor used for user authenticating to the WSCA.	Data disclosure (R6)
TR36	The electronic attestation of attributes about a person that is presented in multiple transactions with a relying party, or across different relying parties, unintentionally allows to link multiple transactions to the relevant person.	Data disclosure (R6)
TR37	A public attestation/relying party revocation list can contain information about the user’s usage of their attestation (e.g. location, IP address …).	Data disclosure (R6)
TR38	Not being able to prove user’s consent for shared attributes, relying parties can affect the integrity of logs.	Data disclosure (R6)
TR39	An attacker can unlawfully trace wallet users using unique/traceable identifiers.	Data disclosure (R6) / Surveillance (R14)
TR40	A relying party that consists of multiple units/entities that each have a different scope of what they are allowed to request/process, can request and process data for which they do not have lawful grounds for.	Data disclosure (R6) / Unauthorised transaction (R9)
TR41	An attacker can subvert the integrity and authenticity checks by the wallet of PIDs to always return success.	Data manipulation (R7)
TR42	An attacker can bypass or subvert the performance of checks by the wallet that verify the integrity and authenticity of requested attributes to always return success.	Data manipulation (R7)
TR43	An attacker can bypass or subvert the performance of checks by the wallet that verify all requested attributes belonging to the same user to always return success.	Data manipulation (R7)
TR44	An attacker can bypass or subvert the performance of checks by the wallet that verify the PID is valid and issued by a trusted PID provider to always return success.	Data manipulation (R7)
TR45	An attacker can bypass or subvert the performance of checks by the wallet that verify that a QEAA is valid and issued by a qualified TSP, who is registered to issue the QEAA, to always return success.	Data manipulation (R7)
TR46	An attacker can bypass or subvert the performance of checks by the wallet that verify whether the PID has been revoked by the PID provider to always return success.	Data manipulation (R7)
TR47	An attacker can bypass or subvert the performance of checks by the wallet that verify whether the (Q)EAA has been revoked by the (Q)EAA provider to always return success.	Data manipulation (R7)
TR48	An attacker can modify the content of backup and recovery data that should be exclusively under the user’s control.	Data manipulation (R7) / Data loss (R8)
TR49	An attacker can modify the transaction history for a given wallet instance from the activity logs.	Data manipulation (R7) / Data loss (R8)
TR50	An attacker can eavesdrop during the connection from the wallet to relying parties.	Data theft (R5) / Data disclosure (R6)
TR51	An attacker can convince a user to share personal data (i.e. PID, EAA-s, pseudonyms, electronic signatures, logs and other data) with the attacker or with a third party that the user did not intend to do so.	Data theft (R5) / Data disclosure (R6)
TR52	An attacker can read the transaction history for a given wallet instance from the activity logs.	Data theft (R5) / Data disclosure (R6)
TR53	An attacker can export or extract cryptographic key material outside of the WSCD.	Data theft (R5) / Data disclosure (R6) / Unauthorised transaction (R9)
TR54	An attacker can read the content of backup and recovery data that should be exclusively under the user’s control.	Data theft (R5) / Data disclosure (R6)
TR55	An attacker can bypass the user authentication method to use a pseudonym generated by a wallet unit.	Identity theft (R4)
TR56	An attacker can propose an application that mimics a specific legitimate wallet to users.	Identity theft (R4)
TR57	An attacker can export wallet data, including PID, (Q)EAAs or logs.	Identity theft (R4)
TR58	An attacker can export cryptographic binding material.	Identity theft (R4)
TR59	An attacker can take over identities through the cryptographic keys of the wallet.	Identity theft (R4)
TR60	An attacker can duplicate another user’s personal wallet unit on their personal device and use it.	Identify theft (R4) / Creation or use of an existing electronic identity (R1)
TR61	Authorities of another state can ask the user to show and/or share all the wallet data in a situation of proximity, such as when crossing the border of that state.	Identify theft (R4) / Surveillance (R14)
TR62	Users cannot transfer their transaction logs after failure of a user device, resulting in a loss of traceability of previous transactions on the new wallet.	Repudiation (R11)
TR63	Users cannot recover their transaction logs after failure of a user device, resulting in a loss of traceability on the new wallet.	Repudiation (R11)
TR64	Relying parties can have difficulties proving consent for remote electronic signatures.	Repudiation (R11)
TR65	An attacker can flood the connection(s) with requests during the connection to relying parties.	Service disruption (R13)
TR66	An attacker can flood a status provisioning service with connections to relying parties.	Service disruption (R13)
TR67	An attacker can make the attribute presentation appearing as contested/denied, despite the attribute presentation stating its validity.	Service disruption (R13)
TR68	An attacker can revoke a PID without justified reason.	Service disruption (R13)
TR69	An attacker can revoke a PID without user consent.	Service disruption (R13)
TR70	An attacker can revoke a (Q)EAA without justified reason.	Service disruption (R13)
TR71	An attacker can revoke a (Q)EAA without user consent.	Service disruption (R13)
TR72	An attacker can trigger multiple identification requests without them being recognised as intentional orphan requests.	Service disruption (R13)
TR73	An attacker can send multiple requests with no follow-up transaction.	Service disruption (R13)
TR74	An attacker can allow a relying party to request identification without a matching identification (response) and full control.	Service disruption (R13)
TR75	An attacker can send a response to a request after its timeout, or similar situations leading to a service disruption.	Service disruption (R13)
TR76	A relying party can send multiple invalid requests.	Service disruption (R13)
TR77	An attacker can send multiple invalid requests to a wallet provider.	Service disruption (R13)
TR78	An attacker can make a Member State unable to revoke an untrusted PID provider from the trusted PID provider trusted list.	Service disruption (R13)
TR79	An attacker can prevent suspension or revocation of a wallet.	Service disruption (R13)
TR80	An attacker can block transactions by relying parties, users and/or PID provider.	Service disruption (R13)
TR81	An attacker can disable or make a WSCD unavailable.	Service disruption (R13)
TR82	An attacker can make the PID provider unable to revoke or suspend PIDs.	Service disruption (R13) / Unauthorised transaction (R9)
TR83	A relying party can derive the user’s identity data beyond data shared with them.	Surveillance (R14)
TR84	A group of colluding relying parties or PID providers can derive the user’s identity data beyond data known to them.	Surveillance (R14)
TR85	An attacker can track and trace a user by using person identification data of the user where identification of the user is not required.	Surveillance (R14)
TR86	An attacker can combine a ‘forged’ presentation of (Q)EAA combinations.	Transaction manipulation (R10)
TR87	An attacker can activate/take over the wallet remotely (e.g., a bank app embedding an authentication or attestation request) without the explicit consent or sole control of the user, in situations where the user is unaware of (e.g., asleep), or cannot see the relying party.	Transaction manipulation (R10)
TR88	Attackers can make changes to a request’s metadata (service name, usages, etc.).	Transaction manipulation (R10)
TR89	Attackers can make changes to response information (service state, nonce, etc.).	Transaction manipulation (R10)
TR90	Attackers can make changes to a request’s attribute information (over asking, etc.).	Transaction manipulation (R10)
TR91	A relying party can replay elements from a previous session in another session.	Transaction manipulation (R10)
TR92	An attacker can replace or modify the PID during its transfer from the PID provider to the wallet unit.	Transaction manipulation (R10)
TR93	An attacker can replace or modify the PID during its transfer from the wallet unit to the online relying party.	Transaction manipulation (R10)
TR94	An attacker can replace or modify the PID during its transfer from the wallet unit to the offline relying party.	Transaction manipulation (R10)
TR95	An attacker can issue a PID without the user’s consent.	Unauthorised transaction (R9)
TR96	An attacker can use revoked or invalid embedded disclosure policies, possibly without the relying parties’ knowledge.	Unauthorised transaction (R9)
TR97	An attacker can trick the wallet into verifying wrong electronic signatures.	Unauthorised transaction (R9)
TR98	An attacker can use the wallet outside of the user’s control.	Unauthorised transaction (R9)
TR99	An attacker can convince a user to authenticate and approve transactions with an attacker or unauthorised third party.	Unauthorised transaction (R9)
TR100	An attacker can make a user electronically sign without presenting the content to the user or after presenting wrong content.	Unauthorised transaction (R9)
TR101	An attacker can bypass access control of the user’s account with the wallet provider.	Unauthorised transaction (R9)
TR102	An attacker can impersonate relying parties during the connection to relying parties.	Unauthorised transaction (R9) / Data disclosure (R6)
TR103	The user behind the relying party – browser connection can be different from the user behind the relying party – wallet connection.	Unauthorised transaction (R9) / Data disclosure (R6) / Identity theft (R4)
TR104	An attacker can convince the user to revoke the user’s wallet without reason.	Unauthorised transaction (R9) / Service disruption (R13)
TR105	An attacker can perform man-in-the-middle attacks.	Unauthorised transaction (R9) / Data disclosure (R6) / Surveillance (R14)
TR106	An attacker can present invalid or revoked attributes from a wallet that does not regularly connect to the network.	Effect on various risks
TR107	An attacker can steal information from a user by spoofing a wallet.	Effect on various risks
TR108	An attacker can impersonate the user by replaying/imitating a data request (e.g., authentication), which would appear as valid.	Effect on various risks
TR109	An attacker can replay an embedded disclosure policy towards a user, to imitate an approved request.	Effect on various risks
TR110	An attacker can exploit the lack of information of wallet users, or undue delays, after a security breach or compromise.	Effect on various risks
TR111	An attacker can modify a previously installed legitimate wallet instance to add malicious features.	Effect on various risks
TR112	An attacker can modify a legitimate wallet instance and propose it to users as a legitimate one.	Effect on various risks
TR113	An attacker can defeat the user authentication mechanism itself to bypass the authentication of the wallet user.	Effect on various risks
TR114	An attacker can introduce malicious code or backdoors into the wallet code during its deployment to the user device.	Effect on various risks
TR115	An attacker can introduce malicious code or backdoors into the wallet code during its development.	Effect on various risks
TR116	An attacker can tamper with the generation of random numbers to reduce their entropy sufficiently to enable attacks.	Effect on various risks
TR117	An attacker can tamper with user devices in the supply chain to include code or configurations that do not meet the conditions of use of the wallet.	Effect on various risks
TR118	An attacker can activate a wallet unit while using a spoofed WSCD controlled by the attackers.	Effect on various risks
TR119	An attacker can read information sent to the WSCA and/or the WSCD.	Effect on various risks
TR120	An attacker can send arbitrary information to the WSCA.	Effect on various risks
TR121	An attacker can steal information by intercepting the exchanges between the WSCA and the WSCD.	Effect on various risks
TR122	An attacker can send arbitrary information to the WSCD.	Effect on various risks
TR123	An attacker can send information to the WSCD, circumnavigating the WSCA.	Effect on various risks
TR124	An attacker can use phishing to get users to a fake wallet and PID management web application.	Effect on various risks
TR125	An attacker can replace a wallet’s keys with other keys to create messages to be used in another attack.	Effect on various risks
TR126	An attacker can modify or destroy a wallet’s keys, making some functions of the wallet unusable.	Effect on various risks
TR127	An attacker can control a malware to access data stored in the wallet.	Effect on various risks
TR128	An attacker can access evidence generated in the wallet.	Effect on various risks
TR129	Wallet providers can access objects in the wallet.	Effect on various risks
TR130	Wallet providers can access evidence generated in the wallet.	Effect on various risks
TR131	An attacker can steal an unlocked wallet device.	Effect on various risks
TR132	An attacker can manipulate the system to prevent certain events from being logged.	Effect on various risks
TR133	An attacker can intercept communication between the wallet instance and the WSCA, or replay/imitate a user (e.g. by hijacking authentication mechanism).	Effect on various risks

ANNEX II

CRITERIA TO ASSESS THE ACCEPTABILITY OF ASSURANCE INFORMATION

Name	Object	Points of attention
EUCC	ICT Products	About the issuer: none (accredited certification bodies) About the scope: — Check the protection profile and security target — Check the evaluation assurance level and augmentations About the assurance: — Check restrictions in the user documentation — For composition, may require access to evaluation technical report
EUCS (when available)	Cloud services	About the issuer: none (accredited certification bodies) About the scope: — Check the cloud service description — Check the evaluation level and extension profiles About the assurance: — Check the transparency information and, if needed, the composition information
Common Criteria schemes operated in the EU, including SOG-IS schemes	ICT products	About the issuer: none (Member States) About the scope: — Check the protection profile and security target — Check the evaluation assurance level and augmentations About the assurance: — Check restrictions in the user documentation — For composition, may require access to evaluation technical report
EN 17640:2018 (FITCEM, including CSPN, BSZ, LINCE, BSZA)	ICT products	About the issuer: — Check the scheme and the requirements for certification bodies About the scope: — Check the product description — Check the security claims — Check the assurance level About the assurance: — Check the activities performed and the findings in the report
Certification schemes of qualified signature creation devices in accordance with Art. 30 of Regulation (EU) No 910/2014	QSCD	About the issuer: — Check the scheme and the requirements for certification bodies About the scope: — Check the product description — Check the security claims — Check the assurance level About the assurance: — Check the activities performed
EN ISO/IEC 27001:2022	ISMS	About the issuer: none (Accredited certification bodies) About the scope: — Check the management system description — Check the statement of applicability About the assurance: — Check the activities performed
SOC2	Organisations	About the issuer: — Check their public accountant status About the scope: — Check the Management Statement and the description of the controls — Check the statement of applicability About the assurance: — Check the findings in the report — Check bridge letters if needed
MDSCert (GSMA) (when available)	Mobile Devices	About the issuer: — Check the requirements for certification bodies About the scope: — Check the security assurance level — Check the scheme requirements About the assurance: — Check the activities and findings in the report
Other schemes	Any component	About the scheme: — Check the relevance and provisions of the scheme About the issuer: — Check the requirements for certification bodies About the scope: — Check the scheme requirements — Check the security target or similar document describing the security functional and assurance requirements — Check the product description and selected security functional requirements About the assurance: — Check the activities and findings in the report

ANNEX III

FUNCTIONAL REQUIREMENTS FOR WALLET SOLUTIONS

Under Article 5a(4), (5), (8), and (14) of Regulation (EU) No 910/2014, the functional criteria to be met by a certified wallet solution and the electronic identification scheme under which it is provided shall include the functional requirements for the operations listed in the following:

• (1) Commission Implementing Regulation (EU) 2024/2979 ¹⁴ laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and of the Council as regards the integrity and core functionalities;

• (2) Commission Implementing Regulation (EU) 2024/2982 ¹⁵ laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and of the Council as regards protocols and interfaces to be supported by the European Digital Identity Framework;

• (3) Commission Implementing Regulation (EU) 2024/2977 ¹⁶ laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and of the Council as regards person identification data and electronic attestations of attributes issued to European Digital Identity Wallets.

ANNEX IV

METHODS AND PROCEDURES FOR EVALUATION ACTIVITIES

1. Audit of the implementation of a wallet solution

A conformity assessment activity shall consist of selecting specific evaluation activities.

National certification schemes shall specify an evaluation activity to assess the information provided, covering at least the following:

• (a) an analysis of the information provided to confirm that it is suited for one of the architectures specified in national certification schemes;

• (b) an analysis of the coverage of the cybersecurity risks and threats identified in the risk register of Annex I by the described security controls.

The analysis mentioned in points (a) to (b) shall rely on the rationale and justification provided by the wallet provider.

2. Evaluation activities related to the wallet secure cryptographic device

• (1) Critical operations, including cryptographic computations, are not required to be fully implemented in the WSCD. However, the part implemented in the WSCD, when operating as part of the wallet solution, shall guarantee the protection of the critical operations it performs against attacks by attackers with high attack potential in accordance with Commission Implementing Regulation (EU) 2015/1502 ¹⁷.

• (2) The WSCD or part thereof may be within the object of certification when it is provided by the certificate holder or applicant, or outside of its scope when it is embedded in a device provided by the end user. In addition, national certification schemes shall specify the evaluation activities to verify the suitability of the WSCD, in the two following cases:

• (a) if the WSCA depends on the particular WSCD (i.e. if it needs to be evaluated as a composite product based on the WSCD) then the evaluation of the WSCA shall require access to additional information related to the WSCD’s certification, including, in particular, its evaluation technical report;

• (b) if an architecture considered in the scheme uses several WSCDs, or if some of the operations on critical assets are performed outside of the WSCD, then national certification schemes shall include evaluation activities to ensure that the overall solution offers the expected level of security.

• (3) As a prerequisite to the certification under national certification schemes, the WSCD shall be assessed against the requirements of assurance level high as set out in Implementing Regulation (EU) 2015/1502.

When the conditions in Article 3(3), point (b) are fulfilled, the evaluation of the WSCD or part thereof shall include a vulnerability assessment as set out in EN ISO/IEC 15408-3:2022 at level AVA_VAN.5, as set out in Annex I of the Commission Implementing Regulation (EU) 2024/482 ¹⁸, unless it is duly justified to the certification body that the security characteristics of the WSCA make it possible to use a lower assessment level while keeping the same overall assurance level high as set out in Implementing Regulation (EU) 2015/1502.

• (4) In addition, in the documentation related to each specific architecture, national certification schemes shall formulate assumptions for this evaluation of the WSCD under which resistance against attackers with high attack potential in accordance with Implementing Regulation (EU) 2015/1502 can be provided and specify the evaluation activities to confirm these assumptions and to confirm after issuance of the certificate that the assumptions are still verified. The national schemes shall also require the candidates to certification to refine these assumptions for their specific implementation, and to describe the measures in place to guarantee that the assumptions are verified throughout the certification lifecycle.

• (5) In all cases, national certification schemes shall include an evaluation activity to verify that the assurance information available for the WSCD is suitable for the purpose of the wallet solution, through an analysis of the assurance information, such as the security target for EUCC certificates, including the following activities:

• (a) verifying that the scope of the evaluation is suitable, which for EUCC certificates, for instance, means verifying that the security target claims conformity to one of the protection profiles recommended in the EUCC;

• (b) verifying that the assumptions on the operating environment are compatible with the wallet solution, which for EUCC certificates, for instance, means that these assumptions can be found in the security target;

• (c) verifying that the recommendations in the user guidance or documentation are compatible with the conditions on which the WSCD is to be used in the wallet solution;

• (d) verifying that the assumptions made in the national certification scheme about WSCDs are verified and covered in the assurance information.

• (6) In cases where some of the verifications are not fully conclusive, national certification schemes shall require certification bodies to specify compensating requirements for the wallet secure cryptographic application (WSCA) based on the WSCD, to be included in the evaluation of the WSCA. If this is not possible, national certification schemes shall deem the WSCD unsuitable, meaning that the wallet solution shall not be issued a certificate of conformity.

3. Evaluation activities related to the wallet secure cryptographic application (WSCA)

• (1) National certification schemes shall require that a WSCA, as part of a wallet solution, is evaluated against the requirements of at least assurance level high as set out in Implementing Regulation (EU) 2015/1502.

• (2) This evaluation shall include a vulnerability assessment, as set out in EN ISO/IEC 15408-3:2022 at level AVA_VAN.5, as set out in Annex I of Implementing Regulation (EU) 2024/482, unless it is duly justified to the certification body that the security characteristics of the WSCA make it possible to use a lower assessment level while keeping the same overall assurance level high as set out in Implementing Regulation (EU) 2015/1502.

• (3) When the WSCA is not provided by the wallet provider, national certification schemes shall formulate assumptions for this evaluation of the WSCA under which resistance against attackers with high attack potential in accordance with Implementing Regulation (EU) 2015/1502 can be provided and specify the evaluation activities to confirm these assumptions and to confirm after issuance of the certificate that the assumptions are still verified. The national schemes shall also require the candidates to certification to refine these assumptions for their specific implementation, and to describe the measures in place to guarantee that the assumptions are verified throughout the certification lifecycle.

• (4) In all cases, national certification schemes shall include an evaluation activity to verify that the assurance information available for the WSCA is suitable for the purpose of the wallet solution, through an analysis of the assurance information, such as the security target for EUCC certificates, including the following activities:

• (a) verifying that the scope of the evaluation is suitable, which for EUCC certificates, for instance, means verifying that the security target claims conformity to one of the protection profiles recommended in the EUCC;

• (b) verifying that the assumptions on the operating environment are compatible with the wallet solution, which for EUCC certificates, for instance, means that these assumptions can be found in the security target;

• (c) verifying that the recommendations in the user guidance or documentation are compatible with the conditions on which the WSCA is to be used in the wallet solution;

• (d) verifying that the assumptions made in the national certification scheme about WSCAs are verified and covered in the assurance information.

• (5) National certification schemes shall require that the evaluation of the WSCA covers all security controls implemented by this WSCA.

4. Evaluation activities related to the end user device

Since the risk register, as set out in Annex I of this Regulation, identifies risks that are directly linked to the security of the end user device, national certification schemes shall specify security requirements for end user devices. However, as these devices are provided by the end user and not by the wallet provider, these requirements shall be covered by assumptions.

For each assumption, the wallet solution shall include a mechanism to verify for every wallet unit that the underlying end user device satisfies the assumption. Such mechanisms shall be considered as security controls and covered by evaluation activities to demonstrate both their suitability and their effectiveness at the appropriate assurance level.

Two examples are set out below:

• (a) an end user device may include a certified WSCD, which needs to be demonstrated. Typically, this would be done by using a cryptographic mechanism to verify the presence in the certified WSCD of a cryptographic secret that is only available in the certified WSCD. In this case, this cryptographic secret should be considered as a critical asset and be covered by the certification of the WSCD and/or of the WSCA;

• (b) a typical requirement for end user devices would be that the devices must receive security updates. Since this requirement is related to the wallet instance, the mechanism used to verify the availability of security updates only needs to be covered by evaluation activities at an assurance level suitable for the wallet instance, especially as it is likely to be integrated into the wallet instance.

5. Evaluation activities related to the wallet instance

• (1) The evaluation of the wallet instance shall consider the following two main challenges:

• (a) the wallet instance is likely to exist in a set of variants of the same base application, with each variant specialised for a specific category of end user devices;

• (b) the different variants of the wallet instance will likely need frequent updates in order to follow the development of the underlying security platform, for instance when vulnerabilities are identified that require changes to applications.

• (2) The evaluation of the wallet instance shall take into consideration these specific challenges. One of the immediate consequences is that the Common Criteria framework may not be suitable in all cases. Therefore, alternative evaluation methodologies shall be considered where necessary. National certification schemes shall consider the use of the EN 17640:2018 methodology for the following:

• (a) as part of the scheme itself;

• (b) through national schemes based on the methodology;

• (c) through national schemes based on similar principles but created before the development of the EN 17640:2018 methodology.

• (3) In addition, as there may be limited added value in performing a full dedicated evaluation of each variant, national certification schemes shall consider specifying criteria allowing sampling to be performed, in order to avoid repetition of identical evaluation activities and to focus on activities that are specific to a given variant. National certification schemes shall require all certification bodies to justify their use of sampling.

• (4) National certification schemes shall include updates of the wallet instance in the overall change management process specified for the wallet solution. They shall also lay down rules on the procedures that shall be performed by the wallet provider for every update (e.g. analysing the impact of the changes on the security controls), and on the evaluation activities that shall be performed by the certification body on updates under specified conditions (e.g. assessing the operating effectiveness of a modified security control). The change management process is one of the processes whose operating effectiveness is required to be checked annually in accordance with Article 18(3).

6. Evaluation activities related to the services and processes used for the provision and operation of the wallet solution

• (1) For the evaluation of services and processes that play a role in the provision and operation of the wallet solution and the electronic identification scheme under which they are provided, the evaluation team shall gather evidence by conducting evaluation activities that may include audit, inspection, verification and validation activities.

• (2) The certification body shall confirm the sufficiency and appropriateness of the evidence to provide sufficient assurance that the services and processes meet the certification requirements, by confirming the following:

• (a) the accuracy of the information presented in the description of the processes and services;

• (b) the suitability of the design and the controls of the processes and services to meet the evaluation criteria;

• (c) the operating effectiveness of an implementation of these controls throughout a specified period before the evaluation.

• (3) The accuracy of the description and the operating effectiveness of an implementation of controls may be considered as verification objectives, in the sense of ISO/IEC 17000:2020, of the corresponding claims by the wallet provider (i.e. confirmation of fairness of events that have already occurred or results that have already been obtained), whereas the suitability of the design and the controls of the services and processes to meet the evaluation criteria may be considered as a validation objective, in the sense of ISO/IEC 17000:2020, of the corresponding claim by the wallet provider (i.e. confirmation of plausibility regarding an intended future use or projected outcome).

• (4) Considering that a wallet solution is not allowed to operate before being certified, operating effectiveness cannot be confirmed on the basis of the actual operation of the solution. Therefore, this shall be confirmed using evidence gathered during tests or pilots.

• (5) National certification schemes may already exist for specific services and processes, for instance for the onboarding of users. The use of such schemes shall be considered by national certification schemes, if applicable.

7. Evaluation activities related to the ICT services used for the provision and operation of the wallet solution

• (1) Some wallet architectures may rely on dedicated ICT services, including cloud services for the provision and operation of a wallet solution, and these services may host sensitive data as well as sensitive operations. In such a case, national certification schemes shall specify security requirements for these ICT services.

• (2) Many certification schemes already exist for ICT services, cloud services, and other sources of assurance information, including those listed in Annex II. National certification schemes shall rely, when available and applicable, on those existing mechanisms, through one of the following mechanisms:

• (a) mandating the use of a specific scheme or of a selection of schemes, by specifying the conditions under which the ICT or cloud services is to be assessed using these schemes;

• (b) leaving the choice of the assessment to the wallet provider and use the dependency analysis activity to analyse the suitability of the assurance information obtained through these assessments.

• (3) In both cases, national certification schemes shall specify additional evaluation activities as needed to analyse or supplement the information obtained through these schemes.

ANNEX V

LIST OF PUBLICLY AVAILABLE INFORMATION ABOUT WALLETS

1.

The information that shall be made public pursuant to Article 8(5) shall include at least the following:

• (a) any limitations on the use of a wallet solution;

• (b) guidance and recommendations by the wallet provider to assist end users with the secure configuration, installation, deployment, operation and maintenance of wallets;

• (c) the period during which security support will be offered to end users, in particular as regards to the availability of cybersecurity related updates;

• (d) contact information of the manufacturer or provider and accepted methods for receiving vulnerability information from end users and security researchers;

• (e) a reference to online repositories listing publicly disclosed vulnerabilities related to wallets and to any relevant cybersecurity advisories.

2.

The information referred to in paragraph 1 shall be made available in a clear, comprehensive and easily accessible manner, in a publicly accessible space, to any person seeking to use a wallet solution.

ANNEX VI

METHODOLOGY TO ASSESS THE ACCEPTABILITY OF ASSURANCE INFORMATION

1. Assessing the availability of assurance documentation

Evaluators shall list the assurance documentation available for every relevant component of the wallet solution and the electronic identification scheme under which they are provided. Then, evaluators shall assess the overall relevance of each piece of assurance documentation for the dependency review.

The following aspects shall be considered in the analysis:

• (1) about the assurance documentation itself:

• (a) the type of assurance documentation, with all required details,

(examples of such documents are certificates of conformity according to EN ISO/IEC 27001:2022 or Type 1 or Type 2 for ISAE reports);

• (b) the period covered or period of validity,

(this period may be supplemented with a bridge letter (a document to cover a period of time between the end date of the reporting period of the current ISAE report and the release of a new ISAE report) or similar a statement);

• (c) the applicable framework (e.g. existing standard);

• (d) whether the assurance documentation includes a mapping to the scheme’s requirements;

• (2) about the assurance report issuer’s professional competence and impartiality:

• (a) name of the certification body and, if available, name of the lead evaluator;

• (b) evidence of the certification body’s and the evaluator’s competence (e.g. accreditation, personal certification, etc.);

• (c) evidence of the certification body’s and the evaluator’s impartiality (e.g. accreditation, etc.).

2. Assessing assurance related to individual requirements

Evaluators shall verify that the assurance documentation available for the wallet solution and the electronic identification scheme under which they are provided is adequate to determine that the wallet solution meets the expectations relative to the certification scheme’s individual requirements.

This assessment shall be performed for every relevant component of the wallet solution and the electronic identification scheme under which they are provided, by formulating an assumption on the wallet solution’s security controls.

For each such assumption, the evaluation team shall determine whether or not the assurance provided in the available assurance documentation is adequate.

The determination that the assurance is adequate shall be based on the following:

• (1) the required information is available, with the expected assurance level, in the assurance documentation;

• (2) the information available in the assurance documentation does not cover the full scope of the requirement, but additional controls or compensating controls (i.e., internal controls that reduce the risk of existing or potential control weakness) implemented in the wallet solution or in the electronic identification scheme under which they are provided allow the evaluators to determine that the information is adequate;

• (3) the information available in the assurance documentation does not offer the expected assurance level but the controls implemented to assess and monitor the wallet provider allow the evaluators to determine that the information is adequate;

• (4) if the assurance documentation mentions nonconformities on the design or implementation of the controls used to meet an assumption, the remedial actions proposed and implemented by the wallet provider and reviewed by its evaluators shall be adequate to guarantee that the assumption is indeed met.

ANNEX VII

CONTENT OF THE CERTIFICATE OF CONFORMITY

1.

A unique identifier allocated by the certification body issuing the certificate of conformity.

2.

Information related to the certified wallet solution and the electronic identification schemes under which they are provided, and about the holder of the certificate of conformity, including the following:

• (a) name of the wallet solution;

• (b) name of the electronic identification schemes under which the wallet solution is provided;

• (c) version of the wallet solution that was evaluated;

• (d) name, address and contact information of the holder of the certificate of conformity;

• (e) link to the website of the holder of the certificate of conformity containing the information that is required to be made publicly available.

3.

Information related to the evaluation and certification of the wallet solution and the electronic identification schemes under which they are provided, including the following:

• (a) name, address and contact information of the certification body that issued the certificate of conformity;

• (b) where different from the certification body, name of the conformity assessment body that performed the evaluation, together with information on its accreditation;

• (c) name of the scheme owner;

• (d) references to Regulation (EU) No 910/2014 and to this Regulation;

• (e) a reference to the certification report associated with the certificate of conformity;

• (f) a reference to the certification assessment report associated with the certificate of conformity;

• (g) a reference to the standards used for the evaluation, including their versions;

• (h) the date of issuance of the certificate of conformity;

• (i) the period of validity of the certificate of conformity.

ANNEX VIII

CONTENT OF THE PUBLIC CERTIFICATION REPORT AND THE CERTIFICATION ASSESSMENT REPORT

1.

The public certification report shall contain at least the following aspects:

• (a) executive summary;

• (b) identification of the wallet solution and of the electronic identification scheme under which they are provided;

• (c) a description of the wallet solution and of the electronic identification scheme under which they are provided;

• (d) the security information to be made publicly available, as described in Annex V, or a pointer to this information;

• (e) a summary of the preliminary audit and validation plan;

• (f) a summary of the review and the certification decision.

2.

The certification assessment report shall at least contain:

• (a) a description of the wallet solution’s design, the identification system and the onboarding process, together with the risk assessment and the specific validation plan;

• (b) a description of how the wallet solution meets the requirements of assurance level high and of how this is demonstrated by the results of the certification assessment of the wallet solution conducted in accordance with this Regulation;

• (c) a description of the result of assessment of the conformity of the wallet solution and of the electronic identification scheme under which the corresponding wallet units are provided with, in particular the conformity with the following:

• — the requirements set out in Article 5a(4), (5), and (8) of Regulation (EU) No 910/2014;

• — the requirement for logical separation set out in Article 5a(14) of Regulation (EU) No 910/2014;

• — where applicable, the standards and technical specifications referred to in Article 5a(24) of Regulation (EU) No 910/2014, while describing how these requirements relate to the corresponding normative requirements specified by national certification schemes;

• (d) a summary of the result of the performance of the validation plan, including all identified nonconformities.

ANNEX IX

SCHEDULE FOR MANDATORY SURVEILLANCE EVALUATIONS

1.

Article 18 specifies requirements for the certification lifecycle, in particular the performance of regular evaluation activities. These activities shall include at least the following:

• (a) a full evaluation of the object of conformity assessment in the initial evaluation and at every recertification evaluation, including an update feature of any product component;

• (b) a vulnerability assessment in the initial evaluation and at every recertification evaluation, and at least every two years in surveillance evaluations, covering at least the changes in the object of conformity assessment and the changes in the threat environment since the last vulnerability assessment;

• (c) additional activities such as penetration testing in case of an increased risk level or the emergence of new threats;

• (d) an evaluation of the operating effectiveness of maintenance processes at least every year in surveillance and recertification evaluations, covering at least version control, update and vulnerability management processes;

• (e) following a successful review and certification decision, the issuance of a certificate of conformity after the initial evaluation and after every recertification evaluation.

2.

A reference schedule is set out in Table 1 based on a 4-year cycle, where:

• (a) year 1 starts when the certificate of conformity is first issued; and

• (b) all evaluation activities shall be performed within 12-months from the evaluation of the previous year.

3.

The schedule set out in Table 1 is a recommendation to ensure timely recertification and to avoid disruptions in the provision of the wallet solution. Other schedules may be possible, as long as the validity of the certificate of conformity does not exceed five years, as laid down in Article 5c(4) of Regulation (EU) No 910/2014.

4.

In addition to the regular evaluations, a special evaluation might be triggered at the demand of the certification body or of the holder of the certificate of conformity, following a significant change to the object of certification or to the threat environment.

5.

Any evaluation, including surveillance evaluations and special evaluations, might lead to the issuance of a new certificate of conformity, in particular in case of significant changes to the object of certification, but with the same date of expiry as the original certificate of conformity.

Table 1

A full 4-year evaluation cycle

Time	Eval. type	Activities
Year 0	Initial	— Full evaluation of the object of certification, including vulnerability assessment — Including a feature to perform updates on each software component — Evaluation of the maintenance processes, excluding their operating effectiveness — Issuance of the certificate of conformity and start of the 4-year cycle
Year 1	Surveillance	— Evaluation of the operating effectiveness of the maintenance processes — At least version check, update, vulnerability management — Evaluation of changes impacting the security of the product
Year 2	Surveillance	— Vulnerability assessment of the full solution — Evaluation of the operating effectiveness of the maintenance processes — At least version control, update, vulnerability management — Evaluation of changes impacting the security of the product
Year 3	Surveillance	— Evaluation of the operating effectiveness of the maintenance processes — At least version check, update, vulnerability management — Evaluation of changes impacting the security of the product
Year 4	Recertification	(1) Full evaluation of the object of certification, including vulnerability assessment (2) Simplified evaluation for features/processes that have not changed (3) Including a feature to perform updates on each software component (4) Evaluation of the maintenance processes, including their operating effectiveness (5) Issuance of a new certificate of conformity

ELI: http://data.europa.eu/eli/reg_impl/2024/2981/oj

ISSN 1977-0677 (electronic edition)