Online Safety Act Age Assurance

Highly effective age assurance (HEAA) is Ofcom's standard under the UK Online Safety Act. Methods must be technically accurate, robust, reliable, and fair. Self-declaration without additional measures does not count as age verification or estimation.

This guide is for product, legal, and engineering teams evaluating age assurance under the UK Online Safety Act. It maps Ofcom's highly effective age assurance (HEAA) criteria to verification architecture choices. It is not legal advice.

Who is in scope

Ofcom distinguishes service types with different duties. Your children's access assessment determines how strict age assurance must be for harmful content categories.

• Part 5: services that publish their own pornographic content must use age verification or estimation for all users.
• Part 3: user-to-user and search services likely accessed by children must implement proportionate safety measures, including HEAA where the risk assessment requires it.
• Generative AI: tools that host or generate adult content may fall under Part 5 publisher duties depending on product design.
• Retail and hospitality: offline age gates share the same architectural question: prove a threshold without hoarding identity at every till.

Part 3 vs Part 5 at a glance

Part 3 UGC and search

Children's access assessment first. HEAA applies where harmful content risk is material.

Part 5 publishers

Age assurance for all users accessing pornographic content you publish.

Shared HEAA bar

Both paths require methods that are accurate, robust, reliable, and fair.

Data minimisation

Platforms still owe GDPR duties. Fewer identity copies at the verifier reduces breach scope.

Ofcom four criteria for HEAA

Ofcom has not published fixed pass percentages. Buyers document how their chosen method meets each criterion in the children's access assessment and risk management records.

1. Technically accurate at correctly determining child vs adult for your service context, including edge cases such as shared devices and VPN use.
2. Robust against circumvention appropriate to your risk level. A low-risk forum and a high-risk live stream need different controls.
3. Reliable under normal operating conditions, peak load, and partial outages. Gate failure modes must be documented.
4. Fair to users, including accessibility, appeal routes, and proportionate friction for low-risk journeys.

Age assurance methods compared

Method	Typical data held	AffixIO-compatible path
Self-declaration	Excluded from counting as verification	Not sufficient alone under the Act
Document upload at platform	Full ID images stored at content provider	Witness upstream, YES or NO at boundary
Bank-derived age	Third-party signal, often retained	Threshold proof without exporting DOB
Facial age estimation	Biometric processing at vendor	Policy gate consumes vendor attestation
Zero-knowledge threshold	Cryptographic over-18 proof	Signed outcome with Merkle audit

Implementation checklist for engineering

1. Document which Part 3 or Part 5 duties apply and link to the children's access assessment.
2. Select an age assurance method and score it against the four HEAA criteria using the age assurance scorer.
3. Define the gate question as a signed YES or NO outcome, not a standing profile at the content provider.
4. Keep date of birth and document images at the issuer or user wallet where possible.
5. Log decisions with tamper-evident audit metadata regulators can replay. See proof-not-log audit.
6. Test failure modes: expired proofs, denied appeals, and offline venue scans if applicable.
7. Prepare Ofcom information request packs: method rationale, accuracy evidence, and retention map.
8. Run the OSA scope checker and reproduce a sandbox age flow before procurement sign-off.

What auditors and Ofcom will ask

• Which age assurance method you selected and why it fits your children's access assessment.
• Accuracy and robustness evidence for that method in your service context.
• Whether you retain unnecessary identity data at the content provider or integrator.
• How users appeal incorrect age decisions and how those appeals are logged.
• How you evidence gate decisions during Ofcom information requests without exporting PII to auditors.

How AffixIO fits the architecture

AffixIO is verification infrastructure at the platform boundary. It returns a signed eligibility outcome with Merkle audit metadata. Date of birth and document images stay at the issuer by default. You may still use document or bank-derived witnesses upstream; AffixIO evaluates the policy and returns YES or NO.

Read the privacy-preserving age check product page, the Online Safety field note, and the age check vs ID upload comparison.

Frequently asked questions

Is self-declared age enough?

No. The Act excludes self-declaration without additional measures from counting as age verification or estimation.

Can we avoid storing date of birth?

Yes. Zero-knowledge threshold proofs can return over-18 without exporting DOB to the platform.

Does AffixIO replace an age verification vendor?

It provides the verification boundary. You may still use document or bank-derived witnesses upstream.

What is a children's access assessment?

Part 3 services must assess whether children access the service and what harmful content risks follow. It drives how strict age assurance must be.

Does HEAA require facial scanning?

No single method is mandated. Ofcom requires fitness to context against the four criteria.

How do we evidence HEAA to Ofcom?

Document method choice, accuracy evidence, retention map, and reproducible gate outcomes. Merkle audit supports replay.

Can age checks work offline?

Yes. QR credentials can verify at venue gates without live API calls. See offline gate verification.

What is AffixIO's role vs an age vendor?

Age vendors establish identity signals. AffixIO evaluates policy at the boundary and returns signed YES or NO.