Compliance & Privacy · 2026-04-04

The EU Digital Identity Wallet and Carrier Signals: How eIDAS 2.0 Creates a New Compliance Surface

By J. W. Bouckaert

The regulation

Regulation (EU) 2024/1183, commonly called eIDAS 2.0, amends the 2014 eIDAS Regulation and entered into force on 20 May 2024. Article 5a requires each Member State to provide at least one European Digital Identity Wallet within 24 months of the entry into force of the implementing acts referred to in Article 5a(23) and Article 5c(6). The Commission adopted those acts, Implementing Regulations (EU) 2024/2977, 2024/2979, 2024/2980, 2024/2981 and 2024/2982, on 28 November 2024, and they entered into force on 24 December 2024. Wallets are therefore due by December 2026.

Using a wallet is voluntary for the user (Article 5a(15)), and issuance, use and revocation are free of charge for natural persons (Article 5a(13)).

For identity providers that use carrier signals, such as SIM swap checks and line type and carrier lookups, the Regulation changes who must accept wallets, how a relying party registers, and what data it may request. This article covers those rules, the assurance levels they refer to, where carrier signals sit next to a wallet, and what PasskeyBridge supports today.

The wallet

A wallet holds person identification data (PID) and electronic attestations of attributes. Under Article 5a(4), the user can present PID, combined with attestations where applicable, to relying parties online and, where appropriate, offline, "while ensuring that selective disclosure of data is possible". The wallet can also generate pseudonyms, keep a log of transactions with each relying party, and sign with qualified electronic signatures. Article 5a(5)(g) requires that every natural person can sign with a qualified electronic signature by default and free of charge, though Member States may limit free signing to non-professional purposes.

Article 5a(2) allows a wallet to be provided directly by a Member State, under a Member State mandate, or independently and recognised by a Member State. Article 5a(3) requires the source code of the application components to be open-source licensed. The European Commission publishes a reference implementation and the Architecture and Reference Framework (ARF), whose latest release is v3.0.0 (23 July 2026).

Formats and protocols in the ARF

OpenID4VP 1.0 was published as a final specification on 9 July 2025. Its query language is DCQL; the Presentation Exchange syntax of earlier drafts is not part of 1.0. OpenID4VCI 1.0 followed on 16 September 2025.

Mandatory acceptance

Article 5f sets three groups:

• Public sector bodies. Where a Member State requires electronic identification and authentication to access an online public service, it must also accept wallets (Article 5f(1)).
• Private relying parties required to use strong user authentication. Where Union or national law, or a contract, requires strong user authentication for online identification, including in transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications, the relying party must also accept wallets at the user's voluntary request, no later than 36 months after the entry into force of the implementing acts (Article 5f(2)). That is December 2027. Microenterprises and small enterprises are excluded.
• Very large online platforms. Platforms designated under Article 33 of the Digital Services Act that require user authentication must accept and facilitate wallets for authentication at the user's voluntary request, for the minimum data necessary for the service (Article 5f(3)).

Relying party registration

Article 5b requires a relying party that intends to rely on wallets to register in the Member State where it is established. The registration states at least:

• the Member State of establishment, the relying party's name and, where applicable, its registration number in an official record;
• contact details;
• the intended use of wallets, including the data the relying party will request.

A relying party may not request data beyond what it registered (Article 5b(3)). It must identify itself to the user (Article 5b(8)), is responsible for authenticating and validating the PID and attestations it receives (Article 5b(9)), and may not refuse pseudonyms where Union or national law does not require identification of the user. Article 5b(10) states that "intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction."

That last rule matters for any verification service that sits between a wallet and the business it serves. It is a legal reason, alongside the privacy reasons, to design the service so that it does not keep the presented data. PasskeyBridge's zero-PII architecture stores keyed digests rather than identity data.

Levels of assurance

The assurance levels low, substantial and high are defined for electronic identification means in Commission Implementing Regulation (EU) 2015/1502. For the design of the means, its annex sets these elements:

Article 5a(11) requires wallets to be provided under an electronic identification scheme at assurance level high, and Article 5a(5)(d) requires them to meet the Article 8 requirements for level high, including identity proofing.

These levels apply to electronic identification means. A carrier signal is not an electronic identification means and has no assurance level of its own. A SIM swap check reports an event on a phone line; it does not identify a person. It can be one input to a relying party's risk decision alongside a wallet presentation or a passkey, and the relying party decides how much weight to give it.

Carrier signals next to a wallet

Carrier signals come from carrier intelligence providers such as Twilio Lookup and Vonage. They are not attestations in the wallet's trust framework: they are not issued to the wallet, they are not on a trusted list, and the user does not present them. A relying party that uses both treats them as separate inputs.

Coverage in Europe is uneven. Twilio's SIM Swap package is in private beta, names nine countries, and needs carrier approval; see Carrier lookups from one provider for the fields each provider returns.

Combining the two requires a link between a wallet presentation and a phone line that does not expose the phone number or the PID. One way is a server-side record that holds a keyed digest of the phone number and a keyed digest of the credential subject, signed by the service and checked when either side is used again.

PasskeyBridge today

PasskeyBridge sells verified identity signals that other systems consume. It is not an identity provider and does not issue PID. The parts relevant to eIDAS 2.0 are:

• Carrier lookups. Each lookup asks one provider and returns that provider's answer. Phone numbers are keyed with HMAC-SHA-256 under a server-held pepper before storage.
• Verifiable Credentials. PasskeyBridge issues JWT VCs and SD-JWT credentials signed with ES256 (ES384 on the ML-DSA-87 tier) and a detached ML-DSA-65 or ML-DSA-87 proof. See hybrid signatures and selective disclosure.
• Cross-references. An Enterprise feature that links a carrier signal digest to a credential subject digest, with an optional passkey binding. See SIM signals and Verifiable Credentials.
• Presentation verification. The presentation endpoint verifies JWT presentations and matches them against Presentation Exchange 2.0 definitions. Its authorization request advertises the jwt_vp and jwt_vc formats.
• Revocation. PasskeyBridge publishes credential status as a W3C StatusList2021 bitstring.

PasskeyBridge does not yet accept DCQL queries, mdoc presentations or SD-JWT VC presentations from EUDI Wallets, and it does not publish IETF Token Status Lists. It is not an EUDI Wallet relying party today.

Post-quantum signatures

eIDAS 2.0 does not set a post-quantum algorithm requirement. The EU's Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, published in June 2025 by the NIS Cooperation Group, asks Member States to begin the transition by the end of 2026, to migrate high-risk use cases by the end of 2030, and to complete as much of the remaining migration as feasible by 2035.

A future quantum computer could forge ECDSA signatures, so an audit record signed only with ECDSA and kept for years could lose its value as evidence. PasskeyBridge signs every credential with an ML-DSA proof as well as an ECDSA signature, and signs cross-references with ML-DSA-65 for tenants with post-quantum signing enabled, so those records stay verifiable if ECDSA is broken. See the FIPS 204 architecture.

Engineering checklist for a relying party

1. Register. Register in the Member State of establishment and request only the data declared in the registration.
2. Support the ARF presentation protocols. OpenID4VP 1.0 with DCQL under HAIP for SD-JWT VC and mdoc credentials, and ISO/IEC 18013-7 where mdoc is used remotely.
3. Validate. Verify PID and attestations against the trusted lists and check their status lists.
4. Keep carrier signals separate. Record them as risk inputs, linked to a presentation only through keyed digests.
5. Store no presented data in intermediaries. Article 5b(10) forbids it.

Read about SIM signals and Verifiable Credentials Read about selective disclosure with SD-JWT Get started with PasskeyBridge

Start free · Test the API