The EU age verification trusted list is now live on the eIDAS Dashboard, naming who may issue proof-of-age attestations and what it means for compliance.
Table of contents
The European Commission has switched on the age verification trusted list, a public register inside the eIDAS Dashboard that names which providers are legally authorised to issue proof-of-age attestations. Denmark is the first entry. The register is a foundational block of the EU Digital Identity trust framework, which Member States must stand up by the end of 2026.
- The register is now published on the eIDAS Dashboard, operated by the Commission's DG DIGIT and DG CNECT.
- Denmark's AltID Certificate Issuance Service is the first registered Proof of Age Attestation Provider on the list.
- The Dashboard now also publishes trusted lists for wallet providers, PID providers, relying-party access certificates, registrars and third countries.
- Each Member State notifies the Commission of the proof-of-age providers established on its territory, giving online services one place to check who is legitimate.
- It underpins the privacy-preserving, data-minimising age checks the EU wants live before the EUDI Wallet becomes mandatory.
What just changed on the eIDAS Dashboard?
The European Commission has turned the eIDAS Dashboard from a signature-focused registry into the central trust hub for European digital identity, and a new age-verification register is its most concrete addition. The Dashboard, run by DG DIGIT and DG CNECT, now compiles and publishes the entities that other parties must be able to trust across the ecosystem, in machine-readable form.
The Commission's eIDAS Dashboard announcement describes the age verification trusted list as "a trusted and transparent source of information for online service providers." In practice it answers one question: is this entity legally allowed to issue a proof-of-age attestation? Per that announcement, Denmark's AltID Certificate Issuance Service is the first provider listed in the eIDAS trusted list browser, identified by a dedicated proof-of-age service type.
| Trusted list on the eIDAS Dashboard | What it registers |
|---|---|
| Age Verification Trusted List | Proof of Age Attestation Providers (first entry: Denmark) |
| Wallet Providers | Certified EUDI Wallet solutions |
| PID Providers | Person Identification Data issuers |
| WRPAC Providers | Wallet-relying-party access certificate issuers |
| Registrars and Registers | National registration authorities and registers |
| Third Countries AdES LOTL | Non-EU trusted lists (Moldova and Ukraine, per the Commission) |
How does the age verification trusted list actually work?
The age verification trusted list works as a machine-readable allow-list. A Member State certifies a proof-of-age provider, notifies the Commission, and the provider appears on the Dashboard with its X.509 certificates. An online service that receives a proof-of-age token can then validate the issuer's signature against the register before trusting the claim, with no call back to the issuer and no personal data in transit.
That model is deliberately data-minimising. A user proves they are over 18 without revealing a birth date, a document image or a name, and the relying party proves the attestation is genuine by checking the issuer against the list rather than by collecting more identity data. It is the opposite of the document-upload age gates that dominate today, and it mirrors the wallet-first direction set by Germany's Digital Identities Act and other national rollouts.
| Milestone | Date |
|---|---|
| eIDAS 2 Regulation (EU) 2024/1183 enters into force | 20 May 2024 |
| Age verification blueprint available for Member States to customise | Q2 2026 (Commission-indicated) |
| eIDAS Dashboard expands into the trust framework hub | July 2026 |
| Member States must offer at least one EUDI Wallet | End of 2026 |
What does the trust framework change for your obligations?
The trusted list changes how you evidence an age check, not just whether you run one. For a compliance or product team, that is the real shift. Under Article 28 of the Digital Services Act, platforms accessible to minors must protect them, and the Commission's age-verification guidance points toward verifiable age assurance rather than a self-declared checkbox. The register gives you a defensible way to prove the assurance was real.
Three obligations shift in practice. First, relying-party validation: if you accept a proof-of-age attestation, your control is now checking the issuer against the trust list, and your audit trail should record that you did. Second, provider due diligence: vendors claiming to offer EU-grade age checks should be traceable to a listed provider or to a certified EUDI Wallet, and "we verify age" is no longer enough. Third, data-protection posture: because the model is designed to avoid collecting birth dates and document scans, continuing to hoard that data becomes harder to justify under GDPR data-minimisation duties, and every extra field you store is a field a regulator can ask you to defend.
For KYC and anti-money-laundering teams the read-across is the wallet and PID lists that sit beside it on the Dashboard. When an EUDI Wallet presents Person Identification Data at level of assurance high, checking the wallet and PID provider against the Dashboard is how you decide whether that identity can feed customer due diligence, so the same trust-list discipline you apply to age will soon apply to onboarding. A wallet-sourced identity verified at level of assurance high can lower the residual risk that would otherwise trigger enhanced due diligence, while the trust-list check timestamps the evidence you would later cite in a Suspicious Activity Report. The line between an age check and an identity check is the number of attributes shared, not the underlying trust mechanism, and the difference between KYC and AML duties will increasingly turn on which attributes a wallet is asked to reveal.
What is still uncertain about the age verification trusted list?
The biggest open question is coverage. The list launched with a single provider, so a pan-EU network effect is a promise, not yet a reality, and services operating across borders cannot rely on it alone until more Member States notify providers. A register with one entry does not yet replace anything a global platform runs today.
Interoperability and liability are the next unknowns. Relying parties will need clarity on who is liable when a listed provider issues a faulty attestation, how quickly a compromised issuer is removed from the list, and whether wallet, age and PID checks stay in sync as the lists grow at different speeds across 27 states. Inclusion risk is also live: regulators and privacy advocates have raised concerns that biometric age estimation can misfire for some groups, an echo of the concerns that made the EUDI Wallet biometric portrait optional. An over-reliance on face-based estimation could exclude legitimate users. And the whole framework leans on a hard end-of-2026 deadline that several Member States may miss, which would leave a patchwork rather than a single market.
How does this connect to KYC and reusable identity?
The age verification trusted list is a small, sharp example of where regulated identity is heading: prove one attribute, reveal nothing else, and let the verifier check a trust anchor rather than collect a copy of your life. That same design principle drives modern KYC, where the goal is to confirm who a customer is without building another honeypot of passport images and national ID numbers, the very stores of data that turn into breach headlines.
Zyphe applies this to full onboarding. It reads the identity chip on a document to ICAO 9303 and eIDAS standards with two-step liveness and no image upload, then shards the data across a decentralised network so no single node holds a complete record and no central honeypot exists. The reusable credential means a customer can verify once and re-present elsewhere, which is exactly the "attest once, check the list" logic the EU is now standardising for age. You can see the mechanics in how it works.
How should compliance teams respond?
Start by mapping where you perform age or identity checks and asking whether each one would survive a regulator asking "how do you know the issuer was legitimate?" Add trusted-list validation to your acceptance logic for any EU proof-of-age or wallet flow, and record the check in your audit trail. Review vendors against the Dashboard, and treat providers that cannot be traced to a listed entity or a certified wallet as a gap to close. Where you still collect birth dates or document images purely to gate access, plan to retire that data before the EUDI Wallet becomes mandatory, because unused personal data is pure liability once the privacy-preserving path exists.
Zyphe helps teams get ahead of this shift by making privacy-preserving, standards-based verification the default: chip-level identity reading, no stored image honeypot, per-region data residency and an exportable audit trail, integrated through a single API in about fifteen minutes. If you want to see how reusable, data-minimising KYC lines up with the EU trust framework, book a demo.
The bottom line
A trusted list with one Danish provider is a small thing on its own, but it signals how the EU wants regulated identity to work: prove a single attribute, reveal nothing more, and verify trust against a central anchor instead of a pile of documents. Compliance teams that build trusted-list validation into their age and identity flows now, and stop collecting data they no longer need, will be ready when wallets arrive and the lists fill out.
Cited sources
- European Commission: eIDAS Dashboard expands its role in Europe's Digital Identity Trust Framework
- Regulation (EU) 2024/1183 (eIDAS 2), EUR-Lex
- EU age verification technical portal: Age Verification Trusted List specification
- European Commission: the EU approach to age verification
- eIDAS Dashboard trusted list browser
Michelangelo Frigo (Co-Founder at Zyphe) Michelangelo Frigo is a privacy and identity infrastructure expert and co-founder of Zyphe.