On Thursday 10 September 2026 the Yoti ID app stops being available in the Apple and Google app stores in Spain (Biometric Update). No breach. No accuracy failure. No user data compromised, which Yoti was careful to say in its own statement (Yoti).
The company was told by Spain’s data protection regulator that it has to offer a way into the app that does not use your face. It looked at the options, decided they all make the product weaker, and left the country instead.
That decision is worth reading closely even if you have never touched Yoti’s product, because the reasoning applies to any service that stores something derived from a face and compares a new face to it later. Most age assurance stacks do exactly that somewhere. Ours does, and I will get to that part.
Three findings, and only one of them is about biometrics
The Spanish data protection agency, the AEPD, fined Yoti 950,000 euros in March 2026 across three separate infringements, with six months to put things right (ID Tech, citing decision PS/00164/2025). The investigation started in December 2023. The three parts are very different in kind, and the coverage tends to blur them into one story about biometrics.
500,000 euros under Article 9. During account setup the app compares a live selfie against a stored biometric template. Yoti argued this is authentication, not unique identification, and so falls outside Article 9. The AEPD rejected that and found Yoti had no lawful basis for the processing. This is the finding with consequences beyond Yoti.
200,000 euros under Article 7. Consent was invalid for two reasons, and neither is architectural. Users could click past the privacy policy screen without ever opening it. And the app defaulted to consent for using biometric data in research and development, with no affirmative opt-in. Those are user interface defects. A team could fix both in a sprint.
250,000 euros under Article 5(1)(e). Retention. Geolocation used to work out which age rules apply, kept for five years. Video recordings from liveness detection, kept for 30 days. Fraudulent identity documents kept past their original purpose so they could train the verification models.
Two of the three findings are hygiene. Read your own consent screen as if you were a hostile regulator, put a clock on every artifact your pipeline produces, and you avoid 450,000 euros of that fine. The interesting one is the first.
The sentence the case turns on
Article 9(1) prohibits “processing of biometric data for the purpose of uniquely identifying a natural person” unless one of the exceptions in Article 9(2) applies. So the whole question is whether a one-to-one match against a template you enrolled earlier counts as uniquely identifying someone.
Yoti’s argument has real force. There are two different operations here and engineers keep them apart for good reasons:
- One-to-many search. Take a face, search it against a database of many people, return who it is. Nobody disputes this is identification.
- One-to-one match. The user has already told you who they claim to be. You compare the new sample to that one stored template and return true or false. You learn nothing you did not already have.
On that reading, one-to-one is confirmation of a claim, not discovery of an identity. It is the same shape as checking a password.
The trouble is the text. Article 4(14) defines biometric data as personal data from specific technical processing of physical characteristics “which allow or confirm the unique identification of that natural person”. The word “confirm” is doing a lot of work there, and it points the other way. Recital 51 points the same way even more plainly: photographs count as biometric data “only when processed through a specific technical means allowing the unique identification or authentication of a natural person”. The drafters wrote authentication into the recital themselves.
So the AEPD is reading the words as written. Yoti is reading the purpose. I think the AEPD has the better textual argument and Yoti has the better engineering argument, and that is exactly the sort of split that ends up in court. It is in court: Yoti is appealing to the Audiencia Nacional, the Spanish High Court.
Do not plan around a reversal. Plan around the text, and treat a win on appeal as a bonus.
One thing is not in dispute, and it matters more than the rest. If you never enrol a template, there is nothing to match against, and this finding has no grip on you at all.
Why the alternative you add sets your real assurance level
Here is where the case stops being a Spanish legal curiosity and starts being an engineering problem.
Suppose you accept the AEPD’s reading. You are processing special category data, so you need a gateway from the Article 9(2) list. The obvious one for a consumer product is 9(2)(a), explicit consent. Now Article 7(4) arrives:
when assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.
If the only way into the app is your face, consent is not a choice. So consent is not freely given. So you have no gateway. To rescue the consent, you must offer a way in that does not use the face.
The Age Verification Providers Association, which is the trade body for this industry, set out the consequence in a statement in June (AVPA, reported by Biometric Update). Every practical non-biometric alternative binds to a device or to a secret. A PIN, a password, an SMS code, an email code. All of them can be handed to somebody else.
And handing it over is the attack. This is not a fraudster stealing a credential. It is a fifteen year old asking their father for the four digits, and the father typing them in himself because he does not think it matters.
The AVPA put it in one line that is hard to argue with: a digital identity secured by a biometric cannot be lent to your younger sibling, and one secured by a PIN can.
Passkeys used to be the answer people reached for here. They are not, any more. Apple’s Passwords app supports shared groups where several trusted people hold the same passkeys, and individual passkeys can be sent over AirDrop (Apple). Google Password Manager syncs passkeys across every device on the account. A passkey is now a thing that can travel between people by design, which is precisely the property that made it attractive for binding and precisely the property it no longer has.
The security consequence follows directly, and it is the ordinary weakest-link argument applied to a rule rather than to a network. When a user chooses between two authentication paths, an attacker chooses too, and the attacker picks the cheaper one. Your assurance level is the minimum across the options you offer, not the maximum. The face match constrains the honest users who picked it. It constrains nobody else.
So if you publish an effectiveness number for your age gate, and you offer a PIN alternative, the number you should be publishing describes the PIN.
The regulator’s case is not silly
It would be easy to write this up as a regulator that does not understand security. That is not what is happening, and the exclusion argument deserves a fair hearing because it is empirically grounded.
The AEPD set out its position at length in a July 2026 post on eIDAS 2.0, the EU Digital Identity Wallet and the GDPR, reported by Biometric Update. Requiring face or fingerprint with no alternative produces systematic authentication failures for particular groups. The regulator names them: worse algorithm performance for women, for people with darker skin, and for facial asymmetry. Older people whose features have changed since enrolment struggling with liveness checks. People whose physical disabilities make it hard to hold a phone at the angle the capture flow expects.
Then there is the category the AEPD calls privacy-based self-exclusion. Some people will simply not give their face to a commercial service. If the face is the only door, those people lose access to something they are legally entitled to use, and they lose it because of a preference the law elsewhere encourages them to have.
That is a real cost, it falls on identifiable groups, and “buy a better model” does not make it go away.
The fair criticism of the AEPD’s position is narrower and it is about the remedy rather than the diagnosis. The regulator is asking for an alternative that provides equivalent assurance, and by the assessment of NIST and others there is no non-biometric binding method that reaches equivalence. In-person checking comes closest and is slower and harder to reach. So the AEPD has identified a genuine harm and prescribed a cure that does not exist yet, and the effect of prescribing it anyway is that the weakest option becomes the one with the clearest legal path.
The AVPA’s summary of that is the sharpest sentence anyone has written about this case: the most secure authentication option becomes legally the most difficult to deploy, and the least secure option becomes the path of least regulatory resistance.
The AVPA has asked the European Data Protection Board to issue guidance before the uncertainty spreads. Nothing has been published. The stakes are larger than one vendor, because every member state has to offer citizens a digital identity wallet by the end of 2026, and the EU’s own architecture framework for that wallet lists PIN alongside biometrics as an unlock method.
Article 6 has an exit. Article 9 does not.
At this point most compliance advice reaches for the obvious escape. Stop relying on consent. You are running an age check because the law tells you to, so use a legal obligation basis instead, and Article 7(4) never fires.
For ordinary personal data that works. Article 6(1)(c) covers processing necessary for compliance with a legal obligation, and a duty under the Online Safety Act or the Digital Services Act fits it comfortably.
For biometric data it does not work, and this is the part teams get wrong. Article 9 is a separate prohibition with its own closed list of exceptions, and there is no general legal-obligation door in it. Go through the list with a commercial age gate in mind and almost everything falls away. Employment and social security law, no. Vital interests, no. Not-for-profit bodies, no. Data the person has manifestly made public, no. Legal claims, no. Health and social care, no. Public health, no. Archiving and research, no.
You are left with two doors.
Article 9(2)(a), explicit consent. This is the door the Yoti decision just closed for anything mandatory, because a mandatory step cannot produce freely given consent.
Article 9(2)(g), substantial public interest, on the basis of Union or Member State law. This door is real, and protecting children online is about as clear a substantial public interest as exists. But read the second half of the clause. The condition has to be provided by a specific law, and most member states have not written one that covers biometric age assurance. In the UK, using this route means finding a condition in Schedule 1 Part 2 of the Data Protection Act 2018, and the closest fit, the safeguarding condition at paragraph 18, is drafted for situations where asking for consent would prejudice the protection of the child. That is not a routine age gate on a signup page. It also requires an appropriate policy document in place at the time of processing.
So the honest position is this. There is no clean Article 9 gateway for routine biometric age assurance across most of Europe today. The door that is easy to reach is unstable, and the door that is stable is missing in most jurisdictions.
That is not a comfortable thing for an age assurance vendor to write down. It is what the law currently says.
Notice which situations are hardest. A consumer wallet that a person chooses to install is the worst case, because consent is the natural basis and Article 7(4) fires straight away. Yoti was in the worst case. A platform running a statutory age gate has a better argument on Article 6 and the same problem on Article 9. Nobody is clean.
The way out is architectural, not legal
If both doors are difficult, the durable answer is to stop needing a door.
Article 9 only bites on biometric data processed for the purpose of uniquely identifying a person. Recital 51 confirms the reverse: a photograph is not special category data unless it goes through a specific technical means allowing unique identification or authentication. An age estimate that looks at a face, returns a number, and keeps nothing is not enrolling anybody and not matching against anybody. There is no template, no comparison, and no identification.
Some commentators read the AEPD as treating facial age estimation itself as special category data regardless. Biometric Update framed the question that way when covering the withdrawal, and asked whether a person has ever been identified from age estimation output alone. Be careful with that reading. The finding in PS/00164/2025 is about the selfie-to-stored-template comparison at account setup, not about estimation with nothing retained. Those are different processing operations and they deserve different analysis. Treat the broad reading as a risk to watch, not as the current holding.
The practical split for a design document is one question, asked twice:
- Is this person over the threshold? One-off. Transient. No enrolment, no template, nothing to compare a future sample to. Weak or no Article 9 exposure.
- Is this the same person as last time? Re-identification. Requires something stored and something matched. This is the operation the AEPD fined.
Nearly every age assurance product does both, and nearly every one of them writes a single legal basis across the whole flow. That is how a consent notice ends up covering a mandatory step.
What to change this quarter
Concrete work, in the order I would do it.
- Write the legal basis per processing step, not per product. One row per operation: what is processed, why, which Article 6 basis, which Article 9 gateway if any, how long it is kept. Most teams discover in this exercise that they have one basis stretched over four operations, and that the stretch happens exactly where it should not.
- Find every stored template and ask whether it earns its place. A face embedding kept “in case we need it” is Article 9 exposure with no purpose attached. If re-identification is a feature nobody uses, delete the feature and the vectors go with it.
- Put a clock on every artifact, including the ones that are not the point. Yoti did not get fined 250,000 euros for keeping face templates. It got fined for geolocation kept five years, liveness video kept 30 days, and rejected documents kept to train models. Training is a separate purpose. It needs its own basis and its own retention answer, and it will not inherit either from the verification.
- If you offer a non-biometric alternative, report the floor. Work out the assurance level of the weakest path a user can select, and use that number when a regulator asks how effective your measure is. Quoting the strongest path is how a service ends up in an enforcement letter having described a control it did not really have.
- Ask your vendor two written questions. Which of your processing steps relies on consent as the legal basis, and what happens to the flow when a user declines? A vendor that cannot answer the second question has not thought about Article 7(4), and it is your enforcement exposure as much as theirs.
- Check whether your member state has an Article 9(2)(g) condition that actually covers you. This is a jurisdiction by jurisdiction answer and it is the single most useful hour of legal time you can buy this quarter. It is worth more than another vendor certification.
Where Xident sits, including the part we have not solved
Two of our paths land on opposite sides of this line, and it would be dishonest to describe only the comfortable one.
Path A is the architecture this decision rewards. Client-side age estimation runs on-device in the browser. No image and no biometric data reaches our servers. Only the pass or fail result does. Nothing is enrolled, nothing is stored, and there is no template for anyone to match a future sample against. This is not a legal workaround. It is the normal case for us, and it is the reason most checks a customer runs create no Article 9 exposure at all.
Path B is inside the same problem as everyone else. When client-side estimation is inconclusive and the user verifies with an identity document, we create a face embedding to match the person to the photo on the document. That embedding is a 512-dimensional vector, encrypted at rest with AES-256-GCM and isolated per customer, and we keep it for 12 months from the day of the check whether or not the person has a Xident ID (privacy policy). Document images are deleted within 24 hours. A separate embedding is stored against a Xident ID for returning-user lookup, which is re-identification by definition.
And our stated basis for biometric processing is explicit consent under Article 9(2)(a), collected separately from the terms. That is the basis the AEPD attacked. We are not writing about someone else’s problem.
Three things follow, and I would rather state them than have a customer find them:
We think the split itself is the strongest part of the design. A Check covers browser-based age checks, liveness, returning-user Xident ID lookup and OAuth. A Verification is the document path with text extraction and a face match. On Growth they are 0.02 and 0.20 euros. That ten-times gap exists for cost reasons, but the useful consequence here is that the cheap path is also the one that stores nothing, so the expensive Article 9 operation is the exception rather than the default.
Twelve months is a retention period we chose, not one a regulator blessed. It is defensible as a fraud and dispute window. It is longer than the 24 hours we give document images, and if your own risk assessment wants it shorter, that is a conversation worth having rather than a setting to accept.
We do not yet have an answer to the Article 7(4) question on Path B that satisfies us. A non-biometric alternative to the document face match would let a user pass a document check without proving the document is theirs, and that is the failure the whole path exists to prevent. Nobody in this industry has solved that, which is why the AVPA went to the EDPB rather than shipping a fix. We are watching the Audiencia Nacional appeal and any EDPB guidance, and we will say plainly what we change when either lands.
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 path end to end, including the point where an embedding gets created, and see for yourself what the flow asks a user to consent to before you commit to it.
The short version
A vendor is leaving a European market rather than weaken its product, and the mechanism that pushed it out is not a rule about biometrics. It is a rule about consent.
Matching a live face to a stored template counts as uniquely identifying someone under the words the GDPR actually uses. That drops you into Article 9. Article 9 has a closed list of exceptions and, for a commercial age check, only two of them are reachable. Consent collapses the moment the step is mandatory. Substantial public interest needs a national law that in most countries has not been written.
The alternative a regulator will accept is a shared secret, and a shared secret is exactly what a minor borrows from an adult. Adding it does not make your age gate compliant and secure. It makes it compliant and weaker, and the number you can honestly publish about your gate drops to the weakest path you offer.
The only move that holds up is to stop creating the data. Estimate the age, return the number, keep nothing. Reserve enrolment and matching for the cases that genuinely need to know whether this is the same person as last time, write the legal basis for those cases separately, and put a clock on everything.
Two doors, and one of them just closed. Build so you do not have to walk through either.
Xident provides age verification and age estimation infrastructure with client-side estimation that keeps biometric data on the device, and a separate document Verification path for the cases that need it. Our privacy policy sets out exactly what is stored and for how long. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications. Talk to us about which of your processing steps is really relying on consent.
