Age assurance after one year: privacy, accuracy and enforcement

At a glance

What this is: This is Yoti's one-year analysis of age assurance under the Online Safety Act, with the key finding that privacy-preserving age checks can be deployed at scale and are starting to show measurable safety impact.

Why it matters: It matters because identity verification teams, platform security leads, and privacy officers need controls that prove age without over-collecting personal data or creating weak, easy-to-bypass enforcement paths.

By the numbers:

• Ofcom found that only 5% of children reported using a VPN to access older-age content or restricted features.
• Ofcom found that 87% of children's recorded visits to pornography services lasted less than 30 seconds.
• Internet Matters found that around 68% of children had noticed more safety measures, including better reporting tools and content filters.

👉 Read Yoti's analysis of age assurance one year after the Online Safety Act

Context

Age assurance is the practice of checking whether a user meets an age threshold without collecting more personal data than the service actually needs. In this case, the central governance problem is not just compliance with the Online Safety Act, but proving that age checks can be privacy-preserving, accurate, and hard to bypass at the same time. That makes the topic relevant to identity verification teams and to IAM programmes that already separate proof of eligibility from full identity disclosure.

A year into broader deployment, the debate has moved from whether age checks are possible to how they should be implemented across different service types. Social media, gaming, adult content, and online community platforms do not carry the same risk profile, so the control design cannot be one-size-fits-all. For identity and privacy teams, the important question is whether the assurance method creates a narrow, proportional signal or an unnecessary identity collection exercise.

Key questions

Q: How should security teams implement age assurance without collecting too much personal data?

A: Start with the minimum proof the service needs, then design the workflow so the platform receives only an age result or threshold assertion. Separate age assurance from full identity verification, limit retention, and avoid turning routine access checks into document collection exercises. That reduces privacy risk while preserving a usable control for age-restricted services.

Q: Why do age checks fail when platforms rely on weak inputs?

A: They fail because the control becomes easy to satisfy with spoofed images, replayed video, borrowed credentials, or other low-quality signals. A check that is not bound to the person completing it can still return a technically correct answer while allowing the wrong user through. That is an assurance failure, not just a user experience issue.

Q: What do security and identity teams get wrong about age verification?

A: They often treat it as a one-time onboarding check instead of an ongoing governance process with evidence, testing, and jurisdiction-specific rules. That approach misses auditability, model drift, and threshold ambiguity, which are the points most likely to create compliance failure in production.

Q: Who is accountable when age checks are inaccurate or easily bypassed?

A: The platform operator remains accountable for how the age control is designed, tested, and enforced, even when a third-party provider supplies the technology. Relevant accountability also extends to privacy, safety, and accessibility outcomes. That means governance teams should own the assurance threshold, evidence, and review process, not outsource responsibility with the tool.

Technical breakdown

Privacy-preserving age assurance versus full identity verification

Age assurance answers a limited question, such as whether a person is over 18, while identity verification tries to establish who that person is. That distinction matters because a platform often only needs an eligibility signal, not a name, document number, or date of birth. Techniques such as facial age estimation and reusable digital ID reduce the amount of personal data transmitted to the service. The control challenge is to ensure the age result is trustworthy without turning every age check into a full identity transaction.

Practical implication: design the check around the minimum proof the service needs, not the maximum identity detail the user could provide.

Bypass resistance, liveness, and false-input defence

Age checks fail when the control accepts fake inputs, replayed media, or borrowed credentials as if they were genuine proof. Liveness checks are one way to reduce that risk in facial age estimation because they test whether a real person is present rather than an image or recorded video. For digital ID, the issue is whether the age assertion is bound to the person completing the check and cannot be trivially reused. In practice, enforcement quality depends on resisting low-effort circumvention, not eliminating every possible workaround.

Practical implication: test age assurance against spoofing and replay, not just against functional success cases.

Independent benchmarking and fairness in age estimation

Accuracy in age assurance is not only about overall pass rates. It also includes fairness across different groups, resilience under varied conditions, and consistency when the system is deployed at scale. Independent benchmarking helps platforms compare how methods perform across these dimensions instead of relying on vendor claims alone. For online safety programmes, this matters because a control that performs unevenly can create exclusion, friction, or blind spots that weaken trust in the whole policy.

Practical implication: require independent performance testing before using age assurance in regulated or high-friction user journeys.

Threat narrative

Attacker objective: The objective is to bypass age controls and access restricted content or features without providing trustworthy age evidence.

1. Entry occurs when a user attempts to reach age-restricted content through low-friction circumvention, such as a VPN or spoofed input.
2. Escalation happens when the platform accepts weak age evidence, allowing the user to bypass the intended age gate without strong proof binding.
3. Impact is the exposure of age-restricted services to underage access, which undermines safety controls and weakens regulatory confidence in the programme.

NHI Mgmt Group analysis

Age assurance is becoming an identity governance problem, not just a compliance feature. The article shows that platforms are no longer debating whether to ask for age, but how to do so without over-collecting identity data. That is a familiar governance issue for IAM and identity verification teams: the control must prove eligibility, not expand disclosure. The practical conclusion is that age assurance policies now need data minimisation, binding, and assurance-level decisions, not just product selection.

Verification trust gap: the real risk is not whether age checks exist, but whether they are strong enough to resist casual bypass. The article's evidence points to enforcement quality, not theoretical capability, as the deciding factor. That mirrors a broader identity governance pattern where controls that are easy to satisfy with weak inputs create paper compliance. The practical conclusion is that teams should measure how often an age check is binding the right user, not simply how many checks are completed.

Privacy-preserving proof is now the default expectation for high-volume identity assertions. The article makes clear that users and regulators both reject unnecessary disclosure when a simple threshold result is enough. That aligns with privacy-by-design and with least-privilege thinking in IAM: collect the smallest usable assertion, then limit retention and reuse. The practical conclusion is that identity programmes should treat age assurance as an attribute assertion problem, not a document collection exercise.

Age assurance introduces a distinct control class that sits between identity verification and content moderation. The article shows that the platform is not proving legal identity, but also cannot rely on content filters alone. That creates a named governance gap: the age verification boundary. Teams need a clear model for where age assurance ends, where identity verification begins, and how the two are separated in policy and logging. The practical conclusion is to define that boundary explicitly before scaling the control across services.

What this signals

Age assurance programmes will increasingly be judged on evidence quality rather than policy intent. Platforms that can prove low-disclosure age checks, binding to the right subject, and measurable resistance to bypass will have a stronger governance position than those relying on broad identity collection or behavioural inference alone.

Verification trust gap: this is the point where identity verification, privacy engineering, and product policy intersect. Teams should expect more scrutiny of how age results are generated, retained, and reused, especially where the same identity signals might otherwise be repurposed across access, fraud, or trust-and-safety workflows.

For practitioners

• Define the age assurance boundary Separate age confirmation from identity verification in policy, data flows, and logging so the platform only collects the minimum assertion needed for the service.
• Test controls against circumvention Assess whether liveness checks, digital ID assertions, and age-estimation methods can resist spoofing, replay, and VPN-assisted bypass attempts.
• Require independent benchmarking Use external testing to validate accuracy, fairness, accessibility, and security before rolling age assurance into regulated journeys.
• Review retention and reuse rules Limit how long age-related signals are stored and prevent them from becoming reusable identity data outside the original purpose.

Key takeaways

• Age assurance now sits at the intersection of identity verification, privacy, and online safety, so the control design matters as much as the policy mandate.
• The evidence shows that well-implemented checks can reduce casual bypass and improve user safety, but weak inputs and poor binding still undermine trust.
• Practitioners should treat age assurance as a minimum-disclosure assertion problem, then test it for accuracy, accessibility, and circumvention resistance.

Key terms

• Age Assurance: Age assurance is the set of controls used to determine whether a person can access content or services restricted by age. It can include document checks, biometrics, in-band verification and decision logging, but the governance requirement is the same: the organisation must be able to justify the outcome.
• Privacy-Preserving Identity Verification: Privacy-preserving identity verification is a design approach that confirms a specific attribute or entitlement while revealing as little personal data as possible. It is used when the service needs proof of eligibility, not a full identity profile, and it reduces exposure, retention risk, and unnecessary data sharing.
• Liveness Detection: Liveness detection is the mechanism that checks whether a biometric sample comes from a real, present person rather than a spoof such as a photo, screen, or mask. In identity programmes, it is a core defence against presentation attacks and should be tested under realistic operating conditions.
• Attribute Assertion: An attribute assertion is a statement that confirms a specific characteristic about a person, such as being over 18, without sharing unrelated personal details. It is useful where the receiving service only needs a narrow trust signal rather than a complete identity record.

What's in the full article

Yoti's full article covers the operational detail this post intentionally leaves for the source:

• How Ofcom and the ICO guidance shapes practical age-assurance implementation choices
• Which privacy-preserving methods are being used to prove age without full identity disclosure
• What the evidence says about bypass resistance, fairness, and independent benchmarking
• How platforms are adapting age checks across different service types and risk profiles

👉 Yoti's full article covers the evidence on bypass, privacy, accuracy, and platform implementation patterns.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, identity lifecycle, and secrets management for practitioners building stronger identity controls. It helps security and identity teams translate governance intent into operational decisions across modern access programmes.