On this page · 13 sections
- Why the deadline is 24 December 2027
- Who must accept, and who is exempt
- Step 1: register as a wallet-relying party
- Step 2: build the protocol stack
- Step 3: verification logic in your back end
- Step 4: age verification without collecting birth dates
- Step 5: strong customer authentication for banks
- Build, buy or use an intermediary
- Worked example: a 412-day plan for a mid-size telco
- Notes for Indian and other non-EU teams
- Implementation checklist
- How eCorpIT can help
- References
Summary. Article 5f(2) of the eIDAS Regulation, as amended by Regulation (EU) 2024/1183, requires private relying parties that must use strong user authentication for online identification, by law or contract, to accept the EU Digital Identity (EUDI) Wallet when a user asks. It names banking, energy, telecommunications and eight other areas, and exempts micro and small enterprises. The deadline is 36 months after the implementing acts under Articles 5a(23) and 5c(6) entered into force on 24 December 2024: 24 December 2027, a date the regulation does not print. Wallets are due by 24 December 2026, when the rules for public registers of wallet-relying parties also start to apply. Since 11 August 2026, Implementing Regulations 2026/1730 and 2026/1731 have fixed the stack: SD-JWT VC and ISO mdoc credentials, OpenID4VP under the HAIP profile, ISO/IEC TS 18013-7 for mdoc over APIs and the IETF Token Status List, with relying parties required to support the browser API route as well as redirects. Banks can approve payments with the wallet under Technical Specification 12, but whether the duty covers that is unsettled. Our verdict: register early, ship login and onboarding first.
About this article. For engineering and compliance teams at EU banks, telcos, energy suppliers and insurers, and the Indian teams that build for them. On 7 November 2026 we checked every date and obligation against the Official Journal texts of Regulation (EU) 2024/1183 (published 30 April 2024), Implementing Regulations (EU) 2024/2977 to 2024/2982 and 2025/848 as published, and the amending Implementing Regulations (EU) 2026/1730 and 2026/1731 of 15 July 2026, read from the EU Publications Office because EUR-Lex refused automated requests. We also read the specifications themselves and German, Finnish and Italian legislative texts. Where we rely on Eudigo, an independent tracker, we say so. This is general information, not legal advice; scope questions are for your counsel. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
Why the deadline is 24 December 2027
Article 5f(2) sets the deadline at no later than 36 months after the entry into force of the implementing acts referred to in Articles 5a(23) and 5c(6). Four acts were adopted under Article 5a(23): 2024/2977 on person identification data (PID) and attestations, 2024/2979 on wallet integrity, 2024/2980 on notifications and 2024/2982 on protocols. The certification act under Article 5c(6) is 2024/2981. All five were published on 4 December 2024 and entered into force 20 days later, on 24 December 2024.
The key dates come from the Official Journal and the Bundestag.
| Date | Event | What it means for a relying party |
|---|---|---|
| 24 Dec 2024 | Five implementing acts enter into force | The 24-month and 36-month clocks start |
| 27 May 2025 | Implementing Regulation 2025/848 on registration enters into force | It applies only from 24 December 2026 |
| 11 Aug 2026 | 2026/1730 and 2026/1731 enter into force | Formats, protocols and certificates fixed |
| 24 Dec 2026 | Wallets due in every member state; 2025/848 applies | Registration and testing can start |
| 2 Jan 2027 | Planned start of Germany's wallet, d-you | One large market arrives just after the EU date |
| 10 Jul 2027 | EU Anti-Money Laundering Regulation applies | Onboarding rules change the same year |
| 24 Dec 2027 | Acceptance obligation for private relying parties (calculated) | The wallet option must be live |
| 11 Aug 2028 | Wallets must validate registration certificates; portrait becomes mandatory PID data | Over-asking checks become a wallet duty |
Two cautions. First, no official text prints 24 December 2027; the Commission's page, updated 6 November 2026, says only that wallets are due by the end of 2026, and Eudigo reaches the same date by the same count. Second, 2026/1731 amended four of the original acts and was itself adopted under Article 5a(23). We read the 36 months as running from the original acts, as Eudigo does, and found no official statement that the amendment moves the date. Plan on 24 December 2027 and have counsel confirm.
Two more 2026 changes matter. 2026/1731 dropped the W3C Verifiable Credentials Data Model 1.1, named in the original format annex, in favour of ETSI profiles for SD-JWT VC and mdoc, though its recitals say wallets should support the W3C model once new profiles exist. And Germany's Bundestag passed a Digital Identities Act on 15 October 2026 that applies Article 5f to purely domestic cases; the Bundesrat has it on its agenda for 20 November 2026.
Who must accept, and who is exempt
The tiers come from Articles 5a(15) and 5f, with the size test from Commission Recommendation 2003/361/EC.
| Who | Article | Obligation | Date |
|---|---|---|---|
| Public sector bodies requiring electronic identification for an online service | 5f(1) | Also accept EUDI Wallets | No date in the article |
| Private relying parties required by law or contract to use strong user authentication for online identification | 5f(2) | Accept wallets on the user's voluntary request | 24 Dec 2027 (calculated) |
| Very large online platforms under Article 33 of the Digital Services Act that require login | 5f(3) | Accept and facilitate wallets on request, for the minimum data necessary | No date in the article |
| Micro and small enterprises (under 50 staff, turnover or balance sheet up to EUR 10 million) | 5f(2) exemption | Not obliged; may opt in, but must then register | Not applicable |
| Users | 5a(15) | Wallet use is voluntary; other access routes must remain | Not applicable |
The test is whether Union law, national law or a contract requires strong user authentication for online identification. Article 3(51) defines that as at least two independent factors from different categories (knowledge, possession, inherence), almost word for word PSD2's definition of strong customer authentication. The sector list is introduced by the word including, so it is open. Typical candidates, in Eudigo's reading, are online banking login, a mobile contract with an identity check, and energy or health insurance portals that require proof of identity. Medium-sized enterprises are not exempt, and size counts linked and partner enterprises.
Accepting means adding an option: existing logins and video identification can stay, because other means of access must remain. Article 5f is headed cross-border reliance, but Germany's act would also cover domestic cases, so check each national law.
Step 1: register as a wallet-relying party
No registration, no access certificate; no access certificate, no wallet response. Article 5b(1) requires registration in the member state where you are established, and Implementing Regulation 2025/848 sets the mechanics from 24 December 2026.
What you file. Annex I asks for your names; identifiers such as VAT number, EORI, LEI or EUID; address and contacts; a description of your services; for each intended use, a machine-readable list of the data you will request and why; whether you are a public body; your entitlements, such as service provider or attestation provider; and any intermediary. Registers are public through a single common REST API and a national website.
What you get. An access certificate that authenticates you to wallets, under ETSI TS 119 411-8 V1.1.1, and a registration certificate under ETSI TS 119 475 V1.2.1 that states each intended use and its registered data. Registration certificates were optional for member states under the original 2025/848; since 2026/1730 every member state must issue them automatically after registration, and the data and purpose details are collected for transparency, without pre-authorisation.
What constrains you. Article 5b(3) bars requesting data you did not register. Registrars may suspend or cancel a registration for inaccurate information or for requesting more attributes than registered, revoking your certificates (Article 9); records are kept for 10 years (Article 10).
Where national set-up stands. Finland's Act 810/2026, in force since 1 October 2026, makes Traficom the register's controller. An Italian decree signed on 31 July 2026 names AgID, with IPZS running the infrastructure. Germany's act would name the Federal Office of Administration. Eudigo reported on 12 October 2026 that the Netherlands had no registrar yet and that the Commission's EU-wide registrar list was unpublished.
What it costs. Eudigo found no published fees in any member state as of 12 October 2026. Germany's government bill estimates about 40 hours of internal effort for a first registration in the launch phase, about EUR 2,300 at EUR 57.90 an hour, and about 32 hours (about EUR 1,850) later. It models about 4,200 launch-phase registrations and about 550 a year after that.
Step 2: build the protocol stack
Versions are those the regulations reference.
| Layer | Standard | Version referenced | Notes |
|---|---|---|---|
| Online presentation | OpenID4VP through the OpenID4VC HAIP profile, ETSI TS 119 472-2 | OpenID4VP 1.0 (9 Jul 2025); HAIP 1.0 (24 Dec 2025); TS 119 472-2 V1.2.1 | DCQL queries; redirect and API-mediated paths |
| Online mdoc | ISO/IEC TS 18013-7, Annex C | 2025 | API-mediated mdoc presentation |
| In person | ISO/IEC 18013-5 | 2021 | NFC, Bluetooth LE or QR; mdoc only; no server retrieval |
| JSON credential | SD-JWT VC, ETSI TS 119 472-1 clause 5 | TS 119 472-1 V1.2.1 | SD-JWT VC is an IETF draft; base SD-JWT is RFC 9901 |
| CBOR credential | ISO mdoc, ETSI TS 119 472-1 clause 6 | TS 119 472-1 V1.2.1 | Online and in person |
| Revocation | IETF Token Status List | Draft 20 (20 Apr 2026) | Draft 21 is in the RFC Editor queue |
| Relying-party trust | ETSI TS 119 411-8 and TS 119 475 | V1.1.1 and V1.2.1 | Access and registration certificates |
| Issuance (banks issuing SCA attestations) | OpenID4VCI 1.0 via ETSI TS 119 472-3 | 1.0 (16 Sep 2025); TS 119 472-3 V1.1.1 | Only if you issue into the wallet |
Transport is the change to watch. ETSI TS 119 472-2 as published left the API-mediated mechanism optional. The version made binding by 2026/1731 changes that for the OpenID4VC-HAIP profile: relying parties must meet the API-mediated requirements as well as the redirect ones, wallets must support a mediating API for both HAIP section 5.2 and 18013-7 Annex C, and wallets should not support redirect-based cross-device flows, because of session fixation attacks. HAIP section 5.2 is OpenID4VP over the W3C Digital Credentials API, still a W3C Working Draft (latest 5 November 2026). So keep redirects for same-device flows, build the browser API path now, and do not plan a QR-code redirect as your cross-device answer. The regulation concedes that operating system or browser gaps can block the API path, so test on real devices.
Two referenced specifications are still IETF drafts: Token Status List (draft 20 cited; draft 21 in the RFC Editor queue) and SD-JWT VC (draft 26 of 6 November 2026, in IESG evaluation). A final RFC may differ slightly, so pin versions.
SD-JWT VC is easier in web back ends; mdoc is the only format for in-person checks, such as at a telco store counter. Support both; the Commission's age verification app issues mdoc only.
Step 3: verification logic in your back end
A DCQL query names the credential type and the claims you want. This one asks for a PID in SD-JWT VC format; the type urn:eudi:pid:1 and the claims family_name and birthdate come from the PID annex as amended by 2026/1731. For mdoc, use format mso_mdoc and namespace eu.europa.ec.eudi.pid.1.
{
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": { "vct_values": ["urn:eudi:pid:1"] },
"claims": [
{ "path": ["family_name"] },
{ "path": ["birthdate"] }
]
}
]
}
Then verify in this order:
- Authenticate yourself. Use the
x509_hashclient identifier prefix, sign the request object with the key in your access certificate, and include your registration certificate inverifier_info. Wallets compare the request with that certificate and warn the user about over-asking; their legal duty to validate it starts on 11 August 2028.
- Bind the session. Include a fresh nonce and check that the response is bound to it and to your client identifier.
- Check the issuer. Validate the signature against the published lists of trusted PID and attestation providers.
- Check holder binding. For SD-JWT VC, validate the key binding JWT; for mdoc, the device authentication.
- Check status. Reject revoked credentials. PID and attestations from qualified providers or public bodies show only revoked or not revoked, with no suspension. For mdoc, status checks are optional for relying parties, but if you check you must support both the status list and identifier list mechanisms.
- Minimise and log. Store only what the process needs plus evidence of the check; keep a disclosed portrait only where identification needs it or law requires it.
Two onboarding catches: address is only an optional PID attribute, so onboarding customers from other member states needs a second route for proof of address, and the portrait becomes mandatory PID data only from 11 August 2028. For the AML side, see our AMLR guide for July 2027.
Step 4: age verification without collecting birth dates
The PID has no age-over attribute, so a PID-based age check discloses the birth date. Use the Commission's Proof of Age attestation instead: mdoc only, document type eu.europa.ec.av.1, an age_over_18 attribute in every attestation, optional attributes for other thresholds, and no other personal data. It is presented over the W3C Digital Credentials API through ISO/IEC TS 18013-7 Annex C, with OpenID4VP as fallback.
{
"credentials": [
{
"id": "age",
"format": "mso_mdoc",
"meta": { "doctype_value": "eu.europa.ec.av.1" },
"claims": [ { "path": ["eu.europa.ec.av.1", "age_over_18"] } ]
}
]
}
The Commission published its blueprint on 14 July 2025 and says the solution became feature-ready on 15 April 2026, can now be customised by member states and market players, shares the wallets' technical specifications and adapts to thresholds such as 13+. The verifier is the same: check signature, binding and status, then store the boolean plus evidence. The US is putting age checks at the app store instead; our App Store Accountability Act guide covers Alabama's and Louisiana's 2027 rules.
Step 5: strong customer authentication for banks
PSD2 Article 97 requires strong customer authentication when a payer accesses an account online, initiates an electronic payment or acts remotely in a way that may imply fraud risk, with remote payments dynamically linked to amount and payee; Delegated Regulation (EU) 2018/389 sets the technical standards. Recital 62 of Regulation 2024/1183 says electronic identification and attestations should help support it for account login and payment initiation, but recitals guide interpretation and create no duties.
The technical design exists. Technical Specification 12 reached version 1.0 on 5 December 2025, with an editorial 1.0.1 on 30 January 2026. The bank issues its own SCA attestation, cryptographically bound to the user's wallet unit, and at payment time requests it through OpenID4VP with a transaction_data object whose required payment fields include a transaction identifier, amount, currency and the payee's name and identifier. The user approves the displayed details, and the presentation carries a key binding JWT with a fresh jti that becomes the authentication code. TS12 covers SD-JWT VC and OpenID4VP only. The bank is then both relying party and issuer, and the Architecture and Reference Framework requires issuers to sign their metadata with their access certificate key.
The legal question is open. Eudigo reported on 13 October 2026 that neither the Commission nor the EBA had said bindingly whether Article 5f covers payment approval or only identification and login. In May 2025 the Dutch Payments Association judged it practically impossible to use the wallet as a second factor in full compliance with PSD2's SCA rules; TS12 came later. The Payment Services Regulation, set to take over those rules, is not in force: the Council's position was published on 5 November 2026 and Parliament's second reading is indicatively set for 14 December 2026. Build login and onboarding to the deadline; design payment approval in as phase two.
Build, buy or use an intermediary
An intermediary acting for you is itself a relying party under Article 5b(10) and may not store data about the content of the transaction; your registration names it.
| Option | What you run | Registration | Fits |
|---|---|---|---|
| Direct build on the Commission's open-source reference components | Verifier endpoint, trust-list sync, status checks, certificates | You register | Banks and telcos with identity engineering teams |
| Intermediary | The provider runs the wallet connection | You and the intermediary both register | Mid-size firms that want speed |
| Existing identity or KYC vendor | Depends on the vendor's wallet support | You still register | Firms that already outsource onboarding |
Whichever route you choose, the obligation, the registration and the data-minimisation duty stay with you.
Worked example: a 412-day plan for a mid-size telco
From 7 November 2026 to 24 December 2027 is 412 days, about 59 weeks. Take a hypothetical mobile operator with entities in three member states, each checking identity for postpaid contracts and SIM swaps.
| Window | Work |
|---|---|
| Nov to Dec 2026 | List every process with strong authentication or identity checks; confirm size; choose build or intermediary |
| Jan to Mar 2027 | Register in each state as portals open; set up sandbox testing; write DCQL queries per intended use |
| Apr to Jun 2027 | Pilot with launched national wallets; support SD-JWT VC and mdoc; build redirect and browser API paths; add status checks |
| Jul to Sep 2027 | Align onboarding with the AML Regulation from 10 July 2027; go live for online onboarding and login |
| Oct to Dec 2027 | Add in-store mdoc checks, cross-border tests and buffer |
Using Germany's estimate as a rough proxy for all three states, first registrations take 3 x 40 hours = 120 hours, or 3 x EUR 2,300 = EUR 6,900: an order of magnitude, not a budget.
Notes for Indian and other non-EU teams
Registration attaches to the member state of establishment, so an EU subsidiary registers where it is established; whether a firm with no EU establishment can or must register is for counsel. For Indian teams building verifiers for EU clients, the GDPR governs the wallet data. India's DPDP Act mostly steps back: section 17(1)(d) disapplies most of Chapters II and III when an India-based firm processes data of people outside India under a contract with a person outside India, though section 8(1) accountability and section 8(5) security safeguards still apply. Our DPDP Act engineering playbook covers those safeguards.
Implementation checklist
- Map processes where law or contract requires strong authentication, and confirm size under Recommendation 2003/361/EC.
- Name an owner for registration, certificates and change notices.
- Define intended uses and minimum claims; the register is public.
- Register once 2025/848 applies on 24 December 2026.
- Implement OpenID4VP with HAIP over redirects and the browser API, plus 18013-7 Annex C and 18013-5 for mdoc.
- Sync trusted lists, verify holder binding, check status and send your registration certificate.
- Keep existing login and KYC routes.
- Banks: prototype TS12 and track the PSR.
- Use proof-of-age attestations, not birth dates.
- Pin specification versions.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our identity and CIAM implementation service can add a wallet verifier, trust-list sync and OpenID4VP and mdoc flows alongside your existing login and KYC stack. Talk to us at /contact-us/.
Last updated: 7 November 2026.
