The UK's Information Commissioner's Office called on technology platforms to strengthen age checks in a March 12, 2026 open letter. The announcement distinguishes enforcing minimum ages from protecting children allowed to use a service. Those are related tasks, but the second does not disappear when the first is addressed.
An age-assurance result concerns a person's age or age range for a particular purpose. It does not, on its own, establish who can view the person's profile, whether location is shared or how later activity is used. A successful check therefore cannot serve as a complete description of what happens to information after entry.
The March account says the ICO contacted major platforms about their approaches and urged movement beyond reliance on users declaring their own age. Contact from a regulator is not itself a finding against every recipient. Nor does the announcement establish that all requested changes were implemented later. Its date matters when assessing what the record actually demonstrates.
Entry and experience
Imagine a fictional service that reliably places a teenager in the correct age range but then assigns public profile settings. Now imagine a second service with restrictive profile defaults but an inaccurate age process. The examples isolate different properties; neither is a claim about any named platform or a complete compliance assessment.
Measuring the accuracy of entry checks would not resolve the visibility question in the first example. Examining default settings would not establish the accuracy of age assessment in the second. A single label such as child-safe would conceal which observation had actually been made.
The ICO's December 2025 Children's Code strategy update describes work on default privacy settings, geolocation, advertising profiling and recommender systems. It separately discusses age-assurance activity. These categories show that the regulator's programme examined more than the moment of registration. The update is a dated account of that work, not a current audit of every platform's September 2026 settings.
Defaults and later choices also answer different questions. A default describes the state presented before a person changes a control. A record of later settings describes a subsequent state. In the fictional service, observing one teenager's changed profile would not establish the default received by every new user. Conversely, documenting the default would not show that all users retained it.
That distinction affects the interpretation of progress claims. A commitment is evidence of an intended action. A release record can show that a feature was introduced. Observations of users' settings or data flows would be needed to describe its operation. Counting commitments as completed changes would collapse those stages.
The two cited records come from the ICO and concern different reporting dates. They do not supply independent testing of the fictional services, later compliance findings against every platform contacted, or a new estimate of affected children in September.
The narrower conclusion is methodological: age assurance, default settings and subsequent handling each need evidence matched to the question. The March letter and December progress account explain why the regulator addresses those questions separately. They do not establish that checking age alone resolves the entire privacy experience of a child who uses a service.