Under eIDAS 2.0, a pseudonym is a digital identifier that allows a person to authenticate and interact with services without revealing their real name or full identity. It is a recognised attribute that can be included in the Person Identification Data set of a European Digital Identity Wallet, giving users the ability to prove they are a consistent, verified entity without disclosing who they actually are. The sections below unpack how pseudonyms work in practice, what the regulation requires, and when organisations should use them.
How does a pseudonym differ from an anonymous identifier in eIDAS 2.0?
A pseudonym under eIDAS 2.0 is not the same as an anonymous identifier. A pseudonym is a stable, verifiable substitute for a real identity that is still linked to a known person in the background. An anonymous identifier carries no such link. If someone uses an anonymous identifier, there is no way to trace it back to a real individual, even for authorised parties.
The key distinction is traceability with privacy. With a pseudonymous identifier, the underlying real identity exists and can be revealed under defined legal circumstances, for example by a court order or a regulatory authority. With anonymity, that connection is permanently severed. This makes pseudonyms far more useful in regulated environments, where accountability still matters even when privacy is protected.
In practical terms, a pseudonym lets a user interact with a service consistently over time. A service provider sees the same pseudonymous identifier each time that user returns, which makes session continuity and personalisation possible. An anonymous identifier would generate a new, unlinked token each time, making continuity impossible. For organisations in sectors like financial services or healthcare, where knowing that the same person has returned matters for compliance, pseudonyms strike the right balance between privacy and accountability.
What are the legal requirements for pseudonyms under eIDAS 2.0?
Under eIDAS 2.0, pseudonyms are a recognised attribute that can be included in the Person Identification Data set of a European Digital Identity Wallet. The regulation allows users to present a pseudonym instead of their legal name when accessing services, provided that the relying party does not legally require the real name. The pseudonym must be clearly labelled as such, so the receiving party knows they are not receiving a legal name.
The regulation also sets out that pseudonyms must not be used to circumvent identity verification obligations. Where a service is legally required to establish the real identity of a user, such as under anti-money laundering rules, a pseudonym alone is not sufficient. The legal framework therefore draws a clear line between services where pseudonymity is appropriate and those where it is not.
Member States and wallet providers each carry distinct responsibilities in ensuring that pseudonyms are generated and managed in a way that protects user privacy. Member States are responsible for providing or mandating wallet solutions, certifying and notifying them, and supervising actors within their jurisdiction. Wallet providers are responsible for implementing the technical and operational requirements that flow from the legally binding implementing acts adopted by the European Commission. The Architecture and Reference Framework provides the technical elaboration of those requirements and guides EUDI Wallet implementation across Europe, but it is the implementing acts that carry legal force.
A pseudonym generated by the EUDI Wallet is not a PID attribute. It is generated by the wallet itself and stored locally on the user’s device. This means the pseudonym is not issued by a PID provider and does not appear in the Person Identification Data set as a named attribute in the same way that, for example, a date of birth or nationality would.
How does the EUDI Wallet generate and manage pseudonyms?
The EUDI Wallet generates pseudonyms through a cryptographic process that creates a unique identifier for each combination of user and relying party. This means that the pseudonym a user presents to a bank is different from the one they present to a government portal, even though both are derived from the same verified identity. This design prevents different services from cross-referencing a user’s activity without their knowledge.
The wallet manages pseudonyms locally on the user’s device, keeping the user in control of which pseudonym is shared with which service. When a user initiates an interaction, the wallet generates or retrieves the appropriate pseudonym and presents it alongside any other requested attributes. The user reviews what is being shared before confirming each individual presentation request.
This approach reflects one of the core design principles of the EUDI Wallet: selective disclosure. Users share only what is necessary for a given interaction. For many everyday services, a pseudonym combined with a small number of verified attributes, such as age range or country of residence, is all that is needed. This minimises the personal data footprint of each interaction without reducing the trustworthiness of the exchange.
From a technical standpoint, pseudonym generation relies on the same cryptographic infrastructure that underpins the wallet’s verifiable credentials. The result is a pseudonymous identifier that is stable for the intended relying party and privacy-preserving across the broader ecosystem. When a relying party receives a presentation, verification involves checking the issuer’s signature against the relevant national trusted list, confirming the revocation status of the attestation, and validating the wallet unit attestation to confirm that the presenting wallet runs on a certified wallet solution. These three checks are distinct: only the signature check can be performed fully offline.
When should organisations request a pseudonym instead of a real identifier?
Organisations should request a pseudonym instead of a real identifier when their service does not legally require knowledge of the user’s real name, and when collecting that name would create unnecessary privacy risk. The right question to ask is: do we actually need to know who this person is, or do we just need to know they are the same person as before?
There are several scenarios where a pseudonym is clearly the better choice:
- Loyalty or subscription services where continuity matters but legal identity does not
- Online platforms where age verification is required but the user’s name is not
- Research or survey tools where consistent participation tracking is needed without personal data collection
- Access control systems where the question is “is this an authorised user?” rather than “who is this person?”
- Cross-border services where collecting real names may trigger additional data protection obligations
On the other hand, organisations in regulated sectors such as banking, insurance, or healthcare often have legal obligations that require real identity verification. In those cases, a pseudonym can still play a role after the initial identity check, for example as the identifier used in ongoing interactions once the real identity has been established and recorded.
The key principle under eIDAS 2.0 is data minimisation. Requesting more identity data than is necessary is a compliance risk under the GDPR as well as a privacy concern. Designing services to accept pseudonyms where appropriate is therefore both a sound privacy practice and a sound regulatory strategy. It is worth noting that a relying party must register with the national authority of its Member State of establishment under CIR (EU) 2025/848 before it can request wallet data. That registration specifies, per intended use, which attributes and attestations the relying party is permitted to request. The wallet checks each presentation request against this registered scope.
What is the difference between a pseudonym and a persistent unique identifier in eIDAS 2.0?
A persistent unique identifier (PUI) under eIDAS 2.0 is a stable identifier assigned to a person that remains the same across all interactions with all services. It is designed for interoperability and record-keeping across systems. A pseudonym is designed to be service-specific and privacy-preserving, varying from one relying party to the next even for the same user.
The practical difference comes down to linkability. A persistent unique identifier allows different organisations to recognise that they are dealing with the same individual, which is useful for cross-sector data sharing, government services, and long-term record management. A pseudonym deliberately prevents this cross-service linkability, protecting the user from being profiled across different contexts.
Under eIDAS 2.0, both types of identifier have their place, and the choice between them should be driven by the purpose of the service:
- Use a persistent unique identifier when cross-system continuity is a legal or operational requirement, such as in healthcare records, tax administration, or social security systems.
- Use a pseudonym when the service only needs to recognise a returning user within its own context, without needing to link that user to their activity elsewhere.
- Combine both in layered architectures where an initial verified interaction uses the PUI for compliance, and subsequent interactions use a pseudonym for privacy.
For organisations designing identity flows, understanding this distinction is essential. Choosing the wrong identifier type can result in either unnecessary data exposure or a failure to meet interoperability requirements. It is also worth noting that cross-border use of EUDI Wallet credentials is designed to work across Member States where certified wallets are in use, but this does not mean that every use case will be immediately available in every Member State, that national registration requirements disappear, or that sector-specific legislation is overridden. The implementation approach an organisation takes should reflect the specific legal and operational context of each service it provides.
For government services, where both accountability and citizen privacy are critical, this distinction is particularly significant. Organisations in the public sector will often need to navigate both identifier types within the same platform.
How the ID Connector supports pseudonym implementation
The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
In the context of pseudonym flows, the ID Connector handles several concrete functions:
- Accepting pseudonymous presentations from any certified EUDI Wallet and mapping them consistently to the relying party’s own session or account layer
- Verifying issuer signatures against the relevant national trusted lists, which are part of the EU List of Trusted Lists
- Checking the revocation status of attestations presented alongside a pseudonym
- Validating wallet unit attestations to confirm that the presenting wallet runs on a certified wallet solution
- Enforcing the registered attribute scope so that only the attributes declared in the relying party’s registration under CIR (EU) 2025/848 are requested
- Supporting account linking via stable pseudonyms or verified attributes, without tying any record to a wallet unit identifier
This applies across the sectors where pseudonym flows are most relevant: financial services, healthcare, pharma, and government. Organisations in these sectors can use the ID Connector to accept wallet presentations today and to be ready for the public sector acceptance deadline of 24 December 2026 and the private sector obligation under Article 5f that applies from 24 December 2027.
Get in touch with TrustTech to find out how the ID Connector fits your identity architecture and what it takes to accept pseudonymous wallet presentations in your specific context.