eIDAS 2.0 — formally Regulation (EU) 2024/1183 amending the original eIDAS Regulation — creates the legal basis for the European Digital Identity Wallet and, more importantly for most companies, a set of concrete obligations for organisations that rely on identity checks. Unlike GDPR, which is a general-purpose regulation, eIDAS 2.0 has staged deadlines, named-sector obligations, and a supervision structure that mirrors financial services regulation more than data protection law. If your business ever asks a customer to prove who they are, this regulation now has an opinion about how.
What eIDAS 2.0 actually changes
The original eIDAS Regulation (2014) governed electronic signatures and trust services between public administrations. eIDAS 2.0 adds a citizen- and business-facing layer on top: the EUDI Wallet, a catalogue of attestation types (PID, QEAA, EAA), and — critically — a legal obligation for certain categories of private-sector service providers to accept wallet-based identification when they already perform identity verification.
- It defines the wallet as a public good every Member State must provide, free of charge, to its residents.
- It creates a European Trust List of issuers and Relying Parties, verifiable in real time.
- It mandates acceptance by specific sectors rather than leaving adoption to the market.
- It introduces Relying Party registration as a legal precondition to requesting attributes from a wallet.
The compliance timeline
The dates that matter for a business roadmap, not a legal footnote:
- 2024 — Regulation (EU) 2024/1183 enters into force; the Architecture and Reference Framework (ARF) and implementing acts are progressively adopted.
- By late 2026 — each Member State must have at least one EUDI Wallet available to residents.
- From 2027 — mandatory acceptance kicks in for the named sectors (see below), with national supervisory bodies enforcing conformity.
- Ongoing — implementing acts on certification, security and interoperability continue to be published and revised, meaning conformance is not a one-off milestone.
Treat 2027 as the deadline for being operational, not the deadline for starting the project. Registration, certificates and testing take longer than the integration itself.
Who is legally required to accept the wallet
Mandatory acceptance applies to organisations that are already required, under existing EU or national law, to perform strong identity verification. In practice this includes:
- Credit institutions and other entities subject to strong customer authentication and AML identity checks.
- Electronic communications providers requiring SIM registration or identity verification.
- Very large online platforms designated under the Digital Services Act.
- Public sector bodies providing services that require identification, in most Member States.
- Sector-specific regulated activities where national law already mandates ID verification (energy, transport, gambling, in several jurisdictions).
Everyone outside these categories is not obligated — but the wallet still becomes a cheaper, lower-fraud onboarding channel that competitors in adjacent sectors will start offering, which creates commercial rather than legal pressure to adopt.
Penalties and enforcement
Enforcement runs through national supervisory bodies designated under eIDAS 2.0, generally the same authorities that already oversee trust service providers. Penalties for non-compliant Relying Parties or issuers can include administrative fines, suspension from the trust ecosystem (loss of access certificates), and — for regulated sectors — knock-on breaches of sector-specific licensing conditions. The exact fine schedules are set at Member State level, so a bank operating in five countries can face five different penalty regimes for the same underlying non-conformity.
What to do now, even if your deadline is 2027
- Determine whether your organisation falls under mandatory acceptance — check sector designation, not just company size.
- Inventory every flow where you currently verify identity, and separate 'must verify' from 'nice to verify'.
- Start the Relying Party registration process early — national registers have processing times measured in months, not days.
- Decide build vs. buy for the integration layer: direct registration in every Member State you operate in, or an intermediary Relying Party that handles registration, certificates and conformance on your behalf.
This is precisely the decision Arkadiz exists to simplify: instead of running a separate registration and certificate lifecycle per Member State, you integrate once against a single trust gateway and let the intermediary carry the regulatory surface area while you focus on the product.
