Age verification technology is becoming an application architecture problem, not a checkbox at registration. This webinar explains how verification, estimation, and inference differ, how teams can combine them into a proportional assurance flow, and why privacy, certification, jurisdiction, and liability matter as much as raw accuracy.
.png)
Hi folks, thanks for your patience. Appreciate you all joining us today. We're talking about age verification technology with a great guest, Iain Corby, who I met at Identity Week America a couple of weeks ago. He is the executive director of the Age Verification Providers Association. We're going to have a discussion about what age verification is, why you might care about it, and some other details. Iain, thank you so much for joining us — really appreciate you coming on.
Hello. My apologies — classic situation where you hit the wrong link and end up on the wrong call.
It's 2025 and we still haven't solved video conferencing, but it's all good. I don't remember whether you have prepared some slides or if we're just having a discussion.
Let's just have a conversation, if that's okay with you.
That's perfectly fine. Let's start with the basics — what is age verification, and why would websites or applications use it?
Let me kick in with who I am. I run the global trade association for age verification providers. We have about 34 members right now who provide various forms of online age verification — and actually we do in-person too, but let's stick to online today.
They might do age verification, which is where we start with an actual date of birth, check that it's accurate, check that it belongs to you, and then confirm to other websites — or relying parties, as we call them technically — that you're 18, or 13, or 16, or whatever the age might be. You're 65, so you can get cheap bus fares.
That's age verification. Age estimation is where we use something around your behavior or your biometrics — your face, your voice, your fingers, your heart rate — to estimate your age.
And then there's age inference, which is where we know something about you. So you've had a Google account for twenty-five years — therefore you're probably over 25. Or you're an airline pilot who can fly a jumbo jet; you're not going to be 17. You have to be 21 to fly a jumbo jet.
Those are the three categories of age assurance as defined by the ISO, and it's those three things that our members supply to the online industry around the world.
That's a fantastic overview. As a developer or someone building applications, why would I pick one of these options over another — inference versus estimation versus verification?
I would always start with: what data do I have already on my customers? Some organizations automatically know the email of all their users. We can do an age verification based on just your email — it turns out that seven-year-olds don't check interest rates for mortgages or lease a car using their email address very often. So if we find 100 points of information where you've used your email address — or your mobile phone number, your cell phone — to do an adult kind of thing, then with pretty good certainty, we know you're an adult.
So if you happen to have the email addresses or cell phone numbers of your users, that's a great place to start. If you have pictures of your users, we might start with facial age estimation. If for some reason your users have given you their passport, we can start with that. But I would always say: what data do you have today before we start asking users for other data on the basis of which we can prove their age?
That makes sense. Are there legal and compliance factors that also play into which of these options makes more sense?
Yeah, totally. We're working really hard with regulators to persuade them to be technically neutral and to accept any method that proves to the required degree of certainty that you're over 18, or over 13, or whatever the age might be. Different use cases have different risks, so we think you should be proportional in how you approach this. Am I that bothered if a few 17-year-olds manage to get onto an adult website? Probably not. Am I really concerned if they can buy ammunition or knives before 18? Yes.
The methods and the level of accuracy will generally be set by a regulator. The best regulators set an outcome — they'll say, "We want you to be 99% or 95% certain." New York has just done this with an online media piece of legislation. They've literally set different percentages of error they will accept at different ages below 18, starting with something like fifteen percent of 17-year-olds they'll tolerate getting onto an adult site but only eight percent of 16-year-olds. Some of the most sophisticated regulators are really getting their heads around this.
That's amazing. And with my developer's hat on — where do I go to find out what regulatory regime I might actually be under? Is that something the Age Verification Providers Association or some of your members offer, or where do I go?
We do our best to put as much as we can on our website. Most age verification providers are also pretty much on top of the different legislative requirements — whether it's state by state in the US, what Australia's eSafety requires, or what the French or Germans will accept. It's different in every jurisdiction. So you could start with them. Obviously, the caveat is that if you want to be compliant, you need to speak to a lawyer — and you probably need a lawyer in Louisiana, a lawyer in Texas, a lawyer in Florida, which could get very pricey and complex.
One of the things we're really trying to do as a trade association is work with regulators to say, could you all just settle on one standard? Maybe three standard levels. We've written an IEEE standard that sets out low, medium, and high options, in the hope that regulators will pick one of those. I was just talking to the Brazilian government last week — they're about to bring in regulations very soon, by March, on pornography and on social media. For adult content it's 18; for social media it's 16. I said, please, please just borrow the Ofcom regulations in the UK for pornography and the eSafety regulations in Australia for social media. Then at least the platforms can say, "We've already done that — we can just reapply."
Yeah. A little bit of that happened in a slightly different sphere around GDPR. Other countries used it as a model around the privacy aspect, which makes total sense. You might need to tweak a few things here and there, but it would be great if everything aligned. The Internet's a global medium, so having some kind of consistent standard is great.
In the US alone, you could face 50 states with different regimes for data protection, cigarettes, pornography, and alcohol — that's 200 different jurisdictional regimes. Total nightmare.
We're doing as much as we can to persuade them to point to international standards. We have an ISO standard — ISO/IEC 27566 — which has literally just been approved globally. That's a long and torturous process to get an ISO standard signed off, but we got there. IEEE was quicker, so we had that ready last year; it's a bit more specific about different standardized levels of age assurance. Between the two of them, they create a really neat set of guidance — a set of rules against which you can then go and get an independent auditor, or conformity assessment body to use the official language, to conduct an audit for you. Then you can get a certificate.
One of the things we're talking to regulators about is: why don't we just ask all websites to put their certificate on the site to show that they're doing good-quality age verification and that it's been third-party audited? Because as a regulator, you can visit a website and have a look, but you don't know if their age verification is any good. You can see it might be there — it might say, "Give us a selfie" or "Show us your passport" — but unless you've got a thousand kids standing by to run a bit of testing, you literally have no idea whether it actually works or not. I think it's much better to work through this sort of co-regulation concept of third-party auditors doing certification.
That reminds me a little bit of SOC 2 and ISO 27001 certifications, where it actually becomes a business advantage. You can say, "Yeah, we're proactive about this — we want to conform, we want to help protect kids from seeing things they shouldn't." So it's not just a win for the regulators; that kind of standardization is a win for all the companies that need age verification integrated in their systems. Let's step into the technical — oh, go ahead.
I just want to check — you can still hear me? The connection went a bit dodgy there. There is a global infrastructure around conformity assessment bodies where, under the ILAC arrangement, each country essentially nominates one organization, which in turn certifies different audit companies to go and conduct those audits. There's already a ready-made structure for a global approach to this, and that's what we're trying to leverage.
Sign me up. You talked a bit about the different age verification technologies — I wonder if you could dig into that a little more. What technologies work for which age assurance techniques, and are there things people should definitely stay away from or always consider? I know you said start with the data, but can we dig into specific techniques?
Let me run through those three categories: verification, estimation, and inference.
Verification is your classic ID check — passport, driver's license, credit reference agency, your bank — people who know your actual date of birth. Our job is to make sure the document is accurate and that it belongs to you; we have to both verify and authenticate. That gives you a very high level of certainty about someone's exact age, though we'll still typically only transmit a simple yes or no to the website: over 13, over 18.
Facial age estimation is the technique everyone has probably heard of. There's always a buffer age here — it's never going to be good enough to tell you that yesterday was your birthday, so let's be clear that nobody's overclaiming for this technology. For an 18-plus check, the best-in-class will set the test at 21: does this person appear to look over 21 to the algorithm? Fewer than 0.6 percent of people under 18 would pass that test, which for most regulators is a pretty good success rate. In fact, an Australian government trial recently demonstrated that level of accuracy is sometimes even better than age verification from a passport, because things can go wrong — people can share documents, borrow them, commit fraud. Nothing's perfect in technology. At the end of the day, most of the time we're trying to stop kids having a drink or looking at adult content. We don't have to deliver identity-level accuracy. 99 percent is a whole lot better than zero, which is where we are today.
Right — you're not sending money via face or doing things that require that level of certainty.
To be really brutal about this, we're not letting you get on an airplane and fly into a building. And kids have got into bars with fake ID for many, many years. So we're just trying to do in the online world what you generally do already in the real world.
Other estimation techniques include ECG — your heartbeat. If you look at your health app and you've got a watch, it's been recording your heart rate for a month, and it turns out that's pretty good. How you move your fingers is another great one. A French company figured this out — they were originally looking for people taking performance-enhancing drugs in sport, understanding how that affected finger movement. In the process of building a mechanism to spot doping, they stumbled upon the fact that it also tells you whether someone is an adult. An amazing discovery.
Then there's inference, which is probably the largest and fastest-growing category. As I said, email is a good example — we can infer from how you've used your email or your mobile phone number. Inference is also growing because in Australia, where they're about to bring in 16-plus for social media, they will be asking platforms to infer from people's behavior online whether they're over 16. That might be who your friends are, what year you're in at school, or how many candles you had on your birthday cake when you posted it on social media.
Typically we use a waterfall approach: you start with the least intrusive method — the one that involves the least action by the user — and step it up until the last resort, which is asking someone to go and find their passport. You hope that at some point in that sequence, you've found a way to be sufficiently satisfied that somebody is old enough to access that particular platform.
Does intrusiveness also correspond to cost? What are the cost implications of these different options?
I have to plead the fifth a bit here — trade associations are never allowed to get into pricing. What I can say is the UK government estimated it was going to cost about 12 cents or 10p per check, as part of their impact assessment for the Online Safety Act. Since July 2025, we've been running new age checks at huge volumes — 10 million checks a day when that legislation came in. So you can anchor around that 10-to-12-cent range. I'm aware of pricing a little above that and somewhat below, but it's not a dollar fifty, which is what an ID check has traditionally cost for identity purposes.
Yeah, I don't want to get you in trouble. Cost is obviously part of any technology solution. Let's talk a bit more about privacy — you mentioned intrusiveness, so are there privacy concerns with these age assurance systems?
I represent the age verification providers, not the identity verification providers — and what distinguishes us is absolutely privacy. It's the essence of what we do: proving your age without disclosing your identity. Initially, we did that structurally: "I don't want to give my passport to a porn site, so I'll use a third party who will independently review my age and just say yes or no to the adult site."
Now things have moved on. It's no longer quite enough to just have that structural protection. Regulators like ARCOM in France and AGCOM in Italy are now saying they want technical guarantees as well. Zero-knowledge proof, privacy-enhancing technologies — these abilities to prove a point about yourself without ever having to reveal who you are. We're building that into our systems, particularly through interoperability.
Now, we all love a cookie pop-up, right? There was a real risk, I think, that age verification became the new cookie pop-up. Something like 60 percent of sites legally should be checking your age, because all it takes is processing a little bit of personal data on the basis of consent, and they then need to know you're over 13 to be able to give that consent. So there's a huge number of sites. If every single one of them said, "Please take a selfie, please find your passport, please share your heart rate with me" — that's not sustainable.
So we've known for years we've got to find an interoperable solution. There are a couple of things now out there in the market. One is called Age Aware, through a nonprofit called euCONSENT. There's another one just launched last week through a for-profit company, KID, and they have something called OpenAge. These are tokenized solutions where you do an age check and then get a token onto your device that, for a set period of time, gives you free entry into any age-restricted site. That's clearly a much better solution than having to do a check every time.
How long that token lasts is a matter for regulators. The Italians, I think, said forty-five minutes was the maximum before they expected a fresh age check. In the UK, Ofcom hasn't specified any limit at all. We're still finding our feet on this, but we can set that within the system and then prompt users with a PIN or face ID just to prove the device is still in their hands.
That's quite different from a purely device-based solution where you designate a phone as an adult phone or a child phone — we don't like that very much, because less well-off families will often share devices, or hand them down. Dad gets a new phone and gives it to his kids. And we know parents struggle with this technology — I think only 1 percent of users were using Snap's parental controls when that was checked a couple of years ago. Parents don't want to get into that whole thing, so we can't rely on diligent parental management.
That makes sense. Why do regulators have such different views on what is an acceptable lifetime for an age verification token? Is there legal justification, technical justification, or is it cultural? What's driving those differences?
I think this has been really hard for regulators. It's a whole new technology, a whole new concept — they've all been learning, and often they have a very short period of time to put out regulation. Brazil, for example, passed some legislation a month ago and it's coming into force in March; the government needs to produce regulations in under six months. The regulator I admire most is the New York Attorney General's office, who really got into this and learned the ins and outs of it. They produced an amazing piece of regulation that totally demonstrates they've understood this stuff.
So there's a lot of inconsistency. On the positive side, there are now a number of global working groups where regulators get together and talk to one another. Just last week I think the EU, the UK, and Australia announced a tripartite group. The ICO — the Information Commissioner, the data protection authority in the UK — runs one for about 15 or 20 countries, more focused on the data protection side. We're beginning to see that sort of global interaction.
That's great. More on the legal side — when age verification fails, who is responsible and what does liability look like? I'm sure it varies by regulator, but can you give us some generalities?
Liability — this is the word. This is the key to everything.
In the traditional relationship from the early days, a website appoints an age verification provider, they have a contract, they do some due diligence, there may be some guarantees and warranties. So if the site gets into trouble with a regulator and gets fined, they probably can't recover all the money from the small age verification provider, but they share the pain.
Some of the latest approaches to interoperability are not creating that kind of liability chain. If you look at what Google and Apple are offering: Apple offers the ability for a parent to put a child's age into the App Store so that apps can see how old the parent says the child is. If the parent lies and a kid gets onto a site they shouldn't, the site has no comeback on Apple — no liability. Apple will just say the parent lied. So if you have serious legal jeopardy as a website for allowing kids on when you shouldn't, that may not be a good solution.
Similarly, Google has an option to present a zero-knowledge proof age check from any credential in your Google Wallet. But Google will be very clear — I was with them today in Brussels — they are not taking any liability for the veracity of that credential. You need to have an arrangement with the issuer if you want a liability chain.
Of the two interoperability networks: Age Aware, from euCONSENT, where I am secretary general — so I should declare an interest in this nonprofit, which we set up to try to create interoperability — does maintain contracts between the providers. The latest entrant, the Open Age initiative by KID, is a for-profit company allowing people to create a passkey on their device — an age key, they call it — which anyone can use for a third of a cent. Very cheap, but there's no liability chain — no relationship between the website, the relying party, and the issuer.
Different use cases will be solved by different approaches. But if you have very high legal liability and a potential fine of 10 percent of your worldwide revenue, you're probably going to want to look the supplier in the eye and say, "How are you doing this check? Show me. I need to be super confident."
So when you say "liability," Dan — in my view, that is the thing that is going to define how this market works, whether it's Apple, Google, or government ID. You've got EUDI wallets, mobile driver's licenses in the US, the UK government talking about issuing digital ID. Lovely. But are we guaranteeing to websites that if they use a government ID and something goes wrong, they're held harmless? Nobody has really articulated that yet.
I was talking to Sparkasse — a bank in Germany that has done a deal with Google, now using banking data to give customers a credential in the Google Wallet. I said, are you charging for this? Are you taking liability if it goes wrong? It turns out Sparkasse is a publicly owned bank, owned by the different German states, so they're not trying to make a profit — they're actually giving away this service. It has some marketing appeal to their customers, but they're definitely not standing behind the quality of the age check. Apple has just announced you can create a digital ID with your passport in the US, which is lovely until someone figures out a way around it — and Apple are not going to take any liability if that goes wrong.
I'm glad you're so thrilled about liability — it means you're in the right job. But with my developer hat on, that sounds like a huge mess. What two or three tips would you give a developer or engineer at a startup who knows they need to do something on age verification and is worried about liability? What steps should they take? Engage with a vendor, engage with Age Aware or KID — what are the key takeaways if a developer walked up to you at a conference and asked for help?
It's not perfect yet, but the independent audit and certification route is a really good way to go. We shouldn't expect developers to become experts in due diligence on age verification systems. They should be able to say: "We're going to do an RFP, but we want you to be certified before we'll even consider you." After that you do your due diligence on pricing and everything else, but the entry requirement is: have you got the basic certification? And that certification isn't just about accuracy — in fact, that's almost the last thing it tests. It's about data protection, security, and privacy — the qualities that can destroy you as a digital service if things go wrong.
It's worth talking about a recent example — not necessarily good for the industry, but instructive. A major social media platform was using a very good age verification provider, in this case KID, who were subcontracting to other age verification providers. But their appeals process was being handled by the platform's customer services team using a completely separate piece of software. There were 70,000 passports sitting on that customer services system, and it leaked — because it wasn't going through the privacy-by-design, super-secure age verification solution. It was bolted onto the customer service team instead.
We have to be super careful about what we recommend and how we approach these things. If you can keep it all with a certified provider, then even when something goes wrong, you can go to the regulator or the judge and say, "Here's this certificate. I did my due diligence. I got this from a qualified, government-approved auditor saying this was a sensible approach." You're sorry it went wrong on this occasion and little Johnny managed to see some content he shouldn't have — but he was an exception, because we know that 99 percent of users were blocked.
Yeah. Listening to you talk about certification and auditing, it almost feels like credit card data — no developer in their right mind would consider storing credit card data themselves; they'd use a provider. I'm not in the business of selling providers, but what I'm hearing is that things are so nuanced, the liability is potentially so large, and things are shifting so much that finding a partner really makes a lot of sense. Is that something you'd agree with?
Yeah. The golden rule of a trade association is neutrality — I will never advise you to prefer one of our members over another. I would just say in general: go and find one that can show you they're certified.
Yeah, I wasn't asking for a specific recommendation — just making the analogy to Stripe, or any PCI-compliant provider. This is a legal minefield and you want experts on your side. Unless you want to hire 35 lawyers across all different jurisdictions — why would you? So go find an expert, and that'll probably be a vendor.
And I would also be really clear about which jurisdictions you intend to be compliant in, and be very transparent about it. Say, "We're going to be compliant in the UK, in the EU, in Louisiana, in Texas, but not in Florida" — and then you might need to geo-block Florida so customers can't easily access the site. Obviously everyone could use a VPN, and we know about those circumvention problems. But you can be very clear about where you're trying to be compliant, because it is a worldwide web and it's a big ask to be compliant everywhere on day one.
You raised circumvention in passing just now, and I'd love to hear more about your perspective on that. Can you talk more about circumvention and how you look at that problem?
When the UK brought in its implementation in July 2025 — we called it "AV Day" — it was a huge, big-bang rollout. We discovered that some sites were pretty easy to get through. You could use a PlayStation 5 avatar character — tell it to look left, look right, open its mouth, all the things we do to check that you're a live person. You could use a downloaded image of the UK prime minister's driver's license — a completely fake document that didn't even look right. What we learned was that the digital services had told their age verification provider, "We want to do age verification, but we want everyone to pass — can you turn off that clever tech that checks for a real person and an authentic document? We just want to ship everyone through."
This was a bit of an ethical crisis for us as a trade association. At the end of the day, the legal responsibility is with the platform — they have to decide what is a proper and proportionate approach to the relevant risk. Some of these platforms were deciding to have very low levels of assurance. It was horrible in the media — TikTok and others were telling all the kids how to get around it.
We settled on requiring our members to document in writing, and advise their clients, that if you turn off this piece of technology, you will no longer be compliant with the UK or Australia requirement. So if there's a regulatory investigation, the first thing that will have to be disclosed is that the client was warned they weren't doing this correctly. But my main point is: neither the avatar nor the fake document actually defeated the technology. Turning off the checks defeated the technology.
Because we weren't born yesterday — we've done this for a few years. Even with AI and deepfakes, we just finished a project with IDIAP, a group of academics in Switzerland who specialize in AI. We figured out how to spot certain telltale signs of deepfakes, and those clues have been shared privately among all the providers so they know how to spot those attacks. It's like cybersecurity — it's a cat-and-mouse game. There'll be new attacks; we'll spot them and deal with them. It won't be perfect, but as I said, we're not letting people onto an airplane. We can cope with a certain error rate.
On VPNs — Ofcom's regulation in the UK estimated only 250,000 more people started using VPNs each day after the legislation came in. Before this legislation, we had 1.4 million kids accessing pornography. Even if every one of those new VPN users was a child rather than an adult just trying to avoid the bother of an age check — and getting there requires capability, cash, and the ability to hide it from parents — it's still only 250,000 versus 1.4 million. We're still stopping a lot of kids. But the platforms can still detect when someone's using a VPN, and we say they should be scrutinizing that traffic for clues. A VPN just hides your IP address — it doesn't hide the currency, the timezone, or the language your browser is set to. On social media, it doesn't hide who your friends are, what your photo looks like, or when you last visited Sydney. There are plenty of ways to flag potential VPN users who should be age-checked. What we're saying is: in those cases, either do an age check or geolocate — prove you are in Malaysia or Thailand or somewhere with no restriction. Because at that point you'd have to either submit to an age check, or admit you're actually in Adelaide and too young to access the content.
The biggest lie being pushed by some of the regulated platforms is, "Oh, well, if we geo-block, it's not our fault if people are using VPNs." I've never seen any legislation that gives you an exception if you have kids on your site via a VPN. The legislation says no kids — it doesn't say no stupid kids.
That's a great way to put it. I think we're getting close to wrapping up. I did want to take a question: what age thresholds are most commonly used for online age verification?
Most of the time we start with 18 — that's almost the least controversial, because most people agree that children shouldn't see pornography or buy alcohol. We then have more controversial ground around social media. My view is you could have a social media platform for a seven-year-old that's safe, but sadly nobody's ever built one. The existing platforms are not safe for kids because of their addictive nature. So we're seeing prohibition, which hopefully will lead to people creating better-designed, age-appropriate platforms.
Then there's 13, because of COPPA — the US data protection law, the Children's Online Privacy Protection Act. That's an important threshold, but it hasn't been heavily implemented in the US because of a "don't ask, don't tell" approach: unless you tell the platform you're under 13, they don't have to treat you as under 13. It's different in Europe under GDPR, where ages between 13 and 16 apply for data protection purposes, but that has also not been very well enforced. I think that's changing — there are a lot of active investigations by the European Commission that will bring enforcement very soon.
One question was: how do age verification laws interact with encryption and end-to-end encrypted apps? Is that a concern, does it even come into play?
Not particularly. This topic often comes up around messaging and intervention around people sending child sexual abuse material through messaging apps — but that's not really an area we get into, because that's just illegal whatever your age. It's not quite pleading the fifth; it's just someone else's issue, not one for us.
One last question, and this gets back to the liability stuff — what are the enforcement mechanisms? You mentioned something like 10 percent of revenue. In general, what does enforcement look like?
Brilliant question. It's the worldwide web, right? There are 5 million adult pornography sites out there and very few are actually based in the US. So we can go to court and issue a fine — but that's not going to make much difference if you're based in Kuala Lumpur.
What the UK has done is take powers to intervene on critical business services: hosting, search, and payment — with payment being the key one. They can require Visa and Mastercard to refuse to take payments on behalf of noncompliant sites. I think that is going to be a really important mechanism for exercising power over websites based overseas, much more so than site blocking.
We've seen site blocking attempted. In Germany, they blocked a website — let's call it xx.de. The following day it became xx.eu and somehow managed to redirect all the traffic. The legal power was only to block the first site, not the new one. Site blocking is never going to be effective — you've got to find more intelligent ways to persuade people to be compliant.
Like you said, hitting the wallet is probably the most effective approach — that's what a lot of these folks are in it for. Well, I think we want to wrap things up. Thank you so much, Iain, for joining us. I learned a ton. I'm going to dig up — or maybe ask you for — the IEEE standard and the ISO standard you mentioned so we can share those with viewers. I learned that how you move your fingers can indicate your age — hopefully that means I'm still young, but who knows.
You don't look a day over 21 to me, Dan. Which is as it should be — we should never let humans do age estimation. We need to trust the algorithms.
Totally. Do you have any final closing thoughts before we say goodbye?
Let me just finish on this. All we are trying to do is apply what we've done in the real world for over a hundred years. Last year was the hundredth anniversary of age verification — in 1923, the first female MP in the UK passed a law setting the minimum age of 18 to buy alcohol in a pub. A hundred years on, we're just saying: we wouldn't let our kids walk downtown and go into a pub, a bar, a casino, a strip club without someone checking their age — so why would we let them do that online? We will look back in ten years' time on what we were exposing our children to online with absolute horror. We've lost one generation. Let's not lose another.
That's a great way to end it. Thank you so much, Iain — thanks for sharing all your knowledge. Really appreciate your time. And thanks to everyone watching. We appreciate you all.
My apologies again for keeping people waiting at the beginning.
Sounds good. Thanks, everyone. Bye.
