Ofcom Published the Questions to Ask Your Age Check Vendor. It Didn't Say What a Good Answer Looks Like.

In its October industry bulletin, published on 15 October 2026, Ofcom added a short document called “Vet Your Vendor”. It is a list of questions for any service that buys its age checks from a third party. Ofcom is the UK online safety regulator.

The document is useful. It is also missing the part that makes it work. It asks for metrics, test results and appeal data, and it doesn’t say what a good number is, how old a test result may be, or what format the evidence should take. A vendor can answer every question and you still won’t know if your age check is highly effective.

This post covers what the document asks, what it leaves open, and how to build a dated evidence file so a vendor’s answers keep their value after the sales call. It applies to anyone who buys age checks, not only services under UK law.

What Ofcom published

The bulletin says Ofcom launched a “vet your vendor” resource to help providers assess their age assurance arrangements. The resource itself says it is based mainly on areas for improvement that Ofcom found in its Age Assurance Report. The list is not complete, and Ofcom says so.

The rule behind it is one sentence: “Service providers are ultimately responsible for ensuring their age assurance process is highly effective.” Buying a product doesn’t move that duty to the seller. Ofcom also expects due diligence on the vendor to happen regularly, not once.

The timing matters. The same bulletin lists a fine of £630,000 for the provider of fapello.com in July and £730,000 for the provider of Xgroovy.com in September. It lists open investigations into TikTok, over whether its age assurance is highly effective at identifying child users, and into Aylo. I covered the Aylo case in Ofcom Isn’t Investigating Apple. In that case, as in this document, the question is what the service did to check its tools before relying on them.

The five areas, turned into numbers

Ofcom groups its questions into five areas. Each one is a question a salesperson can answer in a sentence. Each one can also be answered with a number. Ask for the number.

Ofcom’s area	Ask for this	An answer that should worry you
Testing	The false acceptance rate (children passed as adults) at the age line you gate, split by age band and by group. The test date, the model version, and how often it is repeated.	One accuracy figure for “all ages”. No date. A test the vendor ran alone, on its own data.
Circumvention by children	The attacks tried (photo, screen replay, injected video, shared device, repeated retries) and the share caught and missed for each.	“Our liveness is industry leading.” No list of attacks.
Appeals	Appeals per 1,000 checks, the share upheld, the median time to a decision, and who makes the decision.	No appeal data because “the result goes to you.”
Standards and certification	The standard, the product version it covered, the date, and the scope.	A logo with no scope or date.
Method-specific checks	For estimation: the challenge age (the higher pass line that sends borderline cases to a stronger method). For face and photo-ID checks: whether liveness runs.	An estimation pass line set at exactly 18.

Two notes on the table.

First, Ofcom’s document says certification is not an automatic means of compliance. It names the UK Digital Verification Services Trust Framework and ISO/IEC 27566-1:2025 as examples. A certificate tells you an assessor looked at something. The scope line tells you what. For the standard itself, see what ISO 27566 asks of a vendor.

Second, the testing row is the hardest to get. A vendor can’t test on children, and neither can you. The testing gap post explains how the numbers are produced instead. Ask how the figure was made, not only what it is.

What the document leaves open

Ofcom’s page sets no metric thresholds. It doesn’t require a test frequency. It doesn’t define an evidence format. That is a fair choice for a non-exhaustive guide, because the right numbers depend on the age line, the surface and the risk.

But it moves the work to you. Three things are yours to decide:

• The number that makes an answer acceptable. For example, a false acceptance ceiling at your age line.
• How old an answer may be before you ask again.
• Where the answer is stored, so you can show it later.

If you don’t decide, the default is a questionnaire in a procurement folder. It was true on the day it was filled in. Nobody knows whether it’s true now.

Answers expire

A vendor’s answer is about one thing: one model, measured on one date. It stops being useful in two ways.

The date goes stale. A test from last January says little about a gate that has handled a year of new devices, new attacks and new traffic.

The version changes. If the vendor ships a new model, last quarter’s test is about a product you no longer run. The vendor may be right that the new model is better. You still can’t show it.

So the evidence file needs three fields on every answer: the value, the date it was measured, and the model version it describes. Everything else is detail.

A small check for the evidence file

This function takes the evidence you hold and reports each area that is missing, stale or about an old model version. It reads one rule per area: how many days an answer may age.

export type Area = "testing" | "circumvention" | "appeals" | "standards" | "method";

export interface EvidenceItem {
  area: Area;
  value: string | null; // null means the vendor did not answer
  asOf: string; // ISO date the vendor measured it
  modelVersion: string; // the version the answer is about
}

export interface Policy {
  maxAgeDays: Record<Area, number>;
}

export interface Finding {
  area: Area;
  reason: "missing" | "stale" | "wrong-version";
}

const DAY_MS = 24 * 60 * 60 * 1000;

export function review(
  items: EvidenceItem[],
  policy: Policy,
  today: string,
  liveModelVersion: string,
): Finding[] {
  const findings: Finding[] = [];
  for (const area of Object.keys(policy.maxAgeDays) as Area[]) {
    const answered = items.filter((i) => i.area === area && i.value !== null);
    if (answered.length === 0) {
      findings.push({ area, reason: "missing" });
      continue;
    }
    // Use the newest answer for this area.
    const newest = answered.reduce((a, b) => (a.asOf >= b.asOf ? a : b));
    const ageDays = (Date.parse(today) - Date.parse(newest.asOf)) / DAY_MS;
    if (ageDays > policy.maxAgeDays[area]) {
      findings.push({ area, reason: "stale" });
    } else if (newest.modelVersion !== liveModelVersion) {
      findings.push({ area, reason: "wrong-version" });
    }
  }
  return findings;
}

A starting policy: 90 days for testing, circumvention and appeals, because those numbers move. 365 days for standards and method settings, because those change rarely. These are my numbers, not Ofcom’s. Change them to fit your risk.

I ran this with Node 22’s built-in test runner and six tests passed. They cover a complete file, a missing area, a null answer, a stale testing result, a model upgrade (all five areas flagged as the wrong version), and several answers where the newest wins.

Three details are deliberate. A null answer counts as missing, because “we’re looking into it” isn’t evidence. A stale answer is reported before a wrong-version one, since the older problem is the bigger one. And the function takes today as an argument, so a test never depends on the clock.

Four contract terms that keep the file fresh

The function only helps if the numbers keep arriving. That’s a contract question, not a coding one. Ask for four things in writing:

• Notice before a model change. You get the new version number and the new test results before it goes live on your traffic, not after.
• A fixed report. The same metrics, in the same format, every quarter. Ofcom asks how the vendor reports test results and flags problems to you; this turns that into a schedule.
• The right to run your own test. On your integration, with adults near your age line, at times you choose. A vendor’s lab result doesn’t cover your retries, your shared devices or your age band. The post on measuring effectiveness covers what to track.
• Your decision records, in a usable form. If the vendor keeps the only record of what each check did, you can’t compute any of these numbers yourself, and you can’t leave. See the vendor exit post.

None of this makes the vendor responsible for the result. Ofcom is clear that you are. It makes you able to show what you knew and when you knew it.

What I could not confirm

• Whether Ofcom will add thresholds or an evidence format later. The document sets none today, and I found no sign of a plan.
• Whether Ofcom treats a missing or stale vendor answer as a breach on its own. The document is guidance, and it says the list is not complete. The duty it points to is the duty to be highly effective.
• The detail of Ofcom’s Age Assurance Report. The resource says it draws on that report. I haven’t read all of the report for this post.
• How the document will be used in the open TikTok and Aylo investigations. Neither has a finding yet.

How Xident fits

Here is our own answer to Ofcom’s first question, as of today. Xident has no independent accuracy evidence yet. The figures we can share are our own internal evaluations. If you ask us for them, ask for the date and the model version, and treat them as internal. A vendor who tells you this is giving you a better answer than one who doesn’t.

Four parts of how we’re built help with the rest of the file.

A decision record on every check. We return and store the outcome, the method, the threshold, the confidence, the policy version and the time. We don’t keep the passport image. Those fields are what you need to compute your own numbers, split by method and by policy version, instead of waiting for a vendor report.

A challenge age you set. Age is returned as a threshold result (over or under 12, 15, 18, 21 or 25). The pass line for each surface is configurable. Borderline cases can go to a document Verification: optical character recognition on the ID plus a face match.

Liveness in the browser. The widget runs a randomised head-movement challenge. It sends the head-pose values it measured, and the server checks them against the challenge.

A cheap step-up. On Growth, a Check costs €0.02 and a document Verification costs €0.20. That is a ten-fold gap, and it’s what makes it affordable to send borderline cases and appeals to the stronger method.

The free sandbox grants 1,000 Checks and 100 document Verifications, once, not monthly. It’s enough to run your own test of the borderline and appeal paths before you sign anything.

One limit. This post doesn’t claim that Xident holds ISO/IEC 27566-1 or Digital Verification Services certification. If you need either, ask us in writing for the status, the scope and the date. Treat a missing answer as missing.

Checklist for the next seven days

1. List every age assurance vendor you use, and the product version live on your traffic today.
2. For each of the five areas, write down the answer your vendor gave and the date. If you hold none, mark it missing.
3. Replace each yes-or-no answer with a number: a rate, a count or a time.
4. Set a maximum age for each answer, using the policy above or your own.
5. Run the review check, or an equivalent, against the file.
6. Send the vendor a written request for every missing, stale or wrong-version item, with a date to answer by.
7. Ask for the four contract terms at your next renewal, or sooner.
8. Put a quarterly reminder on the file, with a named owner.

The short version

Ofcom told services to vet their vendors and listed five areas of questions. It set no thresholds, no test frequency and no evidence format, so the useful part is up to you.

Ask for a number, a date and a model version for every answer. Store them. Check the file on a schedule, and ask again when a date or a version goes out of range. The duty to be highly effective stays with you, so the evidence should too.

---

Xident provides age verification and age estimation infrastructure, with a decision record on every check, a configurable challenge age, and a Check priced about ten times below a document Verification. Talk to us about what your vendor file would look like today.