Under eIDAS 2.0, a revoked digital credential immediately loses its validity, and any relying party that checks its status will receive a signal indicating that it can no longer be trusted. Revocation is a core part of how the European Digital Identity (EUDI) Wallet ecosystem maintains integrity: it ensures that credentials issued to users can be invalidated when circumstances change, whether due to data errors, legal requirements, or a user’s own request. The sections below walk through how revocation works in practice, who controls it, and what organizations need to do to be ready.

What happens when a digital credential is revoked under eIDAS 2.0?

When a digital credential is revoked under eIDAS 2.0, it is marked as invalid in a credential status registry maintained by the issuing authority. From that moment on, any verification attempt will return a negative status result. The credential may still be stored in the user’s EUDI Wallet, but it will be flagged as revoked and should not be accepted by relying parties for authentication or authorization purposes.

The practical effect depends on the type of credential and the service relying on it. A revoked qualification credential, for example, would prevent someone from accessing a regulated service that requires proof of that qualification. A revoked identity attestation would block re-authentication flows that depend on it. Importantly, revocation does not automatically delete the credential from the wallet. The user retains the data, but its trustworthiness is gone from the perspective of verifiers.

This distinction matters for organizations designing verification workflows. A system that only checks whether a credential exists is not sufficient. It must also verify that the credential is currently valid, which means querying the credential’s status at the time of each verification.

What revocation mechanisms does eIDAS 2.0 support?

eIDAS 2.0 supports two primary revocation mechanisms for verifiable credentials: Status List (also referred to as Bitstring Status List) and OCSP-style real-time status queries. The Architecture and Reference Framework (ARF) developed by the eIDAS Expert Group outlines how these mechanisms apply to credentials issued within the EUDI Wallet ecosystem, with a strong preference for privacy-preserving approaches.

The Bitstring Status List approach works by embedding a reference to a published list within the credential itself. This list contains a compact, encoded representation of the revocation status of many credentials at once. A verifier downloads the list and checks the relevant entry without needing to query a server for each individual credential. This reduces latency and, when implemented correctly, limits the ability of issuers to track when and where credentials are being verified.

Real-time status queries, by contrast, involve the verifier contacting a status endpoint directly at the moment of verification. This provides up-to-the-second accuracy but introduces privacy risks, since the issuer can observe verification events. The eIDAS 2.0 framework acknowledges both methods and leaves room for implementation choices, but privacy considerations heavily influence which approach is recommended in practice.

Who can revoke a credential in the EUDI Wallet ecosystem?

In the EUDI Wallet ecosystem, the credential issuer is the primary party with the authority to revoke a credential. This is typically a government body, a qualified trust service provider, or another authorized organization that originally issued the attestation. The issuer controls the status registry and can update a credential’s status at any time.

However, eIDAS 2.0 also gives users meaningful rights over their own data. A user can request the revocation or deletion of a credential, particularly when the data is no longer accurate or when they withdraw consent. This aligns with the broader data protection principles embedded in the regulation, including the right to erasure under GDPR.

In some scenarios, a regulatory authority or supervising body may also trigger revocation, for instance when a professional license is withdrawn or a legal status changes. The key point for organizations to understand is that revocation authority is not a single, centralized function. It can originate from the issuer, the user, or a regulatory actor, and systems must be capable of handling updates from any of these sources promptly.

How do relying parties check whether a credential has been revoked?

Relying parties check credential revocation status by reading the status reference embedded in the credential itself and then querying the corresponding status endpoint or downloading the relevant status list. This process is typically automated within the verification software or SDK used by the relying party. The result is a simple valid or revoked signal that the application logic can act on.

For organizations building or procuring verification systems, this means two things need to be in place:

1. Status checking must be integrated into every verification flow, not just at the point of onboarding but at each subsequent interaction that relies on the credential.
2. The verification infrastructure must be capable of resolving status list URIs or querying status endpoints in real time, which requires reliable connectivity and up-to-date software libraries.

Relying parties should also consider how frequently they refresh cached status lists. A list downloaded once per day may be sufficient for low-risk use cases, but higher-stakes scenarios, such as financial transactions or access to sensitive healthcare data, may require fresher status checks to reduce the window of risk between revocation and detection.

What are the privacy implications of credential revocation checks?

Credential revocation checks carry real privacy risks if not implemented carefully. The core concern is that every time a verifier queries a status endpoint for a specific credential, the issuer can potentially observe that the credential is being used, by whom, and in what context. This creates a form of surveillance that undermines the user sovereignty principles at the heart of eIDAS 2.0.

The Bitstring Status List approach addresses this by allowing verifiers to download a large batch list rather than querying individual credentials. Because the list covers many credentials at once, the issuer cannot easily determine which specific credential is being checked at any given moment. This is sometimes called herd privacy: the individual is protected by being indistinguishable within the crowd.

Organizations that handle personal data through credential verification should also consider their obligations under GDPR. Logging revocation check results, retaining status data, or linking verification events to individual profiles may require a lawful basis and appropriate retention limits. Financial services organizations and healthcare providers in particular need to align their credential verification practices with their existing data protection frameworks, since both sectors handle especially sensitive personal information.

What should organizations do to prepare their systems for eIDAS 2.0 revocation requirements?

Organizations should start by auditing their current identity verification infrastructure to identify gaps in credential status handling. Most legacy systems were not designed with dynamic revocation checking in mind, and integrating this capability often requires changes at both the technical and process level.

Key preparation steps include:

• Review your credential verification flows to confirm that status checks are performed at every relevant touchpoint, not just at initial onboarding.
• Evaluate your status checking method and whether it meets the privacy requirements set out in the eIDAS 2.0 framework and the ARF.
• Update your data governance policies to clarify how revocation status data is stored, retained, and used in line with GDPR.
• Test your systems against revoked credentials to confirm that your application correctly rejects them and handles the user experience gracefully.
• Stay aligned with the ARF and technical specifications, which continue to evolve as the EUDI Wallet ecosystem matures.

Organizations in government services and regulated industries should also engage with the large-scale pilot outcomes and technical guidance emerging from the European Commission to ensure their implementations reflect real-world testing. The resources available from digital identity specialists can help teams translate these technical specifications into practical implementation roadmaps.

How TrustTech helps with eIDAS 2.0 credential revocation

Credential revocation is one of the more technically demanding aspects of eIDAS 2.0 compliance, and getting it right requires both deep regulatory knowledge and solid implementation expertise. TrustTech supports organizations at every stage of this process, from initial gap analysis through to production-ready systems.

Specifically, TrustTech helps organizations with:

• Assessing current verification infrastructure against eIDAS 2.0 and ARF requirements for credential status handling
• Implementing privacy-preserving revocation mechanisms such as Bitstring Status List, aligned with the EUDI Wallet technical specifications
• Integrating credential status checks into onboarding, authentication, and signing workflows across the full identity lifecycle
• Aligning data governance practices with both eIDAS 2.0 and GDPR obligations around revocation data
• Supporting cross-sector use cases in finance, government, healthcare, and beyond, where revocation requirements intersect with sector-specific compliance obligations

TrustTech’s platform is built on European digital identity standards and designed to be eIDAS 2.0 ready from the ground up, so organizations don’t have to retrofit compliance onto systems that were never designed for it. If your organization is working through the implications of credential revocation and wants practical, expert guidance, get in touch with TrustTech to discuss your specific situation.