There is a line of code in your age gate that nobody reviewed as a compliance decision.
It sits in the error handler. The verification provider times out, or returns a 503, or the SDK fails to load, and that line decides what happens next. Either the user is let through, or the user is stopped. Whoever wrote it was solving an availability problem at 4pm on a Thursday, not interpreting section 23 of the Online Safety Act. But that line is your age assurance policy for every minute the provider is unavailable, and it is the part of the system a regulator will eventually ask about.
Almost every published discussion of age assurance — including most of ours — assumes the check runs. The arguments are about which method, what threshold, how much data to keep, how to reduce drop-off. All of that assumes the happy path. The failure path gets a shrug and a catch block, and it is the only part of the design that has never been written down.
That gap is closing, because the failures are no longer theoretical and the regulators are now asking services to describe their systems rather than their intentions.
The failures are routine now
Age assurance sits on top of a stack that has had a bad two years.
On 20 October 2025, AWS’s us-east-1 region went down for roughly fifteen hours after a latent race condition in DynamoDB’s DNS automation removed records for critical endpoints, cascading through dozens of dependent services. Four weeks later, on 18 November 2025, Cloudflare pushed a Bot Management configuration change that doubled the size of a feature file, crashing and restarting proxy processes across its global network and producing 5xx errors for a long list of well-known services. Cloudflare had another significant outage on 20 February 2026, and a further cluster of R2 incidents through August 2026. Identity and age assurance vendors run on the same infrastructure as everyone else, and their public status pages record their own acknowledged incidents on top of it.
None of that is a scandal. It is what operating at internet scale looks like. The relevant point for an age assurance programme is narrower and less comfortable: your legal obligation to check age does not pause when your provider does. There is no availability exemption in the Online Safety Act, no downtime carve-out in the DSA guidelines, and nothing in Australia’s social media minimum age provisions that says the duty lapses while a supplier is degraded. Whatever your gate does during those hours is what you did, and it is what you will have to describe.
So the honest question is not how do we prevent this. You cannot prevent it. The question is what do we want to happen, and can we explain it afterwards.
The two defaults, and why both are wrong
Left undesigned, the error handler collapses into one of two behaviours.
Fail open waves everyone through. The product team likes it because the funnel keeps converting and nobody pages anyone. It is also, for the duration of the incident, a service with no age assurance at all. Every under-age user who arrives during that window gets an unverified adult session, and if you bind that session to a persistent account, the outage does not end when the provider recovers — you have minted accounts that are permanently on the wrong side of the line, and no later fix reaches them.
Fail closed blocks everyone. It looks like the responsible choice, and in a narrow compliance sense it is: no minor gets through a gate that passes nobody. But it converts a supplier incident into a full outage of your own product, which means the business will not tolerate it for long. What actually happens at most companies is worse than either policy: fail-closed is the written default, the revenue impact becomes visible in about forty minutes, and someone with production access flips a feature flag to fail-open as an incident mitigation. Now your age assurance posture is decided under time pressure by whoever is on call, and there is no record of the decision, the duration, or the traffic that passed through it.
That last scenario is the one worth designing against, because it is by far the most common. The failure is not that a team chose badly. It is that the choice was never made in advance, so it got made badly under load.
Why fail-open is a documentation problem, not just a safety one
The instinct is to treat fail-open as a child safety risk and stop there. It is that, but the sharper exposure in the UK is evidentiary.
Section 23 of the Online Safety Act requires a user-to-user provider to keep a written record of the measures taken or in use to comply with a relevant duty, and — this is the part that bites — where the provider uses something other than a measure the code of practice recommends, it must record which measure it did not take, what it did instead, how that achieves compliance, and how it satisfies the freedom of expression and privacy requirements. An undocumented fail-open path is exactly that: a measure in use, differing from the recommended one, with no record of what it is or why it is adequate. It is not a gap in your logging. It is a gap in a record duty.
Then there are the information powers. Section 100 lets Ofcom require a person to provide any information it needs for its online safety functions, including information that does not already exist — it can require you to generate it — and to permit remote viewing of systems, processes and functionalities in real time. Section 102(8) obliges the recipient to comply with the notice and to ensure the information is accurate in all material respects. Accuracy is a separate limb from timeliness, which is why a punctual, complete-looking answer that turns out to be wrong is still a breach. Ofcom fined Fenix International, the operator of OnlyFans, £1.05 million for failing to provide accurate information about its age assurance measures. The maximum available penalty is the greater of £18 million and 10% of qualifying worldwide revenue, and section 110 extends criminal liability to a named senior manager who failed to take reasonable steps to prevent an offence of providing false information.
Now imagine answering “describe the age assurance measures in use on your service” for a period that included a six-hour provider outage and an unlogged feature-flag flip. The description your compliance team writes will be the description of the happy path, because that is the only one anyone documented. It will be inaccurate in a material respect, and nobody in the loop will know it.
Australia is heading the same way from the other end. eSafety issued 23 legally enforceable information-gathering notices to 10 platforms in the first three months of the social media minimum age obligation, with five platforms becoming the subject of active investigations, according to its March 2026 compliance update. A bill before the Australian Parliament would let the Commissioner direct platforms — and third parties including age assurance providers and app stores — to produce evidence demonstrating the steps taken to prevent under-16s obtaining accounts. In the UK, Ofcom’s July 2026 report already tells services to conduct vendor due diligence and to review existing age assurance against identified areas for improvement as a matter of urgency, and Ofcom owes Parliament a rapid assessment by the end of October 2026 on what highly effective checks look like for the over-16 question.
Vendor due diligence is not only “is this provider certified”. It is also “what does my service do when this provider is unavailable, and can I evidence it”.
Why fail-closed is not automatically the safe answer either
Blocking everyone is defensible against a child safety regulator and indefensible against almost everyone else.
It is a hard accessibility failure. The users who lose most are the ones already worst served — people who need the assisted or alternative path, who now get nothing at all, with no explanation and no queue. It compounds the adult lockout problem, where legitimate users are already being refused by imperfect estimation. And it will not survive contact with the business, which is the practical objection: a control that gets disabled during every incident is not a control.
There is also a jurisdictional wrinkle. Australia’s social media minimum age provisions bar a platform from collecting government-issued identification for age assurance unless a reasonable alternative method is also offered. If your entire fallback strategy is “when the estimation provider is down, everyone uploads a passport”, you have designed a degraded mode that is non-compliant in Australia on a good day, and you have quietly made document collection the default path during exactly the window when your logging is least reliable — which is also the window when the data you retain is most likely to be handled outside the normal flow.
Fail-closed is a reasonable answer for a hard legal threshold on a high-risk surface. It is a bad universal answer, and applying it universally is how it stops being applied at all.
The third answer: graded degradation
The way out is to stop treating this as a binary. What you want is a documented degradation policy — a small set of pre-decided behaviours, mapped to surfaces by risk, that a system can enter automatically and exit automatically, and that produces a record on the way through.
Four building blocks, in the order they should be reached for.
1. Make the outage smaller before you make it acceptable. The single highest-value property is that not all of your traffic depends on the provider being up. A returning user who already holds a valid reusable credential or age token can be resolved locally against a signature or a cached decision, with no outbound call at all. On mature traffic that is a large share of verifications, and it means a provider incident degrades new-user signup rather than the entire product. This is the strongest argument for reusable credentials that people rarely make: they are not just cheaper and lower-friction, they are the part of your age assurance that keeps working when the network does not.
2. Have a second path on a different failure domain. A layered orchestration model already routes users across several methods for coverage and cost reasons. The reliability benefit is a by-product, but only if the alternatives are genuinely independent. Two methods from the same vendor, behind the same API gateway, in the same cloud region, are one method with two names. Ask where each provider actually runs. Redundancy that shares a failure domain is a diagram, not a control.
3. Define provisional access with a bounded blast radius, not a bypass. Where the surface allows it, the useful middle state is not “let them in as a verified adult”. It is a restricted session: access granted, but with the age-gated capability withheld, purchases blocked, uploads disabled, defaults set to the most protective tier, and a hard expiry. The user gets to keep browsing. They do not get the thing the age check was protecting. Critically, the session is marked provisional in your own data model, so the reconciliation in step four is possible at all.
4. Reconcile afterwards, deliberately. Every provisional session created during degradation is a queue item. When the provider recovers, those users are re-prompted at the next natural boundary, the provisional flag is cleared on success, and the capability is withheld or the account restricted on failure or non-response after a defined window. This is the step that turns a fail-open incident from a permanent hole into a temporary one, and it is the step almost nobody builds — which is why an outage that lasted six hours produces accounts that are wrong for years.
Which surfaces get which behaviour is a policy table, not an engineering preference. A hard legal threshold — alcohol, gambling, firearms, adult content, anything where the statute sets the line — fails closed, full stop. A softer content filter or a feature-level gate can take provisional access with reconciliation. The table should be short, written down, versioned, and approved by whoever owns the compliance risk, so that during the incident nobody is inventing policy from a Slack thread.
Your SLA is not the control you think it is
The contractual side is where most of the remaining illusion lives.
Standard uptime commitments measure the wrong thing. Vendors typically exclude planned maintenance from the calculation by default, so a “99.9%” number is measured against the hours remaining after scheduled windows are removed. Metrics are aggregated monthly, which erases the shape of the failure — a single four-hour outage during your peak signup window and a thousand scattered four-second blips can produce the same monthly figure and wildly different damage. And uptime is usually binary availability rather than functional availability: an endpoint that returns 200 with a degraded model, elevated latency, or a sharply raised inconclusive rate is “up” by the SLA and broken for your users. That last mode is the dangerous one, because your circuit breaker never trips and your escalation logic quietly routes far more people into the expensive path — or, worse, into an auto-approval branch tuned for a much lower volume.
Some vendors also classify their cloud provider’s outage as force majeure. Read that clause carefully: the choice of underlying infrastructure is the vendor’s architectural decision, and it is reasonable to argue it should not exempt them from remedies you are paying for.
What is worth negotiating, in rough order of value:
- A functional SLI, not just uptime. Success rate and inconclusive rate measured over short windows, not availability averaged over a month.
- Latency percentiles with teeth. p95 and p99 on the verification call, because a check that takes forty seconds has failed even when it succeeds.
- Machine-readable status and an incident notification commitment with a stated time to first notification. You cannot automate a degradation policy off a human reading a status page.
- Planned maintenance windows disclosed in advance, and counted honestly.
- Sub-processor and region transparency, so you can verify whether your “second provider” is actually independent.
- Termination triggers on repeated breach, not only service credits. Credits refund a fraction of the fee; they do not refund a regulatory finding.
Service credits are compensation for a supplier failure. They are not a defence to a duty you owe directly. Ofcom will not accept that your provider had an incident as an answer to why your service ran without effective age assurance for a day, any more than a bank’s regulator accepts an outsourced control failing as an excuse. The duty is yours; the provider is how you discharge it.
What to log while it is broken
The final piece is evidence, and it is cheap to build if you decide in advance.
No regulator currently imposes a per-user, per-check audit trail for age assurance — not the Online Safety Act, not Ofcom’s guidance, not eSafety, not the DSA, not the ICO. The ICO’s position points the other way: where a hard identifier is used, a service may only need to retain a yes/no output once the check is complete, and seeing an official document is in many cases excessive. So this is not an argument for hoarding evidence about individuals. It is an argument for aggregate, decision-level records about the system, which are the records an information notice actually reaches.
For any period of degradation, the useful record is:
- when degraded mode was entered and exited, and by which trigger — automatic threshold or human decision, with the operator named;
- which policy version and which fallback branch was active, per surface;
- how many sessions were granted provisional access, per surface and per jurisdiction;
- what capabilities remained withheld;
- how many provisional sessions were subsequently reconciled, how many failed re-verification, and what happened to those accounts;
- the vendor’s own incident reference, so your narrative and theirs line up.
That is a handful of counters and a state transition log. It is a day of engineering work, and it is the difference between answering an Ofcom information notice with a system description and answering it with an apology. It also directly serves the section 23 record — you can state which measure was in use, what you did instead when it was unavailable, and why that alternative achieved compliance, which is the exact form the Act asks for.
Run the incident review afterwards on the compliance dimension, not only the availability one. Most postmortems for this class of failure record minutes of downtime and revenue impact, and never record how many unverified sessions were created. Both numbers belong in the document.
Where this lands architecturally
The pattern that survives an outage is the same one that survives a privacy review and a cost review, which is a reasonable sign that it is right.
Split the operations by what they actually cost and what they actually need. The heavyweight path — document capture, OCR, face match — is expensive, high-friction, and the most dependent on a live external pipeline. It should be reached for by exception, for a genuine legal threshold or a contested case. The lightweight path — an age band, a liveness signal, a returning-user credential lookup — is roughly an order of magnitude cheaper, far lower friction, and much easier to make resilient, because a returning user’s credential can be resolved without a round trip to a document pipeline at all. That distinction is why we treat Checks and Verifications as separate operation types rather than pricing everything as though it were a passport scan: the same split that keeps your unit economics sane is the one that keeps most of your traffic serviceable when something upstream breaks.
And keep the decision rather than the artifact. A stored record that says over 18, at this timestamp, by this method, at this confidence, under this policy version is re-checkable, portable, small, and safe to cache close to your own service. A stored passport image is a breach liability that helps you not at all during an incident.
The four questions to ask this week
- What does our age gate do right now when the provider returns an error? Not what the design doc says — read the error handler. Then read the feature flags around it and check who can flip them.
- What fraction of our verifications require a live outbound call? If the answer is 100%, your age assurance availability is exactly your vendor’s availability, and you have not measured your vendor’s availability.
- If Ofcom asked us to describe our age assurance measures for a month that contained an outage, what would we say, and is it true? Accuracy is a separate limb of the duty and it is the one that produces fines.
- Who signed off the degradation policy? If the answer is nobody, then the answer is an engineer, three years ago, in a
catchblock.
None of this is an argument that age assurance is too fragile to rely on. It is the opposite. The obligations are real and enforced, the methods work, and the operational failure modes are ordinary engineering problems with ordinary engineering answers — circuit breakers, independent failure domains, cached credentials, bounded degraded modes, reconciliation queues, and a log. What makes them dangerous is only that they are currently being decided by default, invisibly, by people who did not know they were writing compliance policy.
If you want to walk through what your gate does on its worst day, and what the record would look like afterwards, we are happy to look at it with you.
