On 23 September 2026, Ofcom opened an investigation into Aylo, the company that owns Pornhub, over the age checks it switched on for UK iPhone users in May (Ofcom).
One sentence in the announcement matters more than the rest. Ofcom said the investigation will not make any determination about how Apple operates its age checks.
So the thing being examined is not the signal. It is what Aylo did with it.
That distinction is the whole piece. A lot of teams are about to adopt an age signal built by somebody much larger than them: an operating system vendor, an app store, a carrier, a national wallet. The signal is usually better engineered than anything the team could build. None of that transfers the duty. The regulator will still come to you, and it will ask what you measured before you turned it on.
The two limbs
Ofcom’s concern, in its own words, is that Aylo “may not have conducted sufficient due diligence and testing” before deploying the new process, and so the process “may not be highly effective” at keeping children away from pornography.
That splits into two separate duties, and they fail independently.
| Limb | The question | What answers it |
|---|---|---|
| Highly effective age assurance | Does the deployed process keep children out? | Measurements from your own deployment: pass rates, false negative rate at your challenge age, behaviour when the signal is missing |
| Children’s access assessment | Did you reassess before you changed the service? | A dated assessment, completed before the change shipped, that names the change and reaches a conclusion |
The second limb is the one teams forget exists. Under the Online Safety Act, a provider has to carry out a suitable and sufficient assessment of whether children are likely to access the service before any significant change to the design or operation of that service. The same duty is triggered again by evidence that existing age checks have become less effective.
Read that as a release gate, not as a policy document. Replacing your age assurance method is a significant change to the operation of your service. It is hard to think of a clearer example. If the assessment is dated after the deploy, you have failed the second limb on the timestamp alone, whatever the gate turned out to do.
We wrote earlier about how every Ofcom age assurance fine in 2026 arrived with a second penalty for failing the information request. This is the same shape. The substantive failure and the evidence failure are priced separately.
“The strongest available” is not a measurement
Aylo’s public response, given to The Register after the investigation was announced, is that Apple’s device-level age verification “offers one of the strongest and hardest to circumvent protections currently available” (The Register).
That may well be true. It is also an answer to a question nobody asked.
Ofcom’s four criteria for highly effective age assurance are technical accuracy, robustness, reliability and fairness. Every one of them is a property of a deployed process, not of a method’s reputation. Technical accuracy is how well the method reads age under test conditions. Robustness is how it holds up against real users and real adversaries. Reliability is whether the output is reproducible and comes from evidence you can trust. Fairness is whether the outcomes differ across groups of people. We set out how to compute those in measuring age assurance effectiveness.
A strong method wired into a weak flow is a weak gate. The method can be excellent and your integration can still pass a child, because the gap is almost never in the age decision. It is in the plumbing around it: what happens when the signal is absent, what happens on a device shared by a family, what happens when the app is opened a second time, what your code does with a response it did not expect.
There is a line in Ofcom’s guidance that reads like it was written for exactly this case. Where testing has been done by a third party, providers should understand what tests were run and what metrics were used. Not “should be reassured that a serious company ran tests.” Should understand the tests and the metrics. If you cannot name the metric, you have not met the standard, no matter who produced the signal.
The coverage asymmetry nobody documents
Aylo reopened UK access for eligible users who confirmed their age through Apple. New users on Android, on desktop, and on everything else remain locked out.
Pause on what that means as an engineering state. One platform has a gate built on a borrowed signal. Every other platform has a different arrangement. Your effectiveness argument is now per platform, and so is your evidence.
This is the normal case, not the odd one. OS-level and store-level signals do not arrive everywhere at once, and they never cover the whole estate. We mapped what the store signals actually return and where they go blank in Play Age Signals and Apple’s Declared Age Range, and how the device mandates diverge from each other in the OS age signal playbook.
The practical consequence is that a mixed estate needs a mixed set of numbers. One blended pass rate across all platforms hides the platform where the gate is weakest, which is the platform a regulator will look at. Split the metrics by platform before anyone asks you to.
What due diligence on a borrowed signal actually produces
Here is the part that is missing from most integrations. Not a policy, a test plan, run before the deploy, that produces artefacts with dates on them.
Write down what the signal means. Not what it is called. What the field values are, what each one asserts, and what it does not assert. A declared age range is a statement about a setting on a device. It is not a statement that the person holding the device is that age. Write the difference down in the ticket, because that sentence is the one that sets your threshold.
Enumerate the absent cases and decide each one. Signal not supported on this OS version. User has not completed the vendor’s own check. Feature disabled. API timeout. Response missing the field. Response present but malformed. Each one needs an explicit branch and a decision you are willing to defend. The failure mode that gets platforms fined is the one where an unreadable response falls through to allow, because allow was the code path that already existed. We covered the wider version of that choice in fail open, fail closed, degraded mode.
Test the shared device. A family tablet, a hand-me-down phone, a sibling’s account. Device-level signals are strongest exactly where one device maps to one person, and weakest where it does not. This is the circumvention path that matters most for a device-bound signal, and it is the cheapest one for a fourteen-year-old to find. See binding, shared devices and proxy verification.
Run a real cohort, not a smoke test. A handful of adult staff accounts passing the flow is not evidence. You need volume through the live integration, split by platform and by branch, with the counts kept. You cannot test on actual minors, which is a genuine and permanent hole in every age assurance test plan, and we wrote about how to work around it in the testing gap.
Ask the signal vendor for their numbers, in writing. What did they test, on what population, against what ground truth, with what error rate at which age. If the answer is a marketing page, record that the answer was a marketing page. That record is worth something later. It shows you asked.
Set a monitoring threshold and a rollback trigger before launch. The duty reopens on evidence that your checks have become less effective. So you need a number that would count as such evidence, chosen in advance, wired to an alert. Pick the level at which you would switch the method off. If no such level exists, you have not made a decision, you have made a commitment.
Date the assessment and ship it before the code. The assessment, the test results, the decision record, the rollback trigger. Four files, one date, all before the deploy.
None of this is expensive. All of it is boring. The reason it does not get done is that adopting a large vendor’s signal feels like the safe option, and safe-feeling changes skip the gate that risky-feeling changes go through.
The re-verification trap inside a device signal
One more thing specific to borrowed signals, because it bites quietly.
A device signal is evaluated on a device, at a moment. It is not a credential you hold. So you have two choices, and both need a written answer.
You can read the signal on every session, which keeps it fresh and ties you to the platform’s availability and to whatever the user has since changed in their settings. Or you can read it once and store the result, at which point you own a piece of age state whose accuracy decays, and you have to decide how long it lives. That is the same expiry question we worked through in re-verification cadence and stale age data, except you cannot fall back on a birthdate, because the signal never gave you one.
Teams usually end up caching, because reading on every session is slower and can fail. Caching is defensible. Caching without a documented lifetime is not.
How Xident fits
Three parts of how we are built speak to this problem directly.
A borrowed signal is an input, not the gate. Our design treats an OS signal, a store signal or a carrier signal as one piece of evidence feeding a decision, with a defined path for every case where the signal is absent or ambiguous. The decision is ours to explain, which means there is something to explain. A pass-through integration gives you nothing to hand a regulator except the vendor’s name.
Decision records, not retained documents. Every decision returns outcome, method, threshold, confidence, policy version and timestamp, and that is what we store rather than anyone’s passport image. When an investigation asks what measure was in force on a given date and what it did, that record is the answer. It is also what lets you split the numbers by platform, because the method is a field on every decision.
A step-up that is cheap enough to actually use. On Growth a Check is €0.02 and a document Verification is €0.20. The ten-fold gap is what makes it affordable to send the ambiguous cases down the document path instead of letting them through. A device signal that returns nothing should cost you a step-up, not a pass.
The free sandbox grants 1,000 Checks and 100 document Verifications as one-time allowances rather than a monthly quota. The 100 Verifications exist so you can run the document branch end to end, including the case where the first method gives you nothing, before you decide what your absent-signal path does in production.
The honest limits
Aylo may be right on the merits. Device-level age verification really may be harder to get around than a document upload, and Ofcom has itself called for system-level solutions. This investigation might close with no action.
It will still have cost Aylo months, and the reason is procedural. Ofcom is not asking whether the choice was good. It is asking whether the work was done and written down before the change went live.
There is also a fairness point worth stating rather than designing around. A gate that works only on recent iPhones is a gate that works best for people who can afford recent iPhones. Coverage gaps in a borrowed signal are not neutral. They land on older devices, cheaper devices and shared devices, which means they land on particular households. Fairness is one of the four criteria, and platform coverage is part of it.
The short version
Ofcom drew a line on 23 September and put Apple on the other side of it. The signal belongs to Apple. The gate belongs to Aylo. The evidence belongs to whoever deployed it.
If you are planning to adopt somebody else’s age signal, the useful question is not whether it is good. It is what you will be able to show, with dates on it, about the version of your service that went live. Write the assessment before the deploy, split the numbers by platform, name the level that would make you switch it off, and keep the email where you asked the vendor for their test metrics.
Xident provides age verification and age estimation infrastructure that treats device, store and carrier signals as inputs to a decision you can evidence, with decision records instead of retained documents. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications. Talk to us about the absent-signal path in your current integration.
