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 legally recognised attribute that can be included in electronic identification means, 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, by contrast, 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. Crucially, 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 are required to ensure that pseudonyms are generated and managed in a way that protects user privacy. This means the pseudonym must not be derived from, or allow inference of, the user’s real identity without proper authorisation. The underlying technical and governance requirements are set out in the Architecture and Reference Framework that guides EUDI Wallet implementation across Europe.

How does the EUDI Wallet generate and manage pseudonyms?

The EUDI Wallet generates pseudonyms through a cryptographic process that creates a unique, unlinkable 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 can see what is being shared before confirming.

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, the pseudonym generation relies on the same cryptographic infrastructure that underpins the wallet’s verifiable credentials. The result is a pseudonymous identifier that is both stable for the intended relying party and privacy-preserving across the broader ecosystem. Organisations looking to understand how this infrastructure connects to their own systems can explore identity solutions built on these standards.

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 not just a privacy concern; it is a compliance risk. Designing services to accept pseudonyms where appropriate is therefore both a good privacy practice and a sound regulatory strategy.

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, by contrast, 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:

1. 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.
2. 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.
3. 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. 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 TrustTech helps with eIDAS 2.0 pseudonym implementation

Implementing pseudonyms correctly under eIDAS 2.0 is not just a technical challenge. It requires a clear understanding of the regulatory framework, the right architecture decisions, and a practical approach to integrating EUDI Wallet-ready identity flows into existing systems. TrustTech supports organisations at every stage of this process.

Working with TrustTech means you get:

• Expert guidance on when to use pseudonyms versus persistent unique identifiers in your specific sector
• Technical implementation support for EUDI Wallet-compatible identity flows, including selective disclosure and pseudonym generation
• Compliance alignment across eIDAS 2.0, GDPR, and sector-specific regulations such as AML and KYC
• A platform built for reusable, wallet-ready digital identity that reduces friction for users and the compliance burden for your organisation
• Proven experience across regulated sectors including finance, government, healthcare, and pharmaceuticals

Whether you are at the early stages of understanding what eIDAS 2.0 means for your organisation or ready to start building, TrustTech provides the infrastructure and expertise to move forward with confidence. Get in touch with TrustTech to discuss your digital identity needs and find out how we can help you prepare for the next generation of trusted digital interactions.