For two years, age assurance has been governed in five different languages at once. Ofcom asks for “highly effective age assurance.” The EU’s Digital Services Act asks for measures “proportionate” to risk. Australia’s Online Safety Act asks platforms to take “reasonable steps.” The US state App Store Accountability Acts ask for a “commercially reasonable” method. Each regulator gestures at the same idea — a check that actually works, sized to the harm — but none of them defined it in terms the others, or the vendors, could share.
In December 2025 that changed. ISO/IEC 27566-1:2025, the first international standard for age assurance systems, was published after years of drafting through the joint ISO/IEC committee. It does not replace any of those regulations. What it does is more useful: it gives everyone — regulators, platforms, and the vendors they buy from — a common vocabulary and a common set of properties to argue about. Through 2026 that vocabulary is quietly becoming the default. The standard was made effectively free to read, the UK’s Age Check Certification Scheme is already certifying providers against it, and April’s Global Age Assurance Standards Summit in Manchester is pivoting its agenda toward relying parties — the platforms doing the buying. The practical consequence for anyone procuring age assurance this year is a new question on the RFP: are you aligned with 27566, and can you prove it?
This post explains what the standard actually contains, why a framework document matters more than it sounds, how to read its five characteristics as a buyer’s checklist, and the trap most teams will walk into — treating certification as if it were legal compliance.
What the standard is, and what it deliberately is not
27566-1 is subtitled Part 1: Framework, and the word “framework” is doing real work. This is not a pass/fail test with a single accuracy threshold. It is a structured way to describe, evaluate, and compare age assurance systems so that a claim made by a vendor in one jurisdiction means the same thing to a regulator in another.
Three design choices are worth understanding before you use it.
First, it treats age assurance as an umbrella term, not a synonym for document checks. Under 27566, age assurance spans age verification (proving age from an authoritative source such as an ID document or bank record), age estimation (inferring an age range from a biometric signal such as a face), and age inference (deducing age from behavioural or account signals). Each sits on the same map, with different strengths, costs, and failure modes.
Second, it formalises the idea of a level of confidence — technically, a level of assurance — that any given method or combination produces. A self-declared birthday and an NFC-read passport are both “age assurance,” but they sit at opposite ends of the confidence scale. The standard’s logic is proportionality: the required level of assurance should track the risk of harm a given service, product, or piece of content presents to a child. That is the same instinct behind Ofcom’s and the ICO’s proportionality language, now expressed in portable terms.
Third, it is explicitly privacy-forward. The framework pushes systems to collect only the minimum data needed, to return an eligibility result without disclosing the underlying sensitive detail, and to delete personal data after the check. Privacy is not a footnote; it is one of the five characteristics the whole document is organised around.
27566-1 also does some housekeeping for the industry. It supersedes the UK’s earlier BSI PAS 1296:2018 specification and forces alignment on IEEE’s 2089.1, consolidating a fragmented set of prior efforts into one reference point. Parts 2 and 3 are already in development — Part 3, on approaches to analysis and comparison, will matter most for buyers, because it moves from “here is the framework” toward “here is how to compare two systems.” For now, Part 1 is the anchor.
The five characteristics, read as a buyer’s checklist
The core of 27566-1 is a set of five characteristics against which any age assurance system can be described and, increasingly, certified: Functionality, Performance, Privacy, Security, and Acceptability. Most teams will first meet these as abstract nouns. The more useful move is to read each as a question you put to a vendor — and to yourself about your own deployment.
| Characteristic | What the standard means by it | The question to ask your vendor |
|---|---|---|
| Functionality | Does the system actually determine age-related eligibility for your use case, at the thresholds and levels of assurance you need? | Which methods do you support, and what assurance level does each produce at my required age boundary? |
| Performance | How accurate and reliable is it — across demographics, devices, and conditions — and how is that measured? | What are your error rates, how are they benchmarked, and how do they vary by age band, skin tone, and lighting? |
| Privacy | Is data minimised, is the output a decision rather than a dossier, and is personal data deleted after use? | What do you collect, what do you return, what do you retain, and for how long? |
| Security | Is the system resistant to spoofing, injection, and compromise, and is the pipeline itself hardened? | How do you resist presentation and injection attacks, and how is the result protected end to end? |
| Acceptability | Will real users complete it — is it accessible, low-friction, and trusted enough not to drive abandonment? | What is your completion rate, and how do you handle users without documents or with accessibility needs? |
The value of this grid is that it stops the two failure modes of age-assurance procurement. The first is buying on a single number — usually a headline accuracy figure — while ignoring that a system can be accurate and still be a privacy liability, or accurate and so high-friction that it bleeds conversion. The second is buying on brand and discovering, under a regulator’s information request, that you cannot describe the system in any of these terms. 27566 gives you five axes instead of one, and it forces the uncomfortable trade-offs — Performance against Acceptability, Functionality against Privacy — into the open where they can actually be negotiated.
Notice too that Performance and Acceptability pull in opposite directions from Privacy and Security only if the architecture is naive. A system that maximises Performance by hoarding identity documents scores well on one axis and badly on two others. The standard rewards designs that hold all five in tension rather than optimising one at everyone else’s expense — which is exactly the point of a framework over a single metric.
Why a framework document matters: it gives “highly effective” a spine
It is tempting to dismiss a vocabulary standard as paperwork. The opposite is true, and the reason is the fragmentation described at the top. Right now, a vendor that has proven its accuracy to Ofcom has to re-prove it, in different terms, to the Australian regulator, and again to a US state attorney general, and again to your procurement team. Every one of those conversations reinvents the measurement.
A shared standard lets that evidence travel. When your vendor can express its Performance in the categories a certification body assessed, that assessment becomes portable across the regimes converging on the same requirement — the UK’s highly-effective duty, the EU’s proportionality test, Australia’s accuracy expectations, and the US state accuracy standards now being written into law. This is not hypothetical: as of July 2026, regulators are actively debating whether hard accuracy minimums should be the bar that brings large platforms into line, and a standard is what makes “accurate enough” a defensible, comparable claim rather than a marketing adjective.
For platforms, that portability is leverage. It is the difference between proving your age checks work once, in a recognised frame, and re-litigating effectiveness with every new regulator that sends an information request. The standard does not lower the bar. It stops you from having to jump it in a dozen incompatible ways. It also anchors the accuracy conversation to external evidence — the kind of independent facial-age-estimation benchmarking that NIST and others publish — rather than to a vendor’s own slide deck.
Certification is not compliance — and that distinction will bite
Here is the trap. Because a certification scheme now exists, a wave of vendors will arrive at your door describing themselves as “ISO 27566 certified,” and a wave of buyers will treat that phrase as a compliance shield. It is not one, and misreading it is how you end up exposed.
Be precise about what certification is. A body such as the ACCS audits a system and issues accredited evidence that it conforms to the five characteristics of the standard. That is genuinely valuable: it is independent, it is structured, and it hands you a defensible artifact for procurement and for your own audit file. What it is not is a finding by Ofcom, the ICO, the EU, or any court that your specific deployment satisfies your specific legal duty. Certification tells you a system was built to a recognised framework. Compliance is a legal judgment about whether your use of it, on your surface, for your risk level meets the law — and that judgment is made by regulators, not standards bodies.
Three consequences follow. First, treat certification as a strong input to vendor selection, not as the end of your obligation; you still have to choose the right assurance level for your risk and document why. Second, interrogate the scope of any certificate — a vendor can certify one product configuration and sell you another, so confirm that what was audited is what you are deploying. Third, watch for “certified-washing”: claims of alignment with a standard that is a framework, dressed up as a legal all-clear. The honest vendor will tell you exactly where certification ends and your responsibility begins. The one who blurs that line is selling you their liability as your assurance.
The architecture the standard quietly endorses
Read 27566-1 as an engineer and a specific system shape falls out of it. Because assurance should be proportionate to risk, and because privacy and security are first-class characteristics, the design the standard rewards is a layered, step-up model rather than a single method applied to everyone.
That model has four properties, and they map cleanly onto the five characteristics.
Start with the lightest method that satisfies the risk, and escalate only when confidence is insufficient — age estimation for a low-risk surface, stepping up to document and NFC chip verification where the boundary genuinely demands certainty. That serves Functionality (right assurance level per surface) and Acceptability (no unnecessary friction). Return an eligibility decision, not a stored identity — over or under the threshold, not a retained birthday or ID image — which is the Privacy characteristic expressed as an output contract. Harden the pipeline against spoofing and injection, the Security characteristic. And keep the evidence of the check — which method ran and what assurance level it produced — without keeping the underlying identity, so you can answer a regulator without becoming a breach magnet.
This is why the “collect everyone’s ID to be safe” reflex fails a 27566 reading as badly as a self-declared checkbox does. Maximal collection scores on Performance and craters on Privacy and Security; a checkbox scores on Acceptability and craters on Functionality and Performance. Neither holds the five characteristics in balance. The resolution is the same one the Children’s Code and the Reddit fine already pointed to, and that privacy-first architecture and zero-knowledge techniques were built to deliver: verify the fact, discard the identity, keep the proof.
Turning 27566 into a procurement question set
You do not need to read the full standard to use it. Translate the five characteristics into a short, blunt question set and put it in front of every vendor — including your incumbent. This complements a security-focused vendor checklist rather than replacing it; the security review goes deep on one characteristic, while 27566 keeps all five in frame.
Ask, in order: Which methods do you support, and what assurance level does each reach at my thresholds (Functionality)? What are your measured error rates, benchmarked by whom, and how do they vary across demographics and devices (Performance)? Exactly what do you collect, return, and retain, and for how long (Privacy)? How do you resist presentation and injection attacks, and how is the result protected in transit and at rest (Security)? What is your real-world completion rate, and how do you serve users without standard documents (Acceptability)? Then two meta-questions: are you certified against 27566-1, and what configuration and scope did the certificate cover? A vendor who answers all seven cleanly is one you can defend to a regulator. A vendor who deflects to a single accuracy number, or waves a certificate without a scope, has told you which characteristic they are weakest on.
How Xident maps to the five characteristics
Xident was designed around the same properties 27566-1 formalises, which makes the mapping direct rather than retrofitted.
On Functionality, Xident supports the full range the standard describes — client- and server-side facial age estimation under liveness for age estimation, and document OCR, face match, and NFC chip reads for age verification — returning threshold classifications at +12, +15, +18, +21, and +25 so you can set the assurance level per surface. On Performance, those methods are benchmarked against independent accuracy evidence rather than self-reported figures, and the step-up flow escalates precisely where a single method would be too weak. On Privacy, the output is a decision, not a dossier: Xident returns an over/under-threshold result and does not retain dates of birth or ID images beyond the check, the data-minimisation posture the standard treats as central. On Security, the pipeline is built to resist spoofing and injection, and results are protected end to end rather than left as a plaintext claim. On Acceptability, client-side estimation keeps friction low for the majority who never need to escalate, and reusable, user-held credentials let returning users prove the same fact without re-submitting identity. Across all five, each decision is logged with its method and assurance level, producing the evidence trail a regulator’s information request actually asks for.
The uncomfortable truth of the last two years is that “our age check works” was an unfalsifiable claim — every party meant something different by it, and no one could compare two systems on equal terms. 27566-1 ends that, not by raising the bar, but by naming it. In 2026 the platforms that treat the standard as a procurement discipline — five characteristics, held in tension, with certification scoped and understood as evidence rather than absolution — will be able to prove their choices to any regulator that asks. The ones that treat a certificate as a compliance shield will find out, at the worst possible moment, that a framework was never a defence. The difference is not the badge. It is whether you can answer the five questions honestly.
Age assurance standards and the regulations that reference them are evolving quickly. This post is general information about a published standard and public certification schemes, not legal advice; certification against ISO/IEC 27566-1 is not a substitute for a compliance assessment, and you should consult qualified counsel for your specific obligations.
