A token and a credential are not the same thing in eIDAS 2.0, even though both carry identity-related information. A credential is a structured, verifiable claim about a person or organization, such as a diploma or a verified address. A token is a short-lived technical object used to prove that a session or authentication event has taken place. Understanding the difference matters because eIDAS 2.0 and the European Digital Identity Wallet treat them as distinct building blocks with different purposes, lifespans, and trust levels. The sections below unpack each concept and explain how they work together in practice.
How are tokens and credentials used in eIDAS 2.0?
In eIDAS 2.0, credentials and tokens serve complementary but separate roles. Credentials are used to carry verified identity attributes, such as a person’s name, nationality, or professional qualification, in a format that can be cryptographically checked. Tokens are used to authorize access to a service or to confirm that a user has successfully authenticated during a specific session. Together, they form the backbone of trusted digital interactions under the regulation.
eIDAS 2.0, formally Regulation (EU) 2024/1183, amends Regulation (EU) 910/2014. The original regulation focused primarily on cross-border recognition of national electronic identity schemes. The updated framework goes further by introducing the European Digital Identity Wallet, which allows citizens and businesses to store and present verifiable credentials directly. Tokens still play a role, particularly in the underlying protocols that connect wallets to relying parties, but the emphasis has shifted toward portable, user-controlled credentials as the primary vehicle for identity data.
The EUDI Wallet framework involves a range of actors, each with distinct responsibilities. The European Commission manages the legal framework and adopts implementing acts that contain legally binding requirements. EU Member States provide or mandate wallet solutions, certify and notify them, and supervise actors within their jurisdiction. The European Digital Identity Cooperation Group supports cross-border alignment and cooperation. National competent authorities, wallet providers, issuers of Person Identification Data and attestations, qualified trust service providers, and relying parties each carry specific obligations within this shared governance structure. No single central European authority operationally manages all EUDI Wallets. The Architecture and Reference Framework provides the technical elaboration of the requirements set out in the implementing acts; it is not itself legislation.
For organizations in regulated sectors such as finance, government, and healthcare, this distinction has real operational implications. Compliance processes that previously relied on session-based tokens for authentication may now need to accommodate credential-based identity flows that carry richer, reusable data.
What exactly is a verifiable credential in eIDAS 2.0?
A verifiable credential in eIDAS 2.0 is a digitally signed statement issued by a trusted authority that asserts one or more facts about a person or organization. The credential contains the claim itself, information about the issuer, and a cryptographic proof that allows a recipient to verify its authenticity. Full offline verification is possible only for the issuer signature check against the relevant national trusted list; checking revocation status and validating the wallet unit attestation require access to additional information from the issuer or the wallet solution. This makes the credential portable and tamper-evident.
Common examples of verifiable credentials in the eIDAS 2.0 context include a government-issued identity attestation, a university diploma, a professional licence, or a European Health Insurance Card. Each of these can be stored in the EUDI Wallet and presented selectively to a service provider, sharing only the attributes that are actually needed for a given transaction.
The key properties that define a verifiable credential are:
- Issuer trust: The credential is signed by an entity listed on a national trusted list, so the recipient can verify its origin. National trusted lists are brought together in the EU List of Trusted Lists (LOTL).
- Selective disclosure: The holder can choose to reveal only specific attributes, for example confirming they are over 18 without sharing their exact date of birth.
- Portability: The credential lives in the user’s wallet and can be presented to any compatible relying party, not just the organization that originally verified the data.
- Longevity: A credential can remain valid for months or years, depending on the issuer’s policy, in contrast to a session token that expires within minutes or hours.
This structure is what makes verifiable credentials well suited for reusable compliance. A customer who has already been verified by their bank or employer can present that credential to a new organization. Whether that presentation satisfies a KYC obligation at the receiving organization depends on applicable AML legislation, not on eIDAS 2.0 itself.
What is a token in the context of digital identity?
In digital identity, a token is a short-lived, machine-readable object that represents the outcome of an authentication or authorization event. It does not describe who someone is in a rich, portable sense. Instead, it tells a system that a specific user has successfully authenticated within a specific session and is permitted to access a specific resource. Tokens are typically generated by an identity provider and consumed by a service within minutes or hours.
The most common types of tokens in digital identity systems are access tokens and ID tokens, both associated with the OpenID Connect and OAuth 2.0 protocols. An access token grants permission to call an API or access a protected resource. An ID token confirms the identity of the user who authenticated, often including a small set of attributes such as a user identifier or email address.
Tokens are not designed to be stored long-term or reused across organizations. They expire, they are bound to a specific session context, and they are not cryptographically tied to the user in the same way a verifiable credential is. This makes them well suited for session management but poorly suited for scenarios where a person needs to prove a verified claim to multiple parties over time.
What is the difference between an SD-JWT and a verifiable credential?
An SD-JWT (Selective Disclosure JSON Web Token) is a specific technical format used to encode a verifiable credential in a way that supports selective disclosure. The difference is one of abstraction: a verifiable credential is the conceptual object, the signed claim about a person or entity, while an SD-JWT is one of the data formats used to represent and transmit that credential. An SD-JWT is a type of verifiable credential format, not a separate concept.
eIDAS 2.0 and the EUDI Wallet architecture support multiple credential formats, with SD-JWT VC (Verifiable Credentials using SD-JWT) and mdoc (mobile document, used for mobile driving licences and similar documents) being the two primary formats referenced in the Architecture and Reference Framework. Both formats allow the holder to disclose only selected attributes from the credential. For proximity presentation, the relevant standard is ISO/IEC 18013-5; for online presentation, ISO/IEC TS 18013-7 applies. Credentials are issued using OID4VCI and presented using OID4VP.
The SD-JWT format is particularly relevant for organizations building relying party integrations because it is based on widely used web standards, making it relatively straightforward to implement in existing systems. It uses JSON Web Token conventions that many developers already know, with an added layer that allows certain claims to be hidden from a verifier unless the holder explicitly chooses to reveal them.
For practical purposes, when someone refers to an SD-JWT in the context of eIDAS 2.0, they are almost always referring to a verifiable credential encoded in that format, not a traditional session token. The word JWT in the name can cause confusion, but the use case and trust model are fundamentally different from an OAuth access token or ID token.
When should an organization issue a credential versus rely on a token?
An organization should issue a credential when the verified information needs to be portable, reusable, and trusted by third parties over time. It should rely on a token when it only needs to manage a user’s access within its own systems during a single session. The right choice depends on whether the data needs to travel beyond the organization that originally verified it.
Consider these scenarios to illustrate the distinction:
- Opening a bank account: The bank verifies the customer’s identity and could issue a verifiable credential. That credential can then be presented to other financial institutions or service providers. Whether this satisfies a KYC obligation at the receiving organization is governed by AML legislation. A session token alone cannot serve this purpose.
- Logging into an internal portal: An employee authenticates with their corporate identity provider and receives an access token. The token grants access to internal tools for that session. There is no need for a portable credential here.
- Proving a professional qualification: A healthcare professional needs to demonstrate their registration to multiple hospitals or clinics across borders. A verifiable credential issued by the relevant authority and stored in their EUDI Wallet is the appropriate mechanism. Recognition of professional qualifications across Member States remains subject to Directive 2005/36/EC. A token would expire before the second use.
- Completing a payment authorization: A user initiates a payment, and the system generates a short-lived token to authorize the transaction. This is a token use case, not a credential use case.
The general principle is this: if the verified claim needs to outlive a single session, cross organizational boundaries, or be controlled by the user rather than the issuing system, a verifiable credential is the right tool. If the goal is simply to manage access within a session, tokens remain the appropriate and efficient choice.
How do tokens and credentials interact inside the EUDI Wallet?
Inside the EUDI Wallet, tokens and credentials work together in a layered architecture. The wallet stores verifiable credentials long-term, but when a user presents a credential to a relying party, the underlying protocols often generate short-lived tokens as part of the exchange. The credential carries the identity data; the token handles the authorization mechanics of the presentation flow.
When a user wants to share an attribute from their wallet with a service provider, the process typically works as follows. The relying party sends a presentation request to the wallet. The wallet asks the user for consent to share specific attributes. The wallet then generates a cryptographically signed response that includes the relevant credential data. In many protocol implementations, this response is wrapped in or accompanied by a token that the relying party can validate to confirm the exchange was legitimate and recent.
Verifying a credential presentation involves three distinct checks. First, the relying party verifies the issuer’s signature against the relevant national trusted list, a step that can be performed offline. Second, the relying party checks the revocation status of the credential using status information provided by the issuer, which requires a connection to that information. Third, the relying party validates the wallet unit attestation to confirm that the presenting wallet runs on a certified wallet solution. Only the first of these checks can be completed fully offline.
This means that even in a credential-first architecture like the EUDI Wallet, tokens do not disappear entirely. They shift from being the primary carrier of identity information to being a supporting mechanism for secure, time-bound presentation events. The credential remains the source of truth about the user’s attributes, while the token ensures that the presentation is fresh, consented to, and bound to the correct session.
Cross-border use of EUDI Wallet credentials does not mean that national registration requirements or sector-specific legislation disappear. The framework is designed so that a certified wallet from one Member State can be used with an appropriate relying party in another Member State, but which use cases are available, and when, will depend on national rollout progress, relying party registration under CIR (EU) 2025/848, and the maturity of each Member State’s implementation. The legal deadline for Member States to make wallets available and for public bodies to accept them is 24 December 2026. Private relying parties in regulated sectors are subject to the acceptance obligation under Article 5f from 24 December 2027. Practical interoperability and national rollout are expected to develop in phases.
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 covers the intended use and specifies which attributes and attestations the relying party is permitted to request. The wallet validates incoming requests against this registered scope. A relying party must be able to accept every relevant notified wallet, regardless of which provider issued it.
For organizations building integrations with the EUDI Wallet, this layered model means they need to handle both credential verification and token-based presentation flows. Relying parties must be able to validate verifiable credentials, including checking issuer signatures against national trusted lists and managing revocation and wallet unit attestation checks, while also managing the token-based flow that governs how presentations are requested and confirmed.
How the ID Connector supports tokens and credentials in eIDAS 2.0
Building systems that handle both tokens and credentials correctly, in a way that is compliant with eIDAS 2.0 and ready for the EUDI Wallet, involves managing credential format validation, trust list lookups, revocation checks, wallet unit attestation validation, and registered attribute scope enforcement alongside the session-level token flows that govern each presentation event.
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.
Specifically, the ID Connector handles:
- Accepting and validating verifiable credentials in SD-JWT VC and mdoc formats, as referenced in the Architecture and Reference Framework
- Verifying issuer signatures against national trusted lists brought together in the EU List of Trusted Lists
- Checking credential revocation status using issuer-provided status information
- Validating wallet unit attestations to confirm that presenting wallets run on certified wallet solutions
- Enforcing the attribute scope registered by the relying party under CIR (EU) 2025/848
- Managing the OID4VP-based presentation flow, including the short-lived tokens that accompany each presentation event
- Supporting qualified signing via a connected qualified trust service provider
- Enabling reuse of verified identity data across onboarding and compliance processes in financial services, healthcare, pharma, and government
Organizations in financial services, healthcare, pharma, and government can find sector-relevant information on the TrustTech customers page. To discuss how the ID Connector fits your integration, get in touch with TrustTech.