The deadline of 31 December 2026 tends to appear in discussions about eIDAS 2.0 as a future obligation — something on a roadmap, noted and deferred. It's worth being precise about what it actually is. Regulation (EU) 2024/1183 entered into force on 20 May 2024. Every EU member state is legally required to make at least one certified European Digital Identity Wallet available to citizens and businesses by the end of this year. That's not a policy aspiration. It's a binding obligation with implementing acts already published and interoperability testing already completed between multiple member states.
For organizations in regulated sectors — banking, insurance, healthcare, telecommunications, energy — the practical implications arrive one year later. By late 2027, those sectors must accept the EUDI Wallet as an authentication method. But the preparation for acceptance doesn't start in 2027. It starts now, because the integration work, the conformity assessment, and the identity verification workflow redesign required to accept a wallet-based credential take time that organizations in catch-up mode won't have.
We've been building digital identity middleware for over twenty years. The Portuguese Citizen Card middleware, which Caixa Mágica developed and has maintained since the early 2000s, runs on every computer in Portugal that handles Citizen Card authentication — a deployment that eventually reached the entire adult population. That experience shapes how we read eIDAS 2.0: not as a regulatory compliance project, but as an infrastructure transition with specific technical and institutional requirements that determine whether it works in practice for the people who depend on it.
What eIDAS 2.0 changes, and what it doesn't
The original eIDAS regulation of 2014 established a legal framework for electronic identification and trust services across the EU. It succeeded in harmonising qualified electronic signatures and cross-border recognition of national eIDs, but it had structural limitations: coverage was uneven across member states, adoption by the private sector was voluntary, and the system wasn't designed for mobile-first use. For organizations trying to implement cross-border digital identity in practice, the eIDAS 1.0 landscape meant navigating a patchwork of national systems with different technical architectures and different levels of assurance.
eIDAS 2.0 changes this in three ways that matter operationally. First, it mandates universal availability — every citizen and resident in the EU will have access to a wallet, not just those in member states that chose to implement a strong national eID scheme. Second, it mandates private-sector acceptance — the voluntary nature of eIDAS 1.0 private-sector participation is replaced by an obligation for regulated sectors and very large online platforms. Third, it introduces selective disclosure at the architecture level — citizens can prove specific attributes (age, professional qualification, address) without revealing unrelated personal data, which changes the design requirements for identity verification workflows significantly.
What eIDAS 2.0 doesn't change
eIDAS 2.0 doesn't just extend eIDAS 1.0. It replaces the assumption that digital identity is optional for the private sector with a legal requirement to accept it.
What it doesn't change is the fundamental engineering challenge of digital identity: making a system work reliably for people who need it, in the conditions in which they actually use it, across the institutional and legal frameworks of multiple jurisdictions. The Cabo Verde middleware project — where we built an offline-first digital identity system for a ten-island archipelago — is a reminder that the hardest problems in digital identity aren't in the specification. They're in the gap between specification and deployment at scale.
Who needs to do what, and by when
The obligations under eIDAS 2.0 fall on different actors at different times. It's worth mapping them precisely, because the common framing — "the deadline is 2026" — obscures the fact that different organizations face different obligations on different timelines.
The technical layer that most eIDAS 2.0 implementation discussions skip
Most of the public conversation about eIDAS 2.0 focuses on the policy framework: which sectors are obligated, what the deadlines are, how cross-border recognition will work. The technical layer receives less attention, which is where most implementation projects encounter the problems that delay them.
The EUDI Wallet ecosystem is built on three technical specifications that every relying party needs to support: ISO/IEC 18013-5 (the standard for mobile document presentation, originally designed for mobile driving licences), W3C Verifiable Credentials (the data model for selective disclosure of identity attributes), and the EUDI Architecture Reference Framework, which specifies how these interact with national wallet implementations, trust registries, and interoperability across member states.
For organizations whose authentication systems were built for eIDAS 1.0 — which used different data formats, different assurance levels, and different interaction models — this isn't an update. It's a redesign of the identity verification flow. The middleware layer that sits between the wallet and the application needs to handle credential presentation from different member state wallets, validate against the relevant trust registry, enforce selective disclosure so only the required attributes are accessed, and produce an audit record of the verification.
What the Portuguese Citizen Card experience says about eIDAS 2.0
The Portuguese Citizen Card middleware has been in production for over twenty years. It's been through multiple card generations, operating system changes, browser updates, and regulatory evolutions. The most consistent lesson from that experience isn't technical — it's institutional. Digital identity infrastructure that works reliably at national scale requires sustained alignment between the bodies responsible for the legal framework, the document itself, and the software. When any of those three changes without coordination, the middleware breaks in ways that affect every citizen who tries to use their card.
eIDAS 2.0 adds a fourth dimension that the Citizen Card never had to manage: interoperability across 27 independent national implementations, each built to the same ARF specification but with implementation choices that will differ in practice. The ARF is detailed and technically rigorous. What it can't fully specify is the real-world behaviour of 27 wallet implementations at the moment they go into production simultaneously, with millions of users attempting cross-border verification for the first time.
The specification is not the implementation. The gap between them is where the real engineering work of digital identity lives — and where experience with national-scale deployments matters most.
This is not an argument against eIDAS 2.0. It's an argument for approaching the implementation with the seriousness it deserves, rather than treating it as a software update that will be handled closer to the deadline. Organizations that have started the integration work now — building against the ARF, testing against available wallet implementations, and establishing the institutional relationships required for relying party registration — are in a materially better position than those treating late 2027 as the real deadline.
The data sovereignty question that the policy discussion understates
One of the most consequential architectural choices in eIDAS 2.0 is one that tends to get described in terms of privacy: selective disclosure. A citizen can prove they are over 18 without sharing their date of birth. They can prove professional qualification without sharing their full identity. This is described as a privacy feature, which it is. But it has a structural implication for how identity verification systems need to be designed that goes beyond privacy.
Systems built for eIDAS 1.0 and pre-eIDAS identity verification typically requested and stored a defined set of identity attributes — name, date of birth, identification number — and retained them as part of the user record. Selective disclosure under eIDAS 2.0 means that the attribute presented during verification may not be the same as the attribute stored, and in many cases the application should not be storing personal data at all — only a confirmation that the verification occurred. This requires a redesign of data models, storage architectures, and audit trails that is not a minor update to existing systems.
eIDAS 2.0 implementation: what organizations should be doing now
The practical preparation for eIDAS 2.0 acceptance isn't a single project. It's a sequence of decisions that build on each other, and the earlier in the sequence an organization is, the more time it has to course-correct before the acceptance obligation arrives.
What eIDAS 2.0 doesn't resolve on its own
It's worth being honest about what the regulation can and can't deliver. eIDAS 2.0 establishes a legal framework that, when fully operational, will give every EU citizen access to a portable, interoperable digital identity. That's a significant achievement in the context of Europe's fragmented pre-2024 landscape. What it doesn't guarantee is that the 27 wallet implementations will all be functionally complete by 31 December 2026, that relying party registration will be straightforward in every member state, or that the user experience of wallet-based authentication will be smooth enough for widespread voluntary adoption.
An independent assessment published in April 2026 found that three countries appear almost certain to meet the December deadline with full functionality, five are very likely, eight are likely, and the remaining eleven face varying degrees of risk. The launch will be real but uneven. For organizations planning their eIDAS 2.0 integration, this means the testing environment will not be uniform, and the assumption that wallet availability in one member state implies the same functionality in another needs to be verified rather than assumed.
None of this is an argument for waiting. It's an argument for building the integration with enough lead time to absorb the variability that a parallel rollout across 27 member states will inevitably produce. The organizations that treat the late 2027 acceptance deadline as the start of their preparation will discover that their competitors, who started in 2025 and 2026, are already through the hard part.
