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 regulatory catalyst

On 20 May 2024, the revised Regulation (EU) 2024/1183—commonly known as eIDAS 2.0—entered into force. It replaced the 2014 eIDAS framework with a mandate that has no historical precedent in digital identity: every EU Member State must offer a government-backed digital identity wallet to every citizen, resident, and business entity by May 2027.

This is a binding legal obligation, not an opt-in pilot or a sandbox experiment. It will reshape how 450 million people authenticate online—and, critically, how identity service providers outside the EU must adapt if they serve European users or process European identity data.

For organizations that rely on carrier signals—SIM-swap detection, number-portability checks, device-continuity attestations—the EUDI Wallet mandate creates an entirely new compliance surface. The Architecture Reference Framework (ARF) published by the European Commission defines specific Level of Assurance (LoA) requirements that directly intersect with SIM-based verification methods. Understanding that intersection is a prerequisite for operating in the European identity ecosystem post-2027.

The EUDI Wallet

The EU Digital Identity Wallet (EUDI Wallet) is a mobile application—issued or certified by each Member State—that stores three categories of digital credentials:

1. Person Identification Data (PID): Legal name, date of birth, nationality, and a unique persistent identifier—issued by the Member State under ISO/IEC 18013-5 and mdoc CBOR encoding, or as SD-JWT VCs per the ARF v1.4.0 specification.

1. Qualified Electronic Attestations of Attributes (QEAAs): Credentials issued by Qualified Trust Service Providers (QTSPs)—driver's licenses, professional certifications, health insurance cards, bank account ownership attestations.

1. Qualified Electronic Signatures (QES): Legally binding electronic signatures equivalent to handwritten signatures under Article 25(2) of the original eIDAS Regulation.

The wallet itself is not a single application. The European Commission's reference implementation is open source, but each Member State may deploy its own variant using the common ARF protocols. What matters for identity providers is the interoperability layer: the protocols that the ARF mandates for credential issuance, presentation, and verification.

The protocol stack

The key insight for carrier-signal providers is that OpenID4VP is the gateway protocol. Any relying party—bank, telecom, government agency, or identity verification platform—must accept credential presentations through OpenID4VP. And any supplementary identity signal (including carrier attestations) must either be encoded as a verifiable attestation within this protocol or operate alongside it in a manner that the ARF recognizes.

Levels of assurance: Where carrier signals fit

The ARF inherits the three-tier Level of Assurance (LoA) framework from Commission Implementing Regulation (EU) 2015/1502, which maps directly to ISO/IEC 29115:

This mapping reveals a critical regulatory boundary: carrier signals are naturally LoA Substantial, but they cannot independently achieve LoA High.

LoA High

The ARF specifies that certain use cases require LoA High:

• Opening a bank account under PSD2 Strong Customer Authentication (SCA)
• Accessing electronic health records under the European Health Data Space (EHDS) Regulation
• Signing contracts with legal equivalence to handwritten signatures
• Cross-border access to government services (e.g., tax filing, social security)
• Age verification for regulated products under the Digital Services Act

For identity platforms that currently rely on SIM-based verification as their primary or sole signal, the eIDAS 2.0 mandate creates a binary choice: remain at LoA Substantial and forfeit high-assurance use cases, or architect the binding layer that elevates carrier signals into an LoA High-compliant multi-factor stack.

Binding a carrier attestation to a wallet credential

The core technical challenge is binding: how do you cryptographically connect a carrier-signal attestation (e.g., "this SIM has not been swapped in the last 72 hours") to a EUDI Wallet credential (e.g., "this person is Maria García, born 15 March 1988, PID issued by Spain")?

The ARF's Trust Model requires that every attestation presented through OpenID4VP be signed by a recognized issuer—either a Member State PID provider or a Qualified Trust Service Provider. Carrier signals, by their nature, are not issued by QTSPs. They are real-time network queries returned by mobile network operators (MNOs) or aggregators like Twilio, Vonage, or Sinch.

This creates an architectural gap that the ARF does not explicitly address—but that identity providers must resolve:

┌─────────────────────────────────────────────────────────────┐
│                     LoA High Transaction                     │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Factor 1: EUDI Wallet PID         (Qualified Attestation)  │
│  Factor 2: WebAuthn Passkey         (Biometric Binding)      │
│  Factor 3: Carrier Signal           (Device Continuity)      │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  BINDING LAYER                                        │   │
│  │  ─────────────────────────────────────────────────── │   │
│  │  PID Subject Hash ←→ SIM Signal Hash ←→ Passkey ID  │   │
│  │  Cross-reference proof: SHA-256(pid:sim:passkey)     │   │
│  │  Signed by: Hybrid PQC (ES256 + ML-DSA-65)        │   │
│  └──────────────────────────────────────────────────────┘   │
│                                                              │
└─────────────────────────────────────────────────────────────┘

The binding layer must satisfy four properties:

1. Zero-PII linkage: The cross-reference must prove correlation without revealing the underlying identity data. The carrier signal contains a phone number hash; the PID contains a subject identifier hash. The binding proves they refer to the same person without exposing either value.

1. Temporal proximity: The carrier signal and the PID presentation must occur within a defined time window. A SIM-swap check from 48 hours ago does not provide meaningful assurance for a real-time LoA High transaction.

1. Signature independence: The binding proof must be signed with a scheme that remains valid under post-quantum threat models. The Harvest Now, Decrypt Later risk applies directly to binding proofs that will be stored in audit logs for regulatory retention periods of 5–10 years.

1. Revocation alignment: If the PID is revoked (e.g., the citizen reports their wallet compromised), the carrier-signal binding must be invalidated in real-time. This requires integration with the ARF's Status List 2021 revocation mechanism.

ARF requirements for relying parties

The ARF (current release v2.9.0, May 2026) specifies concrete technical requirements that any relying party (RP) must implement to accept EUDI Wallet credentials. For identity providers that augment wallet presentations with carrier signals, these requirements compound:

Relying party registration

Under Article 5b of the revised eIDAS Regulation, every relying party must:

• Register with a Relying Party Registry maintained by the Member State
• Declare which attestation types and attributes it will request
• Publish its authentication policy, including which LoA level it requires
• Accept credentials from all Member State EUDI Wallets (no cherry-picking)

For an identity provider that also queries carrier signals, the registration must declare the carrier-signal attestation as a supplementary factor—not as a replacement for the EUDI Wallet PID.

Selective disclosure

The ARF mandates selective disclosure as a core privacy principle. A relying party cannot request the user's full PID if it only needs to verify their age. The SD-JWT VC format implements this through salted hash disclosure:

The selective-disclosure requirement has direct implications for how carrier signals are bound to PID attributes. The binding cannot reference the full phone number or the full legal name—it must operate on the same hash-level abstraction that the SD-JWT VC format uses for its disclosures.

This is where a zero-PII architecture stops being a privacy best practice and becomes a regulatory requirement.

Timeline

The eIDAS 2.0 compliance timeline is staggered, but the milestones are non-negotiable:

For identity providers serving European customers today, the critical window is Q2 2026 through May 2027. This is when cross-border interoperability testing begins, and when the practical gaps between carrier-signal attestations and ARF requirements will surface in production environments.

The PQC imperative in eIDAS 2.0

The original eIDAS Regulation was cryptographically conservative—it relied on RSA and ECDSA for qualified electronic signatures. The revised Regulation introduces, for the first time, an explicit acknowledgment of the quantum threat.

Recital 16 of the revised Regulation states:

"In order to keep pace with technological developments, including developments in quantum computing, the Commission should be empowered to adopt delegated acts to update the technical standards..."

This is not merely aspirational language. The European Commission has tasked ENISA (the EU Agency for Cybersecurity) with publishing post-quantum cryptography recommendations for the EUDI Wallet ecosystem. ENISA's 2024 report on PQC migration explicitly recommends hybrid signature schemes for high-assurance use cases—precisely the approach that FIPS 204 (ML-DSA) standardizes.

For carrier-signal binding proofs that will be stored in audit logs for regulatory retention periods, the PQC requirement is particularly acute. A binding proof signed today with ECDSA alone could be retroactively forged by a CRQC within the retention period, invalidating the regulatory compliance artifact. Hybrid signatures (ES256 + ML-DSA-65) eliminate this risk by ensuring that at least one of the two signatures remains quantum-resistant throughout the entire retention lifecycle.

Cross-border complexity: 27 Member States, one protocol, zero uniformity

The ARF specifies a common protocol layer (OpenID4VCI, OpenID4VP, SD-JWT VC), but it does not—and cannot—mandate uniform implementation across all 27 Member States. This creates practical challenges for carrier-signal providers that operate across borders:

MNO fragmentation

The European telecommunications market is served by over 100 mobile network operators across 27 Member States. Carrier-signal intelligence APIs from aggregators like Twilio, Vonage, and Sinch normalize this fragmentation to some extent, but significant gaps remain:

When a French citizen uses their EUDI Wallet in Germany while roaming on a German MNO, the carrier-signal provider must resolve a three-way trust problem:

1. The PID was issued by France (Member State A)
2. The device is connected to a German MNO (Member State B)
3. The relying party might be headquartered in the Netherlands (Member State C)

The binding proof must be valid across all three jurisdictions, using the ARF's common trust framework, without leaking the subscriber's phone number, IMSI, or location to any party that does not have a lawful basis under GDPR Article 6 to process it.

This is precisely the scenario that carrier signal chaining was designed to address—correlating multi-MNO events across roaming boundaries without logging the underlying identifiers.

Five engineering requirements

The compliance surface that eIDAS 2.0 creates for carrier-signal-based identity providers can be decomposed into five concrete engineering requirements:

1. OpenID4VP relying party implementation

Accept EUDI Wallet credential presentations via OpenID4VP, including SD-JWT VC format parsing, selective disclosure verification, and Presentation Exchange 2.0 matching. OpenID4VP is the only protocol the ARF recognizes for remote credential presentation, so this item is mandatory.

2. Carrier-signal attestation encoding

Encode carrier-signal results (SIM-swap status, number-portability checks, device-continuity scores) as machine-verifiable attestations that can be presented alongside EUDI Wallet credentials. The attestation format must support selective disclosure and hash-level binding.

3. Cross-reference binding layer

Implement a cryptographic binding between the PID subject identifier hash, the carrier-signal phone hash, and the WebAuthn passkey credential ID. This binding must use zero-PII architecture principles—no plaintext identifiers, no reversible hashes, no PII stored at rest.

4. Hybrid PQC signature infrastructure

Sign all binding proofs and attestations with hybrid signatures (classical + post-quantum) to satisfy ENISA's PQC recommendations and ensure that audit artifacts remain valid throughout their regulatory retention period. ML-DSA-65 provides NIST Level 3 security; ML-DSA-87 is available for LoA High use cases requiring Level 5.

5. Real-time revocation integration

Integrate with the ARF's revocation mechanism (Status List 2021) so that carrier-signal binding proofs are invalidated when the underlying PID or attestation is revoked. This requires polling or webhook-based integration with each Member State's revocation endpoint.

The market implication

The eIDAS 2.0 mandate does not eliminate the need for carrier signals in identity verification. If anything, it elevates their importance by defining a clear regulatory framework in which carrier signals serve as one factor in a multi-factor, multi-assurance-level authentication stack.

But it does eliminate the option of treating carrier signals as a standalone identity solution for European users. The days of "we verified the phone number, therefore we verified the person" are ending—replaced by a framework that demands cryptographic binding, selective disclosure, cross-border interoperability, and post-quantum resilience.

Identity providers that begin building the EUDI Wallet integration layer today—OpenID4VP acceptance, PID binding, hybrid PQC signatures, revocation integration—will have a 12-month head start on the compliance deadline. Those that wait until 2027 will be scrambling to retrofit a fundamentally different architecture onto systems that were designed for a world where a SIM card was proof enough.

The compliance surface is new. The engineering requirements are clear. The deadline is fixed.

Build accordingly.

Start free · Test the API