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 builds on the original eIDAS regulation, which 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 clearly shifted toward portable, user-controlled credentials as the primary vehicle for identity data.
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 anyone receiving it to verify its authenticity without contacting the issuer directly. This makes it portable, privacy-preserving, 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 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 trusted registry, so the recipient can verify its origin.
- 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: Unlike a session token, a credential can remain valid for months or years, depending on the issuer’s policy.
This structure is what makes verifiable credentials so powerful for reusable compliance. A customer who has already been verified by their bank or employer can present that credential to a new organization without going through the full verification process again.
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’s 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. In other words, 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 rather than revealing everything at once.
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, eliminating the need for repeated KYC checks. 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. 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.
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.
For organizations building integrations with the EUDI Wallet, this layered model means they need to handle both. Relying parties must be able to validate verifiable credentials, including checking issuer signatures and trust registries, while also managing the token-based flow that governs how presentations are requested and confirmed. TrustTech’s identity solutions are designed to support exactly this kind of integration, bridging the gap between credential verification and session management in a compliant and practical way.
How TrustTech helps with tokens and credentials in eIDAS 2.0
Understanding the difference between a token and a credential is one thing. Building systems that handle both correctly, in a way that is compliant with eIDAS 2.0 and ready for the EUDI Wallet, is another challenge entirely. That is where TrustTech comes in.
TrustTech provides the infrastructure and expertise to help organizations move from fragmented, session-based identity flows to a modern, credential-first architecture. Whether you are a financial institution preparing for reusable KYC, a healthcare organization managing professional credentials, or a government body issuing identity attestations, TrustTech supports the full journey. Explore how organizations in your sector are approaching this on the TrustTech customers page.
Specifically, TrustTech helps organizations with:
- Issuing and verifying verifiable credentials in formats compatible with eIDAS 2.0 and the EUDI Wallet
- Integrating credential-based identity flows into existing onboarding and compliance processes
- Enabling reusable identity so customers verify once and share securely across multiple touchpoints
- Connecting credential verification with qualified digital signatures for a complete, auditable identity chain
- Supporting regulated sectors such as financial services and healthcare with sector-specific implementation expertise
The transition to eIDAS 2.0 does not have to be complicated. With the right partner, you can build a digital identity infrastructure that is secure, interoperable, and ready for what comes next. Get in touch with TrustTech to discuss how we can help your organization make the move.