Topic T - Support and maintenance by the Wallet Provider

[phin10]

Description
Are specific requirements necessary to govern support and maintenance of the Wallet? For instance, guidelines could clarify what types of data the Wallet Provider is permitted (or prohibited) from collecting from Wallet Instances for support and maintenance purposes.

Publication discussion paper
1 October 2025

Link to discussion paper
Link

Discussion close
Three weeks later.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicT AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[david-bakker]

Thank you for your letter. It was duly analysed and considered in the discussion and the High-Level Requirements definition for the new Support and Maintenance by the Wallet Provider section in the ARF Annex 2 and main document. Hereby we provide a detailed response.

The ARF editing team shares the point of view of AEPD that functions related to maintenance, technical support, incident response, or recovery by Wallet Providers (WPs) must be carefully assessed to prevent infringements of fundamental user rights of the Wallet Users, particularly concerning tracking and surveillance.

The ARF team took those principles into account when defining the new High-Level Requirements and believes that such principles are not violated. We are highlighting the Regulation’s text on data minimisation and logical data separation (Article 5a(14) as a strong regulatory requirement for the Wallet Providers – this article has been now added to the final topic T text version.

Below we provide responses to some specific comments from your letter.

(1) In reference to the observations of AEPD:

Strict adherence to data protection principles: All data processing carried out by theWallet Provider for support and maintenance must be limited to what is strictly necessary for the provision of the Wallet services (data minimisation and purpose limitation). For example, any processing of personal data in the logs must be collected for specified, explicit, and legitimate purposes. The primary purpose is to provide users with a transparent history of their activities and enable them to exercise their rights. Processing these logs for undisclosed purposes beyond what users reasonably expect would violate the principles of lawfulness, fairness, and transparency. What specific High Level Requirements support this adherence? We recommend providing explicit guidance on what personal data the Wallet Provider is permitted to collect from Wallet Instances for each specific mandatory support and maintenance purposes:

• installation of a new version of the Wallet Solution,
• WUAs update,
• Wallet Unit revocation (in case its security is compromised, for example),
• regular updates of the Wallet Instance application, etc.

Additionally, we recommend including a HLR mandating Wallet Providers to list, in advance, any other support and maintenance activity necessary for the provision of Wallet services. The proposed list would serve to formally delineate these specific, necessary processing activities, ensuring they have a legal basis, a specific purpose, etc.

ARF writers’ response:
After the latest discussions and comments, the Discussion Paper now says that Wallet Providers have two secondary purposes for data processing – product maintenance (improved service) and understanding the security posture of individual Wallet Instances over time (for protection against malicious use and fraud with User’s Wallet Instances, which Users assume to be highly secure by nature). We have tried to exclude most privacy-sensitive information available for mobile software developers when it comes to recommended monitorable data for Wallet Providers. Also, the two HLRs listing potential data to be collected now demand the Wallet Provider to make and document transparently (publish as part of their Terms of Service, most likely) the data they collect on either maintenance or security posture analysis related monitoring: “The Wallet Provider SHALL monitor their installed base of operational Wallet Instances for maintenance and detecting critical security risks, and determine and document in a transparent manner the data it needs and is allowed to monitor…”

(2) In reference to the comment of AEPD:

Unobservability during support activities: Support and maintenance operations pose a direct threat to the principle of unobservability, which mandates that WPs should not have insight into the details of the users’ transactions. While Wallet Providers are required to ensure users can easily request technical support and report technical problems or other incidents, the mechanisms established for reporting and diagnosis must uphold the requirement that the technical framework does not allow Wallet Providers to link, correlate, or track transactions or user behaviour. If access to transaction data is genuinely required for diagnostic purposes (e.g., investigating a reported technical issue), this should only be granted in specific cases, on an instance-by-instance basis. Again, we recommend providing explicit guidance on what personal data the Wallet Provider is permitted to collect from Wallet Instances for each specific mandatory support and maintenance purpose, such as providing technical support, investigating a technical problem, or incident.

ARF writers’ response:
With the set of monitorable items that is currently recommended in the Discussion Paper, the Wallet Provider is not expected to monitor or gain insight to the user’s transactions.

Note that transactions-related security posturę analysis can and most likely will happen by Relying Parties (as opposed to Wallet Providers) that carry the transaction-related business risks. This is outside the scope of this paper and the ARF. An example of this includes IP address monitoring, which is a commonly used anomaly detection tool in payments and eID means fraud analysis today in existing service architectures. However, the Discussion Paper does not recommend this data for the Wallet Providers’ monitoring palette, exactly for the reasons listed in your concern.

(3) In reference to the comments of AEPD:

Data separation as a foundation for compliance: The eIDAS 2.0 regulation requires that personal data related to the provision of the European Digital Identity Wallet be kept logically separate from any other data held by the provider. This includes data gathered during support or maintenance activities. This measure is essential to prevent the Wallet Provider from combining personal data from Wallet services with personal data derived from any other services they offer, thereby preventing misuse.

ARF writers’ response:
In one of the previous discussion topics and related HLRs, the requirement WIAM_12a (“The Wallet Unit SHALL ensure that the Wallet Provider cannot access the contents of the Wallet Unit, in particular to learn a) which attestations are present on the Wallet Unit, b) the status of these attestations, c) the value of attributes in these attestations, and d) the contents of the Wallet Unit log meant in DASH_02”) was added to the ARF.

The corresponding article from the Regulation has been added to the discussion paper’s regulatory background section. There is no new HLR on the logical data separation requirement in this discussion topic, but we expect (and recommend) that the certification criteria set for the Wallet Providers would include audit requirements against this article. Each Wallet Solution will have to go through detailed security evaluations to receive the necessary certification, as mandated by the eIDAS Regulation and CIR 2024/2981.

(4) In reference to the comments of AEPD:

Transparency and user control over maintenance: The user must maintain full control over maintenance activities, which must be transparent. The user must be kept informed and involved as a data subject in processes such as revocation or re-issuance and must be allowed to exercise all their data protection rights about these processes, even if explicit user actions are not required. Furthermore, users must be provided with clear and comprehensive information about security measures in place for processes such as data portability (export/import), as a lack of transparency would infringe the GDPR's transparency principle.

ARF writers’ response:
The maintenance process and involved data shall be documented by the Wallet Provider, as covered in earlier comment’s response.

Communicating the user of Wallet Instance suspension and revocation events (or risk thereof, unless the user updates their Wallet Instance or otherwise fixes identified vulnerabilities on their device) is already included in the Wallet Unit revocation related topic and HLRs in the ARF.

Wallet Providers are not positioned (as app developers for mobile OS platforms) to set their own policies regarding enforcing updates. A user cannot be forced to update their Wallet Instances, and the Wallet Provider cannot update the Wallet Instance software automatically without end-user’s prior ‘global’ consent to allow background app updates through the mobile OS level mechanisms.

For the communication and transparency, the new HLR included sets the Wallet Provider the duty to guide the user on how to perform the required update (or vulnerability fix, if outside of the Wallet Instance itself, like OS version upgrade in the device).

We don’t take a technical requirement position on informing the user of the security measures related to data portability as a GDPR-set requirement. We assume a Wallet Provider failing to communicate their measures to the user’s in their Terms of Service or Privacy Policy would simply not pass the certification criteria that expects compliance with the GDPR.

(5) In reference to the comments of AEPD:

Accountability for data integrity and confidentiality: Maintenance activities, such as implementing recovery processes or facilitating migration, rely on secure handling of the Migration Object. Any vulnerabilities that allow tampering or unauthorized access may violate users' fundamental rights. Therefore, specific requirements concerning the protection of the Migration Object during export and import processes, for example, must be established. The ARF should require WPs to establish procedures for data breaches and conduct regular audits to test security measures (e.g., encryption and access controls).

ARF writers’ response:

The content of the Migration Object, required security, and data security/vulnerability differences between different attestation types (or rather, their cryptographic binding type) of the user are covered in the section 6.5.4.3 of the ARF 2.7.3 and Topic 34 of Annex 2. It should be noted that only attestations with low, or none type of key binding should contain actual data values in the MO, therefore narrowing the sensitivity level of MO data as a whole.

Special HLR regarding the protection of the MO is documented can be found in Mig_05 in Topic 34, and the technical specification that contains the encryption requirements for the MO is TS10 (see sections 4.2 and 5).