Under eIDAS 2.0, which amends Regulation (EU) 910/2014, 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 attestation, 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. 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 real-time status queries. The Architecture and Reference Framework (ARF) provides the technical elaboration of how these mechanisms apply to credentials issued within the EUDI Wallet ecosystem, with a strong preference for privacy-preserving approaches. The legally binding requirements are set out in the implementing acts adopted by the European Commission; the ARF elaborates on those requirements at a technical level.
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 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?
Revocation authority in the EUDI Wallet ecosystem is distributed across several actors. The credential issuer, typically a government body, a qualified trust service provider, or another authorized organization that originally issued the attestation, is the primary party with the authority to revoke a credential. 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 national competent authority or supervising body may also trigger revocation, for instance when a professional license is withdrawn or a legal status changes. EU Member States supervise actors within their jurisdiction and play a role in ensuring that issuers and wallet providers operate within the applicable rules. Revocation authority 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 valid or revoked signal that the application logic can act on.
Verification of an attestation involves three distinct checks:
- Verification of the issuer’s signature against the relevant national trusted list, which forms part of the EU List of Trusted Lists (LOTL). This is the only check that can be performed fully offline.
- Revocation status check via the issuer’s status information, which requires connectivity to the status endpoint or a recently downloaded status list.
- Validation of the wallet unit attestation to confirm that the presenting wallet runs on a certified wallet solution.
For organizations building or procuring verification systems, two things need to be in place:
- Status checking must be integrated into every verification flow, at the point of onboarding and at each subsequent interaction that relies on the credential.
- 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. Relying parties must also register with the national authority of their Member State of establishment under CIR (EU) 2025/848 of 6 May 2025, specifying per intended use which attributes and attestations they will request. Organizations operating across borders should account for national registration requirements in addition to the European-level technical specifications.
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, at initial onboarding and at each subsequent interaction.
- Evaluate your status checking method and whether it meets the privacy requirements set out in the eIDAS 2.0 implementing acts and elaborated in 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 review the outcomes of the large-scale pilots that ran from April 2023 to 2025 and the technical guidance emerging from the European Commission to ensure their implementations reflect real-world testing. The legal deadline for Member States to issue wallets and for public bodies to accept them is 24 December 2026. The obligation for relevant regulated private sector organizations, including banks, financial services providers, and healthcare providers, to accept the EUDI Wallet applies from 24 December 2027 under Article 5f of the regulation. These are legal deadlines, and practical interoperability and national rollout are expected to develop in phases. Organizations should plan accordingly.
How the ID Connector supports eIDAS 2.0 credential revocation
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.
In the context of credential revocation, the ID Connector handles several of the technical functions that organizations need to get right:
- Revocation status checking integrated into every verification flow, covering both Bitstring Status List resolution and real-time status endpoint queries
- Issuer signature verification against national trusted lists as published in the EU List of Trusted Lists (LOTL)
- Wallet unit attestation validation to confirm that the presenting wallet instance runs on a certified wallet solution
- Registered attribute scope enforcement to ensure that data requests stay within the scope registered under CIR (EU) 2025/848
- Cross-sector applicability in financial services, healthcare, government, and pharma, where revocation requirements intersect with sector-specific compliance obligations
If your organization is working through the technical and compliance implications of credential revocation under eIDAS 2.0, get in touch with TrustTech to discuss how the ID Connector fits your situation.