Blog

Onboard in minutes, prove it in 2040: what eIDAS 2 means for finance and insurance

TL;DR. From December 2027, banks and insurers have to accept the European Digital Identity Wallet wherever strong customer authentication is already required by law. Treated as a compliance chore that is a cost. Treated properly it removes most of your onboarding friction, and fixes an evidence problem you may not know you have.

Meet Marie. She is 48, she has just bought an apartment with her partner, and on a Tuesday evening she finally gets around to arranging life insurance.

She finds your website, likes the quote and starts the application. Twenty minutes later she has photographed her ID card three times because the first two were blurry, gone looking for a proof of address that nobody has received on paper since 2019, and landed on a screen promising that someone will review her file within two working days.

Marie closes the tab. Marie is not coming back.

Hold that thought, because in roughly sixteen months that Tuesday evening is going to look very different, and the reason is a regulation with an unpromising name.

What eIDAS actually is

eIDAS stands for electronic IDentification, Authentication and trust Services. The original arrived in 2014 and quietly underpins things you already use, such as itsme and your eID card. The 2024 rewrite, Regulation (EU) 2024/1183, adds one big new element: the European Digital Identity Wallet, an app issued by your own member state that holds a citizen’s verified identity and can prove things about them. Each member state has put forward its own national wallet: BOSA’s myGov app in Belgium, France Identité in France, and DigiD in the Netherlands. All three are live today for government services, and the certified wallet versions are in pilot ahead of the December 2026 deadline. 

The scope is worth stating plainly, because eIDAS is regularly mistaken for a much bigger beast. In short, eIDAS governs three things: 

1. how you establish who someone is, 
2. how they sign or seal, and 
3. how that evidence survives over time. 

Identity, signature, proof. In finance and insurance, those three happen to sit at the beginning, the middle and the end of almost every process you run. 

A Belgian wallet also works in Spain, by the way. No bilateral recognition negotiations and no separate flow for the customer who moved here from Lisbon last year. 

One further property is worth knowing: the wallet supports selective disclosure. This means that a customer can prove they are over 18 without handing over their date of birth. You ask for less, so you hold less, and data you never collected is data you never have to secure, justify or report as breached. 

eIDAS 2 deadlines 

Every member state must offer a wallet by the end of 2026, and public bodies must accept it from that same date. Regulated private sectors, banking and financial services among them, must accept the wallet by December 2027, wherever strong customer authentication or identification is already required under European or national law. For banks that is unambiguous, since PSD2 already mandates strong customer authentication. For insurers it depends on the journey, so the first useful exercise is working out which of your flows actually carry that obligation. 

Two things make that date less comfortable than it looks. The anti-money-laundering regulation (AMLR) applies from 10 July 2027, five months earlier, and it is blunter than it first appears. For verifying a customer remotely, its Article 22 points exclusively at eIDAS means of identification. That means: one identity stack, two regulations, a single budget year. 

The second thing is more cheerful. Because public bodies must accept wallets a full year before you do, your customers will have been using theirs to file taxes and renew permits long before they use one on your portal. The adoption curve, normally the expensive part of any identity project, is being paid for by someone else. 

That leaves you roughly sixteen months to design, build, test and register as a relying party. 

But we already have itsme 

Fair, and itsme is not going anywhere: it is a qualified trust service provider and is expected to plug into the wallet ecosystem rather than compete with it. But itsme covers a moment, not the chain. It authenticates the user and it can sign. It does not issue the verified attributes that make onboarding instant, it says nothing about what happens to the document afterwards, and accepting itsme is not legally the same as accepting the wallet. If your eIDAS 2 plan currently consists of the sentence “we have itsme”, the interesting question is which pieces are missing. 

Marie’s Tuesday evening, the 2028 version 

Let’s get back to Marie, and fast forward to 2028. 

She finds your website, likes the quote and starts the application. Your portal shows a QR code. She scans it with her wallet, approves the request on her phone, and her identity arrives in your systems verified by the state itself. No card reader, no photographs, no utility bill, no driving licence. Age, address and the attributes you need for risk acceptance come through as verified claims rather than as fields she typed in and you quietly hope are accurate. 

That is a small change of wording with a large consequence for your data. Today the customer asserts and you verify. From here the issuer asserts, cryptographically, and you consume. What lands in your systems is not merely faster, it is better than what you collect today, and it arrives already attributable to a source that is not your call centre. 

Because there is nothing left for anyone to review by hand, Marie gets a decision in the same session. She signs the policy with a qualified electronic signature generated by the wallet, without ever leaving your journey. 

That last step matters more than it looks at first sight. A qualified electronic signature (QES) carries the same legal weight as a handwritten one in all 27 member states. That equivalence is what changes your position in a dispute. Advanced signatures (AES), where most insurers sit today, cannot be denied legal effect for being electronic, but their reliability is something a court assesses, and the work of establishing it lands on the party relying on the signature. That is usually you. With a qualified signature there is nothing to establish. 

The same pattern reaches well beyond life policies: mandates, beneficiary clauses, claim settlement agreements, credit agreements. Broker and partner onboarding too, where a company proves its identity and the mandate of the person signing instead of emailing scans of its statutes and hoping the mandate is still current. That last one runs on the European Business Wallet, a separate track arriving behind the citizen wallet, so plan it as phase two rather than day one. 

Twelve years later: proving evidential value 

Fast forward again, this time to 2040. Marie has died, the payout is substantial, and a family member disputes who the beneficiary was. Your lawyers go looking for the policy. 

They find it immediately. It is exactly where it should be: a tidy PDF in the document library. And that is the moment somebody discovers that storing a signed document is not the same thing as being able to prove it. 

Signatures depend on certificates, and certificates expire. A policy signed in 2028 may rest on a certificate that lapsed in 2033. To defend it in 2040 you must still show the signature was valid at the moment of signing, and a PDF cannot do that on its own, no matter how neat the metadata is. 

eIDAS answers this with two services that are easy to merge into one and should not be. Qualified preservation keeps a signature verifiable long after its certificate has expired, by re-timestamping the validation evidence before the cryptography ages out. Qualified electronic archiving, one of the four trust services newly introduced by eIDAS 2, covers the record itself: anything held in a qualified archive enjoys a presumption of integrity and origin for the entire preservation period. An archiving provider is allowed to lean on a preservation service for the signature part, which is how most qualified providers are built. 

The practical output is the part worth remembering. On request, a qualified archive hands your lawyers a report confirming that the document is intact and came from where it claims to, sealed by the provider. That is a rather different conversation from producing a PDF and asserting that it looks untouched. Life insurance, pensions and mortgages run for twenty or thirty years, so this is not a theoretical edge case. It is probably most of your portfolio. 

Authenticate, sign, preserve. A single transaction touches all three, and getting two out of three right feels perfectly compliant, right up to the year somebody asks you to prove it. 

eIDAS 2 compliance: what to do before 2027 

Nothing needs rebuilding this quarter. What you do need is to stop building flows that will have to be torn out again. 

Three things worth doing now: 

• Design new authentication and signing journeys as wallet-ready, even if nobody’s asking for it yet 
• Decide which document families genuinely need qualified treatment. Not all of them do, and over-engineering is expensive 
• Check whether your archive is really an archive, or just a well organised folder 

The deadline arrives either way. The efficiency you get from it is optional. 

Take one journey you already run (an onboarding flow, a signing flow) and ask yourself: 

1. Can you authenticate that transaction end to end? 
2. Can you sign it in a way that holds up in a dispute? 
3. Can you still prove both of those 20 years from now? 

If you’re not sure on any of the three, that’s the gap worth finding. 

We’ll walk through your journey and these three questions with you, in an hour. Bring the flow and we’ll help you understand exactly which of the three you’re missing, and what it takes to close it.