Is a date-of-birth field ever acceptable?

As a friction-free UX nicety, sometimes. As compliance with any modern age-assurance duty, no. Self-declaration fails on accuracy, robustness and reliability simultaneously, which is why regulators name it explicitly as insufficient rather than leaving it to interpretation. If your only gate is a form field, assume you have no gate.

Do we need to verify every user, or only some?

It depends on what the user can reach. Many platforms scope assurance to the actions that trigger the duty rather than to signup, which reduces friction and keeps the compliance boundary crisp. The trap is scoping too narrowly and leaving a path to restricted functionality that never passes the gate — audit by route, not by intention.

How do we handle users who cannot verify?

Fairness is an explicit criterion in the UK's test, so 'they simply cannot use the service' is a weak answer if your single method excludes a predictable group. Offering more than one route — an ID check, a facial estimation option, an operator or bank-backed signal — is both better compliance and better product. Design for the person without a credit card.

Does verifying once cover us forever?

Not comfortably. Accounts get shared, sold and handed down, and a verification from two years ago says little about who is at the keyboard today. Sensible designs re-verify at intervals or on risk signals such as a new device, a new country, or a long dormant period.

What if we are a B2B API with no consumer users?

The duty usually follows the end user rather than the contracting party, so an API whose output reaches consumers does not escape by being sold to businesses. What changes is where the check sits. Either you verify the end user or your customer does and attests to it — and if it is the latter, that attestation needs to be a term you can actually enforce and evidence.

News8 August 20266 min read

Age Verification Law in 2026: What Platforms Face Now

Age verification law is now enforced in the UK, US states and the EU. What applies to your platform — and what to build first if you're behind.

By LikeWard Compliance Desk

Documents and identification paperwork on a desk, illustrating how age verification law now applies to platforms

Photo via Unsplash

Age verification law spent a decade as a debate about feasibility. That debate is over. The UK has an enforced regime with a regulator and revenue-based penalties, a large and growing number of US states have their own statutes, and the EU has been pushing minors-protection expectations through the Digital Services Act. If your platform hosts adult or age-restricted material, the question is no longer whether to build a gate but which gate survives scrutiny.

This piece summarises where things stand in August 2026, what the differences between regimes mean for architecture, and what to build first if you are behind.

The short version

Self-declaration is dead everywhere that matters.

The UK standard is outcome-based: accurate, robust, reliable, fair.

US state statutes vary in trigger and remedy — private rights of action are the sharp edge.

Search interest tracks enforcement, not legislation: "age verification law" averages 1,900 US searches a month.

Fail-closed is the only defensible default.

Why this became urgent

Two things converged. Regulators acquired enforcement powers rather than guidance-issuing roles, and age-assurance technology got good enough that "impossible" stopped being credible.

The search data tracks the shift rather neatly. A Google Ads Keyword Planner run we made in August 2026 puts "age verification law" at an average of 1,900 US searches a month with a competition index of 1, and shows a marked spike in mid-2025 — precisely when UK enforcement began in earnest. People search statutes when statutes start affecting them.

The UK: an outcome-based standard

The Online Safety Act 2023 requires services publishing or hosting pornographic content to use highly effective age assurance. Ofcom has framed that as four properties: technically accurate, robust, reliable and fair.

Notably, no approved vendor list. You choose the method and you defend it. Facial age estimation, photo ID, credit-card checks, mobile-operator signals and digital identity wallets have all been discussed as capable of meeting the bar when implemented properly. A date-of-birth box meets none of it.

Penalties reach £18 million or 10% of qualifying worldwide revenue, and Ofcom holds business disruption powers aimed at payment and ancillary providers. We went through the full duty set in the UK Online Safety Act deep-dive.

The criterion people underweight is fairness. A method that works poorly for a predictable group is a compliance problem, not an acceptable trade-off. Practically, that argues for offering more than one route.

The US: a patchwork with teeth

There is no single federal age-verification statute. Instead, a growing set of state laws, differing on three axes that actually change your build:

Axis	Variation	What it changes
Trigger	Share of site content that is adult material	Whether you are in scope at all
Method	Some name acceptable categories; some say "commercially reasonable"	How much latitude you have
Remedy	Attorney-general enforcement, private right of action, or both	Your realistic risk exposure
Data handling	Some prohibit retention of identity documents	Your vendor architecture

Table: the four axes on which US state age-verification statutes differ, and the design decision each one drives. Scope and remedy matter more than the method language.

Private rights of action are the sharp edge. Regulator enforcement is finite and prioritised; private litigation is neither. And the data-retention restrictions in several statutes point the same way as good practice anyway: verify through a provider, keep the result, do not keep the document.

Separately, the TAKE IT DOWN Act — federal, FTC-enforced — imposes a 48-hour removal duty for non-consensual intimate imagery. It is not an age law, but it lands on the same platforms and the same engineering team. See the compliance guide.

The EU: minors protection via the DSA

The Digital Services Act does not prescribe an age-verification method either, but its obligations around protection of minors and risk mitigation for very large platforms push in the same direction, and the Commission has been developing guidance and age-verification approaches at EU level. If you serve the EU, the reasonable planning assumption is convergence rather than divergence.

What this means for AI platforms specifically

Generation platforms have a wrinkle that hosting platforms do not: there are two age questions.

Is the requester an adult? Standard age assurance on the account.
Is the depicted person an adult, and is the depiction of an adult? Different question entirely.

The second splits again. Creator identity and age must be verified at onboarding. And the content must never depict a minor regardless of who requested it — which is a content-evaluation problem, not an identity one.

LikeWard treats these as separate controls. Creator activation is gated on recorded identity evidence — a profile cannot go live without it. Generation refuses with age_verification_required when the requesting account is unverified. And minors contexts are one of four non-waivable platform prohibitions, evaluated before the age gate, so a prohibited request from a fully verified adult account is still refused.

That ordering matters more than it sounds. Evaluate prohibitions after the age gate and a verified adult becomes the exception that swallows the rule.

Choosing a method

Practical guidance rather than a vendor list:

Offer at least two routes. Fairness, and resilience when one provider has an outage.
Do not store documents. Store the verification result and the provider's reference.
Re-verify on risk signals. New device, new country, long dormancy.
Log the assurance state on the action, not just the account — so you can prove the check applied at the moment that mattered.
Fail closed. If the provider is down, refuse. An open gate during an outage is the gap that turns up in a review.

Build order if you are behind

Fail-closed gate on the restricted action. Even a single method beats none.
Audit by route. Find every path to restricted functionality; verify none bypasses the gate.
Second method. Fairness and resilience.
Record assurance state on each transaction. Evidence, not inference.
Re-verification policy. Written down.
Risk assessment. Cheap, and the first thing anyone asks for.

Mistakes we keep seeing

Gating signup instead of the action. Users arrive through deep links, invites and API paths.

Trusting a session forever. Sessions outlive the assumptions behind them.

One method only. Fails the fairness criterion and your uptime target simultaneously.

Storing ID documents. Restricted in several statutes, and a breach liability everywhere else.

Failing open during an outage. The single most common finding in reviews we hear about.

Assuming synthetic content is out of scope. It is not. Ask the unlicensed generation risk analysis how that argument goes.

Related reading: the UK Online Safety Act deep-dive, the deepfake law round-up, and the card network consent rules guide — because your acquirer will ask about age assurance too. LikeWard's own gate is described on the verification page.

Frequently asked questions

Is a date-of-birth field ever acceptable?: As a friction-free UX nicety, sometimes. As compliance with any modern age-assurance duty, no. Self-declaration fails on accuracy, robustness and reliability simultaneously, which is why regulators name it explicitly as insufficient rather than leaving it to interpretation. If your only gate is a form field, assume you have no gate.
Do we need to verify every user, or only some?: It depends on what the user can reach. Many platforms scope assurance to the actions that trigger the duty rather than to signup, which reduces friction and keeps the compliance boundary crisp. The trap is scoping too narrowly and leaving a path to restricted functionality that never passes the gate — audit by route, not by intention.
How do we handle users who cannot verify?: Fairness is an explicit criterion in the UK's test, so 'they simply cannot use the service' is a weak answer if your single method excludes a predictable group. Offering more than one route — an ID check, a facial estimation option, an operator or bank-backed signal — is both better compliance and better product. Design for the person without a credit card.
Does verifying once cover us forever?: Not comfortably. Accounts get shared, sold and handed down, and a verification from two years ago says little about who is at the keyboard today. Sensible designs re-verify at intervals or on risk signals such as a new device, a new country, or a long dormant period.
What if we are a B2B API with no consumer users?: The duty usually follows the end user rather than the contracting party, so an API whose output reaches consumers does not escape by being sold to businesses. What changes is where the check sits. Either you verify the end user or your customer does and attests to it — and if it is the latter, that attestation needs to be a term you can actually enforce and evidence.