What an Age Check Can Actually Know
This chapter examines the kinds of evidence behind age-assurance decisions and the standards used to judge them. The practical goal is to distinguish what a method can observe or verify from what an online service may safely conclude, then apply that distinction across privacy, fairness, and usability. Without it, a face scan, an identity document, a behavioural model, and a reusable credential can sound like interchangeable versions of the same thing when they are not.
The word “age check” encourages a misleading picture: a user presents something, a system returns yes or no, and the matter is settled. In reality, the input determines the kind of claim available at the output. A photograph of a document can support one kind of verification; an estimate based on a face supports another; a pattern of online behaviour supports a third. The process that interprets the input may also add thresholds, safeguards, and fallback routes. A reliable judgment starts by keeping these layers separate.
Four ways to make an age judgment
Ofcom uses “age assurance” as a collective term for age estimation and age verification. It distinguishes an age-assurance method—the technology or system underneath—from an age-assurance process, which is the end-to-end implementation of one or more methods. An age check is one instance of that process. The distinction is more than terminology. A method supplies evidence, while a process decides how much evidence is enough, what happens when it is uncertain, and which protection follows.
Consider age estimation first. A facial age-estimation system analyses features of a user’s face and produces an estimated age or age range. Its output is probabilistic: the system is not reading an age stored in the face. Even when the estimate is useful on average, individual outputs can be wrong, and the quality of the result can vary with the conditions under which the image is captured and the population represented in testing. A service using such a method therefore has to decide how to act on uncertainty, particularly when an estimated age is close to the boundary that matters for access.
Age verification makes a narrower but different claim. Ofcom defines it as a form of age assurance designed to verify the user’s exact age. Photo-ID matching is one example: relevant information is taken from an uploaded identity document and compared with an image of the user at the point of upload to verify that they are the same person. Other methods use a financial or institutional relationship as evidence. Open banking, credit-card checks, mobile-network-operator checks, and email-based age estimation may draw on records or signals associated with an account, payment instrument, network relationship, or trusted organisation. They do not all prove the same fact in the same way, and the service still has to understand what the result means.
The distinction between verification and estimation does not imply that exact verification is always preferable. Exactness may come with greater disclosure, a more intrusive user journey, or a dependency on a document or account that some people do not possess. Estimation may reduce the need to handle an identity document, but it can require careful treatment of uncertainty and demographic performance. The choice is therefore not a contest between a “real” method and an “imperfect” one. It is a decision about which evidence is proportionate to the risk and how the process will compensate for the evidence’s limits.
Age inference is different again. Ofcom describes it as a broad class of estimation techniques that typically analyse behavioural data, user interactions, or other signals—often called signals on a platform—to determine age. A service may ask a user to declare an age and then use activity and account-level information to infer whether the user is a child or an adult. The model may run repeatedly or continuously rather than at one visible moment. This can make the experience less disruptive and may allow a service to tailor protections across the platform, but it also means the determination depends on observation over time. The protection may arrive only after the service has seen enough behaviour to make an inference.
That timing matters. A method that requires a user to be active before it can infer age is not equivalent to a method that can gate access at the point of entry. It may be suitable as one part of a service-wide protection system, but the service must account for what happens before the inference is made and for users whose signals remain ambiguous. Ofcom did not include behavioural age inference in its non-exhaustive list of methods capable of being highly effective. It has nevertheless recognised that a provider may use it in a wider process if the provider can produce reliable evidence of its accuracy, robustness, timing, reliability, and fairness, while meeting data-protection obligations.
A reusable digital identity service changes the shape of the interaction rather than simply adding a fourth sensor. Ofcom defines digital identity services as systems that provide a reusable way to prove age or identity across multiple interactions. A wallet or credential may allow a user to share an attribute such as “over 18” without sharing every underlying identity detail. The service receiving the proof may learn less, and the user may avoid repeating a full check. But the result remains dependent on the original proof, the issuer, the credential’s security, and the rules governing reuse. Reusability reduces repetition; it does not by itself establish accuracy, privacy, or resistance to sharing.
These approaches can also be combined. A service might use a lower-friction signal for most users and request a stronger form of evidence in particular circumstances. It might use an age estimate to decide whether more evidence is needed, or use behavioural signals to identify accounts that warrant another check. Once methods are combined, the object being evaluated is the process. A strong component can be undermined by an unclear threshold, weak handoff, poor data handling, or a protection decision that arrives too late.
The following diagram captures the relationships without ranking the methods. Age assurance is the broad subject; a method is one underlying technique; a process implements one or more methods; and a check is a particular application of that process. The criteria apply primarily to the process as deployed, even though individual methods have their own performance characteristics.
This structure also explains why the same method can have different consequences in different services. A facial estimate used to decide whether to show a particular restricted feature is not the same intervention as a facial estimate placed before entry to an entire service. A reusable credential that reveals only adulthood is not the same as a credential that reveals identity and browsing history. The label names an ingredient; the process determines the practical result.
What “highly effective” asks of a process
Ofcom’s UK framework gives the word “effective” a more demanding meaning than “the software usually returns an answer.” Its guidance identifies four core criteria: technical accuracy, robustness, reliability, and fairness. It also asks services to consider accessibility and interoperability. Each criterion tests a different way an age-assurance process can fail.
Technical accuracy concerns whether a method can correctly determine a user’s age under test-lab conditions. It is the most familiar kind of performance claim: a vendor evaluates a system against a labelled dataset or controlled test and reports how often its outputs match the reference. Such testing is necessary, but it does not reproduce every condition of use. A camera may be different, a document may be damaged, the lighting may change, or the people using the service may not resemble the test population. Technical accuracy tells us what the method can do in a defined setting. It does not, alone, tell us what the deployed process will do to an actual user.
Robustness asks the next question: can the method correctly determine age in real deployment contexts? The shift from laboratory to deployment changes the problem. The service has to consider the devices, images, networks, user behaviour, and other conditions through which the method is encountered. It also has to consider attempts to manipulate the input or use someone else’s evidence. Robustness is therefore about the method in its operating environment, not only the algorithm under controlled conditions.
The distinction can be stated simply. Technical accuracy is a property observed under a test arrangement; robustness is a property observed when the arrangement meets the real world. A vendor can report excellent laboratory results while a service still has an exposed gate, a poorly configured threshold, or a process that accepts a signal in circumstances the test never covered. Conversely, a robust process may combine methods and safeguards in a way that manages the limitations of an individual component. The question is not whether laboratory accuracy matters. It is whether the process has earned a claim beyond the laboratory.
Reliability concerns whether the age output is reproducible and derived from trustworthy evidence. Reproducibility matters because a decision should not change unpredictably when the relevant circumstances have not changed. Trustworthy evidence matters because a polished output can still be based on an unreliable document, an unvalidated signal, or a data source whose origin and quality the service cannot explain. Reliability therefore includes the evidence chain behind the answer, not just the consistency of a software routine.
Fairness asks whether the method avoids or minimises bias and discriminatory outcomes. An overall accuracy figure can hide meaningful differences among demographic groups. A process may work well on average while producing more errors for particular users because of the data used to train or test it, the conditions under which images are captured, or the way the service handles uncertain results. A fairness claim is stronger when a service can explain which populations were included in evaluation, how those populations were represented, and what it will do when meaningful differences emerge. Without that information, a single average accuracy figure cannot show whether the process works equitably for the people who encounter it.
The two supporting principles extend the criteria beyond model performance. Accessibility means that age assurance should be easy to use and work for all users, regardless of their characteristics or membership of a particular group. Offering more than one method can help a person who lacks a formal identity document or cannot complete one particular flow. Clear instructions, device and browser compatibility, assistive-technology support, and human help can also matter. Accessibility is not a promise that every method will be effortless. It is a requirement that the whole process not make a narrow assumption about what every user can provide or operate.
Interoperability means that systems can communicate using common and standardised formats. It is relevant when a user should be able to reuse an age credential across services, or when an account, operating system, digital identity provider, and relying service need to exchange a trustworthy result. Interoperability can reduce repeated checks and make a process less burdensome, but it also creates dependencies. A shared format does not settle who may issue a credential, how it is revoked, whether its use is linkable, or what happens when an issuer changes its practices. Compatibility is an infrastructure property, not a guarantee of privacy or safety.
These criteria are related but not substitutable. A process can be technically accurate but inaccessible. It can be accessible but weak against manipulation. It can be robust in one environment but lack reliable evidence about another. It can be fair in a test but opaque about the data it uses in production. Treating one strong metric as a proxy for all six questions is precisely the category error the framework is designed to prevent.
The phrase “capable of being highly effective” is equally important. Ofcom lists seven method types that it considers capable of being highly effective, including financial and network checks, photo-ID matching, facial age estimation, email-based estimation, and digital identity services. “Capable” describes a class of method under suitable conditions. It does not certify every vendor, configuration, threshold, user journey, or service outcome. The burden remains on the service to show that the method is implemented in a way that meets the criteria.
Nor should a method judged suitable for one age threshold be assumed to answer every other age question. The Ofcom report focuses on whether a person is 18 or above for the duties covered by the UK Online Safety Act. It does not assess the enforcement of minimum ages such as 13 or 16. A change in threshold can alter the difficulty of the decision, the consequences of error, and the kind of evidence that is proportionate. “Over 18” is not a universal synonym for “old enough for any service.”
The FTC’s COPPA policy illustrates a different boundary. COPPA is concerned with the collection, use, and disclosure of personal information from children under 13 and with verifiable parental consent. The FTC’s enforcement statement addresses relevant mixed-audience and general-audience operators that want to determine whether a user is a child or older user. Under the statement, the FTC says it will exercise enforcement discretion for information collected for age-determination purposes without prior verifiable parental consent only when the operator follows conditions such as purpose limitation, appropriate third-party safeguards, prompt deletion, notice, security, and reasonable accuracy. The statement does not change the position that a primarily child-directed service must treat all users as children, and a general-audience service that learns a user is a child remains subject to COPPA’s other requirements.
This is not the same project as Ofcom’s HEAA framework. Ofcom’s report evaluates age assurance in relation to duties intended to protect children from harmful content and focuses on an over-18 boundary. The FTC statement is an enforcement position within a child-privacy regime and its own operator categories. One should not use the FTC’s permission to collect limited information for a defined age purpose as a universal approval of identity collection, nor read Ofcom’s list of capable methods as a general rule for COPPA compliance. The legal purpose determines what the process is trying to establish; the technical criteria determine how carefully it should be built.
The useful habit is therefore to ask four questions in order. What evidence does the method consume? What exactly does its output support? Under what conditions has the process been tested in practice? What protection, data handling, and recovery behaviour follow the output? Those questions keep the method, the process, and the legal purpose aligned.
An age check can be a face estimate, a document match, a behavioural inference, or a reusable proof of an attribute. None of those labels is a conclusion about effectiveness. The meaningful judgment belongs to the complete process: its evidence, deployment conditions, fairness, accessibility, and ability to communicate with the rest of the system. The next question is how those pieces operate over time, from the first signal through the access decision and the controls that respond when the signal is uncertain or attacked.