Authentication and authorization are two distinct steps in digital identity: authentication confirms who you are, while authorization determines what you are allowed to do. Under eIDAS 2.0, this distinction becomes especially important because the regulation sets binding standards for how identity is verified across the EU, while access decisions remain the responsibility of individual services and organizations. The sections below unpack each concept, explain how they interact in the EUDI Wallet ecosystem, and show why getting them right matters for compliance.
How does authentication work differently from authorization in digital identity?
Authentication is the process of verifying that a person or entity is who they claim to be. Authorization is the process of deciding what that verified person or entity is permitted to access or do. The two are sequential: authentication always comes first, and authorization depends on its outcome. Confusing the two, or treating them as interchangeable, leads to gaps in both security and compliance.
Think of it this way: authentication is the moment you show your passport at a border. The officer checks that the document is genuine and that the face matches. That is identity verification. Authorization is the decision about whether you are allowed to enter the country based on your visa, nationality, or other criteria. The passport does not grant you entry on its own.
In digital identity systems, authentication typically involves credentials such as a username and password, a biometric check, or a government-issued digital ID. Authorization then applies rules, roles, or policies to determine what resources or services the authenticated user can access. Both steps are necessary, but they serve fundamentally different purposes and are governed by different mechanisms.
How does eIDAS 2.0 handle authentication specifically?
eIDAS 2.0, which amends Regulation (EU) 910/2014, focuses primarily on authentication. The regulation establishes a framework for how electronic identification schemes are recognized across EU Member States, and it defines assurance levels that determine how reliably a person’s identity has been verified. These assurance levels, low, substantial, and high, describe the degree of confidence that can be placed in an authentication claim.
Under eIDAS 2.0, every EU Member State is required to make a European Digital Identity Wallet available to citizens, residents, and businesses by 24 December 2026. This date is the legal deadline set by the regulation; it does not guarantee that every national wallet will have reached the same level of maturity, or that every possible cross-border use case will be fully operational throughout Europe on that date. Practical interoperability and national rollout are expected to develop in phases, as wallets are certified, notified, and progressively adopted by relying parties. Once available, the wallet enables EUDI Wallet authentication across both public and private digital services throughout the EU. When a user authenticates using their wallet, the relying party receives cryptographically verified identity attributes, not just a token or a password.
What makes eIDAS 2.0 authentication distinctive is the combination of portability and assurance. The EUDI Wallet framework is designed so that a certified wallet from one Member State can be used with an appropriate relying party in another Member State. A person verified at the high assurance level in one Member State can use that same verified identity to authenticate in another, provided the relevant wallet has been certified and notified and the relying party is set up to accept it. This cross-border recognition was a core gap in the original eIDAS regulation, and the revised framework addresses it directly by making recognition mandatory. It is important to note, however, that cross-border use does not eliminate national registration requirements, sector-specific legislation, or differences in how individual credentials are treated across jurisdictions.
It is also worth noting that eIDAS 2.0 does not dictate authorization decisions. Once a service has received a verified authentication from a wallet or eID scheme, what that service does with the result, which features it unlocks, which data it shares, which actions it permits, falls entirely outside the scope of the regulation. That is an organizational and technical responsibility.
What role does authorization play in the EUDI Wallet ecosystem?
Authorization in the EUDI Wallet ecosystem is the layer that sits on top of verified identity. After a user authenticates using their wallet, the relying party uses the verified attributes to make access decisions. The wallet itself does not grant permissions; it delivers trusted, verified data that services can use to apply their own authorization logic.
Governance of the EUDI Wallet ecosystem is a shared responsibility. The European Commission manages the legal framework and adopts implementing acts that contain legally binding requirements. EU Member States are responsible for providing or mandating wallet solutions, certifying and notifying them, and supervising actors within their jurisdiction. The European Digital Identity Cooperation Group supports cooperation and cross-border alignment. National competent authorities and registrars, wallet providers, issuers of Person Identification Data and attestations, qualified trust service providers, and relying parties each carry distinct responsibilities within this structure. No single central European authority operationally manages all EUDI Wallets.
Before a relying party can request wallet data, it must register with the national authority of its Member State of establishment under CIR (EU) 2025/848, adopted on 6 May 2025. Registration specifies, per intended use, which attributes and attestations the relying party intends to request. The wallet checks each presentation request against this registered scope.
The EUDI Wallet can carry a wide range of verified attributes beyond a basic identity, including professional qualifications, age verification, health data, and employment records. Each of these attributes can feed into different authorization decisions depending on the service:
- A bank may use a verified age attribute to authorize access to certain financial products
- A healthcare provider may use a verified professional credential to authorize access to clinical systems
- A government portal may use a verified citizenship attribute to authorize access to specific public services
- An employer may use verified qualification data to authorize access to regulated workflows
This separation is deliberate by design. The wallet handles the identity side; the service handles the access side. Users retain control over which attributes they share, and they share only what is necessary for the specific interaction. This principle of selective disclosure is one of the core privacy protections built into the EUDI Wallet framework.
Why does mixing up authentication and authorization create compliance risks?
Mixing up authentication and authorization creates compliance risks because it leads organizations to either over-rely on identity verification as a substitute for proper access control, or to apply access decisions before identity has been properly confirmed. Both scenarios introduce vulnerabilities that regulators and auditors will flag.
Under eIDAS 2.0, organizations that accept electronic identification must respect the assurance level of the scheme used. If an organization treats a low-assurance authentication as sufficient for a high-risk transaction, it is not meeting the standard the regulation requires. Conversely, if an organization applies authorization rules before authentication is complete, it may expose sensitive resources to unverified users.
There are also downstream risks related to other regulations. GDPR requires that personal data is accessed only by those with a legitimate basis, and a relying party must have its own GDPR legal basis for processing the attributes it receives. AML and KYC frameworks require that customer identity is properly established before certain services are provided. PSD2 requires strong customer authentication for payment initiation. If the authentication step is weak, incomplete, or conflated with access control, the downstream compliance requirements built on top of it are also compromised.
A practical example: an organization that grants access to a regulated service based solely on a user presenting a credential, without verifying the assurance level of that credential or confirming it meets the required threshold, has effectively skipped authentication and jumped straight to authorization. That shortcut creates a compliance gap that is difficult to defend under audit. Organizations working in financial services or other regulated sectors face particularly high exposure here.
How should organizations design identity flows that separate the two?
Organizations should design identity flows so that authentication and authorization are handled as distinct, sequential stages with clear handoffs between them. This means defining what level of identity assurance is required for each service or transaction before building the flow, and then selecting authentication mechanisms that meet that requirement before any authorization logic is applied.
A well-structured identity flow typically follows this sequence:
- Define the assurance requirement: determine what level of identity confidence the service requires based on its risk profile and regulatory obligations
- Select the authentication method: choose an eID scheme, wallet-based authentication, or other mechanism that meets or exceeds that assurance level
- Verify the identity: complete the authentication step and receive cryptographically verified attributes
- Apply authorization rules: use the verified attributes to evaluate access policies, roles, and permissions
- Log and audit: maintain a complete record of both the authentication event and the authorization decision for compliance purposes
When verifying a presentation from a EUDI Wallet, a relying party should carry out three distinct checks: verifying the issuer’s signature against the relevant national trusted list, which is part of the EU List of Trusted Lists (LOTL); checking the revocation status of the attestation using the issuer’s status information; and validating the wallet unit attestation to confirm that the presenting wallet runs on a certified wallet solution. Only the first of these checks can take place fully offline.
Organizations should also avoid building systems where authentication and authorization are handled by the same component or where the boundary between them is unclear. Separation of concerns is not just good architecture; it makes compliance easier to demonstrate and audit trails easier to maintain. For organizations in sectors such as healthcare or government, where both identity assurance and access control carry regulatory weight, this separation is essential. It is also worth noting that for relying parties, registration under CIR (EU) 2025/848 remains connected to the applicable national registration framework, even where cross-border use cases are involved.
Reusable identity is another design principle worth building in. If a user has already been verified at the required assurance level elsewhere, a well-designed system can accept that verified credential rather than requiring the user to go through the process again. This is one of the key benefits the EUDI Wallet framework is designed to enable, and it reduces friction without compromising security. Organizations should plan for this capability progressively, in line with the phased rollout of certified and notified wallets across Member States, in the period leading up to and beyond 24 December 2026.
Public sector bodies are required to accept notified wallets for online services that require electronic identification from 24 December 2026. For relevant regulated private sectors, including banking and financial services, healthcare, telecoms, energy, transport, and digital services, the acceptance obligation under Article 5f applies from 24 December 2027. Micro and small enterprises, defined as organizations with fewer than 50 employees and an annual turnover or balance sheet total of no more than 10 million euros, are excluded from this obligation. Very large online platforms are subject to a separate provision under Article 5f, which requires them to accept wallet-based authentication where the platform requires user authentication, on the voluntary request of the user and limited to the minimum necessary data.
How TrustTech supports authentication and authorization in eIDAS 2.0
Getting the distinction between authentication and authorization right is both a technical and a strategic challenge. Organizations need to understand their regulatory obligations, design identity flows that meet them, and implement infrastructure that keeps both steps secure, auditable, and user-friendly.
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.
TrustTech builds and operates the ID Connector for organizations across financial services, healthcare, pharma, and government. In the context of authentication and authorization, the ID Connector specifically handles:
- Accepting presentation requests from every certified and notified EUDI Wallet, regardless of the issuing Member State
- Verifying issuer signatures against the relevant national trusted lists within the EU List of Trusted Lists (LOTL)
- Checking the revocation status of attestations using issuer-provided status information
- Validating wallet unit attestations to confirm that the presenting wallet runs on a certified wallet solution
- Enforcing the registered attribute scope so that only attributes covered by the relying party’s registration under CIR (EU) 2025/848 are processed
- Supporting reuse of verified identity data across multiple services without repeating the verification process
- Connecting identity verification and qualified signing via an integrated qualified trust service provider
Explore our identity solutions or get in touch to discuss your specific situation.