How should platforms implement Ofcom’s children’s safety requirements without relying on weak age checks?

Why weak age checks fail against Ofcom’s safety model

Weak age checks usually fail because they treat children’s safety as a one-time gate rather than a continuing exposure problem. A service can still recommend harmful content, surface direct messages, host livestream abuse, or enable repeated re-entry through circumvention. The control objective is not merely to ask a user’s age, but to reduce the routes through which children can encounter harm.

That makes the design problem broader than age verification alone. Platforms need to understand which product surfaces create the risk, how children actually arrive there, and where a lightweight check can be bypassed, shared, or faked. Ofcom’s model pushes teams toward risk-based controls that match the service’s real harm pathways, not its sign-up form.

One practical implication is that a low-friction age prompt can be worse than useless if it creates false confidence while the rest of the product remains open. A safer approach is to align the intensity of age assurance with the level of risk and the likely harm mechanism, then re-test that decision as product behaviour changes.

What controls should map to the child-facing risk, not just the login screen?

Controls should be mapped to the exact ways children encounter harm on the platform: recommendations, search, messaging, livestreams, discovery surfaces, and any sharing or reposting path that can amplify exposure. Where the risk is higher, age assurance guidance becomes relevant because it explains the trade-off between age verification, age estimation, privacy, and circumvention resistance.

The control set should also include content restriction and product limitation, not just identity checks. If the risk stems from exposure to harmful material, then removal, down-ranking, friction, or feature restriction may be more effective than trying to prove age with a weak check. The answer depends on the harm path, not on whether the platform has a login wall.

For engineering teams, this usually means the age control is only one layer in a broader safety architecture. You still need moderation, detection, reporting, and periodic review of whether the chosen controls are being bypassed in practice. The control is working only if it changes exposure, not if it merely records a claim about age.

How should platforms keep the controls aligned to actual usage and circumvention patterns?

Platforms should treat children’s safety controls as a monitored system, not a static policy. The main operational question is whether the platform can detect when children are reaching harmful areas through account sharing, reused devices, false ages, alternative entry points, or product features the original assessment did not anticipate. If that picture changes, the control design should change with it.

Age-related controls also need regular review because product changes alter the threat surface. A new messaging feature, a change in recommendations, or a livestream launch can make a previously adequate control set incomplete. The service should therefore test whether the current controls still cover the actual paths of exposure and whether they remain proportionate to the risk.

That is why a risk assessment is not a paperwork exercise. It is the mechanism that tells the platform which surfaces need stronger assurance, where restriction is preferable to age gating, and when a product should be redesigned rather than lightly patched. A verification standard for authentication, validation, and access control is useful here as a reference point for making those controls more robust and testable.

Practitioner Guidance

What to prioritise: Start with the highest-risk child-facing surfaces, typically recommendations, direct messaging, livestreaming, and search, because those are the places where exposure can scale quickly even if onboarding checks look strong. If a surface can repeatedly reintroduce harm, it deserves stronger controls than a simple age prompt.

What to verify: Before trusting an age control, verify two things: it actually changes access to the risky feature, and it remains effective against realistic circumvention, including account sharing and re-entry from a different session or device. If neither can be shown, the control is too weak to support a safety decision.

What good looks like: The mature state is not “we check age”, but “we can explain which harms each control blocks, why that control level is proportionate, and how we know the control still works after product changes.” That is the standard that keeps safety aligned to the service, rather than to a policy slogan.

Practitioner takeaway: Weak age checks fail because they do not change the underlying exposure model. The right question is whether the platform can reduce children’s access to harmful pathways in a way that is proportionate, testable, and resilient to circumvention.

Related resources from NHI Mgmt Group

• How should platforms implement facial age estimation to meet online safety requirements without collecting more personal data than necessary?
• How should adult content platforms implement age checks to meet privacy and data minimisation requirements?
• How should platforms implement age assurance without over-blocking legitimate users?
• Why do age checks fail when platforms rely on weak inputs?