If you run a UK-facing service where age matters, you have probably heard three phrases thrown together: Digital Economy Act, age-appropriate design, and online safety. They are related, but they are not the same law. Treating them as one checkbox is how teams over-collect ID and under-document their decision.
Consider a regional news publisher that adds a comments section. Product wants a frictionless signup. Legal wants to know whether commenters are over 18. Engineering is asked to "turn on age verification" by Friday. Nobody has written down which law applies, what threshold they need, or what evidence they must keep. That is the moment mistakes get baked in.
The three layers most teams actually hit
Each layer answers a slightly different question. Part 3 asks whether you have gated harmful material. The Children's Code asks whether your defaults protect children who might still find your app. Sector regulators ask whether your method matches the harm you could cause if you get it wrong. A single vendor contract rarely maps cleanly onto all three.
What the Digital Economy Act actually asks
Part 3 of the Digital Economy Act sets out duties for providers of age-restricted material. The practical ask is straightforward: take age assurance seriously before you grant access. It does not prescribe one vendor or one biometric stack. It expects you to use measures that are appropriate to risk.
For many businesses that means defining the age threshold (16, 18, or 21) for each product surface, picking an assurance method you can defend, and keeping evidence that a check happened without necessarily keeping the document image forever.
- Define the age threshold for each product surface.
- Pick an assurance method you can defend (document, attribute, or trusted third-party signal).
- Keep evidence that a check happened, without necessarily keeping the document image.
- Review when the product changes (new region, new feature, new data sharing).
Plain-language takeaway: the law cares that you checked, and that you can show how. It does not require you to ship every user's passport to a hosted bureau.
Where the Children's Code fits
The ICO's Age Appropriate Design Code applies when your online service is likely to be accessed by children. Standard 3 is often the one product teams feel first: age-appropriate application. You need a clear view of the age range of your users, and defaults that protect children.
That pushes you toward age assurance at onboarding or at the point where behaviour changes. Messaging strangers, sharing location, or enabling payments are all moments where "we think they are adults" stops being good enough. Again, the code is about outcomes and data minimisation, not about picking the flashiest ID scanner.
Regulators rarely ask which algorithm you used. They ask what you knew, when you knew it, and what you did with that knowledge.
Sector rules add another gear
Gambling operators, alcohol delivery apps, and social platforms each carry sector-specific guidance on evidence and retention. A method that satisfies a low-risk publisher may not satisfy a remote casino. Read your sector code alongside the general duties, not instead of them.
| Context | Typical threshold | Evidence expectation |
|---|---|---|
| News comments | 18 | Proportionate attribute or document check |
| Social messaging | 13 / 16 / 18 by feature | Age band or assurance at feature gate |
| Remote gambling | 18 | Stricter identity evidence, audit trail |
| Alcohol delivery | 18 | Check at order and delivery where required |
What good looks like in practice
A defensible UK age assurance path usually has four properties. Proportionality means a news site and a gambling operator do not need the same rigour. Minimisation means collecting the smallest attribute that answers the question (over 18: yes or no). Auditability means retaining a signed record that a check occurred, with timestamp and method. Review means re-checking when risk changes, such as account takeover, jurisdiction change, or product change.
Tools like Age Pass exist to prove eligibility on the host that already holds the relationship, so you are not building a parallel ID warehouse. For the wider compliance picture, see Compliance and How it Works.
On the host
The prove step
Where AffixIO fits in your age assurance stack
The age question is usually already answerable from records you hold. AffixIO is the prove step on that host, not a bureau you send passports to.
- StaysYour host
- Runs hereProve
- LeavesSigned over-18
It sits on the onboarding service, CRM, or membership database that already holds the account. When a user hits an age gate, prove runs against fields already in that system. The gate gets a signed over-18 yes or no. The document image does not need to leave for every check.
What stays on the host
- The record. Date of birth, account flags, or prior checks remain in systems you already assessed for a DPIA.
- The method. Age Pass stores a signed outcome beside the account, not a scan in a third-party vault.
- Offline coverage. Branch tablets and pop-up events can queue a signed result if the link drops mid-check.
- Audit material. ML-DSA-65 signatures bind method and time without keeping the document.
What the gate receives
- A yes or no. Eligible for this surface, at this threshold, at this time.
- A signature. Verifiers check the outcome without a copy of the ID.
- A repeatable call. The same person can hit another feature gate without a fresh document capture.
- Nothing extra. Marketing lists, scans, and bureau reference IDs are not part of the export.
What this article does not claim
This is guidance, not legal advice. AffixIO does not certify your compliance. Your DPO, counsel, and sector regulator remain the final word. We document how eligibility proof can be returned as a signed yes or no with minimal data movement.