Choose an age check that fits the purpose
An age check should answer the question your service actually needs answered. Start with the applicable rule and risk, then choose a method, an acceptable error policy and a usable alternative. Collecting a full identity is not the automatic starting point.
The Commission's age-verification overview distinguishes its available technical solution from the September 2026 EU KIDS Act proposal. A proposal is not an enacted blanket Irish rule. Confirm the requirements applying to your particular service before setting a threshold.
Age assurance is a family of methods
Age assurance covers ways of establishing or assessing a person's age or age range. The methods vary in the evidence they use, the confidence they provide and the personal information they process. A birth-date field, facial estimate and issuer-backed over-18 result are not interchangeable simply because each produces an age-related answer.
Keep three questions separate: what rule or risk requires a decision, what method is suitable, and what information must the service receive? A method may use identity evidence during enrolment while presenting only a threshold result later. That separation is useful, but you still need to understand the complete data flow.
Compare the options
| Method | What it uses | What to examine |
|---|---|---|
| Declaration | An age or date entered by the user | Whether an unsupported statement is adequate |
| Inference | Signals interpreted as evidence of age | Accuracy, transparency and profiling effects |
| Estimation | A model's estimate, sometimes from a face | Uncertainty near the threshold and demographic performance |
| Document verification | Date of birth in identity evidence | Authenticity, holder matching and unnecessary disclosure |
| Reusable age credential | A statement issued after an earlier check | Issuer trust, availability, presentation checks and linkability |
This table is a decision aid, not a ranking. A method that is convenient for one population may exclude another. A service handling a different risk may need different evidence. Ask suppliers to explain the conditions under which their results are meaningful, including what the product does when it is uncertain.
Define the threshold and the consequences
Write the exact decision in plain language. Is the service deciding whether someone may access a restricted product, whether parental involvement is needed, or which experience to show? Then identify the legal or policy source, the accountable owner and the consequences of a wrong answer. Do not copy a competitor's threshold without understanding why it applies.
For an estimation system, decide how uncertain outcomes will be handled. A score is not a policy. Ask what happens near the boundary, which additional evidence may be requested and whether the person can appeal or use another route. Record false acceptance and false rejection separately because they represent different harms.
Request the smallest useful answer
If the decision is whether a person is above a threshold, ask why the service needs their full birth date, name or address. The European Data Protection Board's age-assurance statement is a useful privacy reference. Have your privacy lead apply it to the proposed flow rather than accepting a generic supplier assurance.
Look beyond the screen shown to the user. Can the provider connect checks across services? What does your support system retain? Are transaction identifiers reused for unrelated purposes? A minimal result on screen does not establish that the underlying processing is equally minimal. Ask for a data-flow diagram and review logs, retention and subcontractors.
Explain the check before asking for evidence. People should know who is making the request, what the result will be used for and how they can seek help. Avoid implying that a person is required to disclose a complete identity when the service has another suitable means of making its decision.
Where wallets fit
The EU's age-verification work describes a way to prove an age threshold without disclosing other identity details to the service. That creates an opportunity to separate the original proofing process from later age presentations. Actual availability, accepted issuers and integration support still need to be established for the service you intend to launch.
Ireland's Government Digital Wallet web verifier offers public information about test journeys, including threshold verification. It is useful for understanding the interaction. It does not, by itself, establish that a retailer, venue or platform has a production integration or meets its obligations by adding a QR code.
A wallet method also needs an alternative for people without the relevant app, credential or device. Ask the supplier how the two routes will coexist, whether their outcomes are comparable and how your staff will explain them. A technically elegant route used by a small subset of customers is only part of the service design.
Make mistakes recoverable
Test refusal, poor capture, interrupted sessions and the wrong credential. Examine whether a user understands what happened without exposing the detailed controls to an attacker. Provide a proportionate review route and make it accessible. An appeal that requires the same failed method again is not much of an alternative.
Include representative users and devices in an appropriately designed pilot. Keep the sample and limitations visible. Ask about differences in outcomes across relevant groups and environments, rather than reporting only an overall success percentage. Do not collect additional sensitive information casually in the name of measurement; agree the evaluation approach first.
Questions for the shortlist
- What evidence supports the result, and what does the result actually mean?
- How is performance measured at our chosen threshold?
- What information does each organisation see and retain?
- What happens when the method is uncertain or unavailable?
- Which current certificates, tests or assessments cover this exact configuration?
- How are complaints, corrections and supplier changes handled?
Turn the answers into acceptance criteria before a pilot. Measure legitimate completion, adverse outcomes, support effort and data exposure alongside price. Use our age-assurance procurement checklist for the next step, or the wallet demo checklist when assessing a proposed wallet connection.
In this topic: Age assurance
How should an organisation select an age-assurance method?
View all 9 pages in this topic
Keep up with the Irish evidence
Independent briefings on wallets, identity verification and age assurance.
Join the business briefing