December 2026 Is the Wallet Deadline. The Harder Question Is What Companies Do With What Comes Out of It
Every EU member state has to offer at least one European Digital Identity Wallet. Regulation (EU) 2024/1183 sets the obligation, and the implementing regulations apply from 24 December 2026. Most coverage has focused on the citizen side: one app, national ID inside, log in anywhere in Europe.
The business side has had less attention, and it's the side that involves work.
The receiving end
A wallet is not only an identity you present. It's also a source of signed artefacts that land in someone's inbox. Attestations of attributes, signed declarations, documents signed with a certificate held on a remote device the wallet manages. The regulation's moving parts are worth reading once in plain language before December, because the wallet is the visible piece of a much larger change to how trust services work: there's a walkthrough of what eIDAS 2.0 actually changes that covers the deadlines without the legal drafting.
Which raises a question most companies haven't asked yet: when one of those arrives, who checks it, and against what?
The honest answer inside most organisations today is that nobody checks it, because nobody checked the last signed PDF either. Somebody opened it, saw no red banner, and filed it. That works tolerably when signed documents are rare. It works badly when they become the normal way counterparties send things.
The plumbing moved in April
There's a detail from earlier this year that matters here and got almost no coverage outside compliance circles.
Commission Implementing Decision (EU) 2025/2164, adopted 27 October 2025 and applicable from 29 April 2026, changed the standard that member state trusted lists are built on. The template moved from ETSI TS 119 612 v2.1.1 to v2.4.1. That update exists precisely so the lists can carry the new service types eIDAS 2.0 created, including remote management of qualified signature creation devices and qualified electronic attestation of attributes.
In other words: the trust infrastructure was rebuilt in April to hold what the wallets will start producing in December. The two dates are the same project.
Anything validating signatures against a stale copy of that infrastructure will get worse answers as the year goes on, and the failure is quiet. A signature that can't be traced to a trusted root doesn't announce that the reader is out of date. It just looks suspicious.
What a real check answers
Validation isn't one question. It's four, and conflating them is where most confusion starts.
Did the document change after it was signed? That's a hash comparison, and it's binary. One altered byte fails it, and re-saving a PDF counts as altering it.
Does the signing certificate chain to a root that the EU actually trusts? That's the trusted list question, and it's the one that broke for people in April.
Was the certificate valid at the moment of signing, and had it been revoked? Note the phrasing. The question is about the signing moment, not about today.
Is there a timestamp proving when that moment was? Without one, the third question has no anchor.
A tool that returns a single green or red verdict has collapsed all four into one word, and you can't tell from the word which one failed. That distinction decides whether you're dealing with a forged document or a configuration problem, and those need entirely different responses.
An unglamorous suggestion
Before December, pick a signed document your company already received and trusts. Run it through an independent validator. See whether the answer matches what your normal software said.
Chaindoc's signature checker is one way to do that. It runs the EU Digital Signature Service library against the EU Trusted List and reports integrity, the certificate and its chain, revocation status, embedded timestamps and the PAdES level as separate lines rather than one verdict. Files up to 50 MB. The first check in a session asks for an email and a one-time code, and the file isn't retained after the check runs.
If the two answers agree, good, you've confirmed something. If they disagree, you've found the gap now instead of during a dispute, which is the entire point of doing it in a quiet month.
Where this actually lands
Two predictions, offered with the appropriate humility about predictions.
Most companies will hit December unprepared, because the deadline is written as an obligation on member states rather than on businesses, and obligations that name someone else rarely make it onto anyone's roadmap.
And the first real problems won't look like fraud. They'll look like a valid document that one system accepts and another rejects, with an afternoon lost to working out which one is right. That's the boring failure mode, and it's the likely one.
Worth knowing which of your systems you'd believe.
A note on the other end of the same pipeline
Verification is the receiving side. The sending side has its own quiet mess, and operations teams tend to inherit it.
Internal documents get signed by pasting an image someone saved years ago, usually stored in a shared drive where anyone can copy it. Keeping that asset in one place at least stops it spreading across folders and email threads. Chaindoc holds it against a user account, with creation and storage on the free tier. The image still proves nothing on its own, which is exactly the point worth making internally: it is a rendering, not a record, and documents that matter need the second thing rather than a tidier version of the first.
Audit that shared drive at some point. The number of signature files sitting in template folders, copied by every new starter, tends to surprise people.