Do You Really Have to Verify Your Age Every Time Online?

June 24, 2026 ·Mairi Kutberg ·

age-verificationdsaeudi-walletage-attributeselective-disclosuresren-lawonline-safety-actauthenticationeidas

No, not every time — if your platform is wired to consume a wallet-based age attribute under the EUDI Wallet framework. The DSA requires age-appropriate design under Article 28, Member States are layering harder mandates (France SREN, UK Online Safety Act), and the EUDI Wallet age attribute lands as the EU-wide compliance answer through 2026 pilots.

Do You Really Have to Verify Your Age Every Time Online?

No, not every time — if your platform is wired to consume a wallet-based age attribute under the EUDI Wallet framework. The DSA requires age-appropriate design under Article 28, Member States are layering harder mandates (France SREN, UK Online Safety Act), and the EUDI Wallet age attribute is the EU-wide compliance answer through 2026 pilots.

In our work helping platforms ship age verification under the layered regulatory regime emerging in 2026, the question lands on the compliance officer's desk at least twice a quarter. Usually the trigger is a customer complaint — "your site asked me to upload my ID three times this month" — or a regulator request asking how the platform handles minor users under a new Member State law. The honest answer is layered: yes, you need some form of age verification, no it doesn't have to be invasive, and yes the EU's pilot rollout in 2026 changes which method is actually defensible. This post is how we walk customers through it.

What does the DSA actually require for age verification?

Appropriate and proportionate measures — without specifying exactly how.

Article 28 of the Digital Services Act (Regulation (EU) 2022/2065) states that "providers of online platforms accessible to minors shall put in place appropriate and proportionate measures to ensure a high level of privacy, safety, and security of minors, on their service". The Article does not prescribe the verification mechanism, the assurance level, or the technology. It leaves that to a combination of European Commission guidance, Member State implementation, and sectoral law.

What this means in practice for any platform with EU users is that something has to be in place. The European Commission has explicitly stated that voluntary self-declaration ("I am 18 or over") is not, on its own, an appropriate measure for content categories that carry meaningful risk to minors. But it also has not, until 2026, mandated a single technical solution. The Article 28 gap has been filled, since 2024, by a wave of Member State and adjacent jurisdiction laws creating their own enforceable requirements — and by sectoral regulations (gambling, adult content, alcohol sales) that have always carried age-verification obligations independent of the DSA.

What I see at the regulator-platform interface in 2026 is that compliance leads have learned not to treat "appropriate and proportionate" as a one-size answer. The question that matters under DSA enforcement is whether the platform's measure is defensible against the specific risk profile of its service — and "defensible" has become a moving target as Member State law tightens.

Where are Member States already running age-verification mandates?

In several jurisdictions, with materially different requirements landing in 2024-2025.

France — SREN Law (adopted 21 May 2024). The Loi visant à sécuriser et à réguler l'espace numérique imposes age-verification obligations on adult-content platforms and on social media in defined cases. The French regulator ARCOM has been empowered to enforce these and has issued specifications for what counts as acceptable age verification (rejecting plain self-declaration). The technical reference architecture France is rolling out — anonymous age attestation — is the model the EU Age Verification Solution has explicitly aligned with.

United Kingdom — Online Safety Act 2023 (Royal Assent 26 October 2023). Ofcom's highly effective age assurance (HEAA) requirements landed through 2024-2025 across the regulated service categories. UK platforms serving content harmful to minors have to ship HEAA-compliant verification, and the consequence chain (fines up to 10% of global turnover, service-blocking orders) has produced an enforcement posture similar to the DSA's but in a different legal framework.

Other Member States in pilot or draft. Spain has a draft age-verification law under parliamentary consideration; Italy and Germany are advancing through respective implementing-act processes. The European Commission's age-verification blueprint consolidates these into a reference architecture, and the pilot Member States running it in 2026 are France, Denmark, Greece, Italy, Spain, Cyprus, and Ireland — all planning to integrate the EU Age Verification Solution into their national EUDI Wallets.

A streaming-platform integrator we work with asked us last quarter how to ship one age-verification flow that satisfies the French SREN, Spanish draft law, and UK HEAA simultaneously. The answer is that you can't, today, unless you're shipping the EU Age Verification Solution and its wallet-based attribute — at which point you satisfy France, Spain, and most other Member States in one architecture, and you address UK HEAA separately because the UK is outside the EUDI Wallet framework.

What does the EUDI Wallet age attribute add in 2026?

A privacy-preserving, predicate-based answer that the platform can verify without seeing the user's date of birth.

The EU Age Verification Solution is the technical implementation the European Commission has shipped as a reference platform, aligned with the EUDI Wallet Architecture Reference Framework. The mechanism is straightforward: the user's EUDI Wallet holds a verifiable credential issued by the Member State or an authorised issuer, attesting to the user's birth date. When the user accesses an age-gated service, the wallet generates a predicate proof of the form "the holder is over [threshold]" — yes or no — without revealing the underlying birth date. The platform receives only the predicate truth value.

This is the selective-disclosure mechanism that the Zero-Knowledge product page covers from the technical angle (see also our earlier post on zero-knowledge proofs). The current EUDI Wallet implementation uses SD-JWT under RFC 9901; the BBS+ end-state (proper predicate proofs, unlinkable across presentations) is planned for 2027+. In the interim, the SD-JWT version still discloses less than a full ID document scan — birth date is hidden, only the over-18 boolean is revealed — but does leave a digest fingerprint that the platform could correlate across presentations if it tried to.

For platforms shipping in 2026, the operational question is whether to integrate the EU Age Verification Solution now or wait for the BBS+ end-state. From inside the compliance audit, the question that always comes up is which method satisfies the current regulator's "appropriate and proportionate" test, and the answer landing in 2026 is increasingly: the wallet-based attribute, in either its SD-JWT or future BBS+ form. Self-declaration is failing the test; document-scan-based verification is satisfying the test but with higher data-protection cost (and proportionality questions that are starting to land in DPA decisions).

Age verification methods funnel — from full document scan at the top (most data revealed, highest friction, decreasing privacy and proportionality compliance) down to BBS+ predicate proof at the bottom (only predicate truth revealed, lowest friction, highest privacy and DSA Article 28 proportionality compliance).

The architectural reading the EU has converged on is that age verification, like every other identity-attribute question, should answer the predicate the verifier needs (over 18: yes/no) rather than disclose the underlying data (the birth date). The wallet-based mechanism is a form of attribute authentication rather than full identity authentication — the platform learns one truth value, not the user's identity. The platforms that ship against this reading in 2026 are positioned for the regulatory regime that's emerging. The platforms that keep asking users for ID uploads are answering yesterday's question.

What this means for platforms shipping today

The trap most platforms walk into is treating age verification as a one-time procurement decision against today's law. The regulatory wave is layered: DSA Article 28 sets the European floor, Member State laws raise it locally, the EU Age Verification Solution provides a harmonised technical answer, and the EUDI Wallet integration over 2026-2027 is what makes the harmonised answer actually portable.

What I'd recommend any platform-side compliance lead is to start with the layered map: what does DSA Article 28 require for our service category, what do the Member States we serve already mandate, and what does the EU Age Verification Solution cover for the pilot Member States. The answer for an EU-serving platform in 2026 is usually: ship the EU Age Verification Solution's wallet integration against the pilot Member States, document the SD-JWT-to-BBS+ migration plan, and keep the document-scan flow as a fallback for users who don't yet have an EUDI Wallet credential.

What I'd push back on hardest in the "just use selfie age estimation" pitch is that age-estimation tools are best-effort, not predicate-grade. They produce a probability score, not a verifiable claim. Under DSA Article 28's "appropriate and proportionate" standard, that score is acceptable for low-risk content categories but doesn't survive scrutiny for higher-risk ones — particularly under French SREN or UK HEAA tests. The platforms shipping against the regulatory wave in 2026 are converging on verifiable predicate proofs as the age-authentication primitive, not on estimation.

The IdentiGate angle here sits in the Identity Verification product for the foundation-layer chip-anchored proofing that issues the underlying attestation (in cases where the wallet credential is provisioned from a document chip read) and in the Zero-Knowledge product for the predicate-proof presentation layer. We do not issue EUDI Wallets — those are Member State infrastructure — but we ship the primitives that make the wallet's attestation verifiable independently and the platform's verification of the attribute defensible at audit.

The honest read is that in 2026, "do you have to verify every time" is the wrong question. The right question is whether your platform is wired to consume the wallet-based attribute when the user presents it, and to fall back to document-scan only when the user lacks a wallet credential. Get that wiring right and the user stops getting asked. Get it wrong and the platform stays in a regulatory grey zone that's actively tightening.

Sources

Primary — DSA and EU age-verification framework

Primary — selective-disclosure standards

RFC 9901 — Selective Disclosure for JSON Web Tokens (IETF, November 2025)

Primary — Member State and adjacent-jurisdiction frameworks

About the author

Mairi Kutberg is co-founder of IdentiGate. She focuses on identity-proofing operations under eIDAS, NIS2, AMLR, the AI Act, the EHDS, and adjacent regulatory frameworks, and on the institutional reality of running cross-border identity verification at scale.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.