Biometric Gates Cut the Queue. They Also Create a Liability You Have to Design For

Biometric entry gates at this tournament did what they were bought to do. High-speed facial recognition cross-referenced a fan’s face against the tournament credential and ticketing database in under a second, and queues that historically took minutes per person collapsed.

That is a genuine operational win, and I am not going to pretend otherwise. Getting 80,000 people through a perimeter safely is a hard problem, and slow queues are themselves a safety hazard — crushes happen at chokepoints, not in stadiums.

But every biometric deployment I have reviewed has the same structural weakness, and it has nothing to do with match accuracy. It is that the organisation deploying it never decided, in writing, what happens to the data after the gate opens.

The three questions that decide whether this is safe#

Skip the philosophy. If you are building or buying a biometric access system, these are the questions that determine your actual exposure.

What is stored — an image or a template? These are not the same liability. A stored photograph is a photograph: human-readable, reusable in any other system, catastrophic in a breach. A biometric template is a derived vector, typically not reversible to a recognisable face, and usable only against the same algorithm. Templates are meaningfully safer. They are also still biometric personal data under GDPR Article 9, the Illinois BIPA regime, and most modern frameworks — “it is just a hash” is not a defence anyone has won with. Store templates, not images, and do not tell yourself the distinction exempts you.

Where does matching happen? On-device matching against a template held on the user’s own phone or credential is a fundamentally different architecture from central matching against a database of every attendee. The first has no honeypot. The second has one, and it is the most attractive target in your estate. Same user experience, radically different breach blast radius.

When is it deleted? This is where nearly everyone fails. The system is procured for entry. Entry ends when the event ends. Yet the default configuration on most platforms retains enrolments indefinitely because deletion was nobody’s line item. If you cannot point to an automated job that purges templates on a defined schedule, your retention policy is a document, not a control.

Function creep is the actual risk#

The breach scenario gets the headlines. In practice, the thing that goes wrong is duller and more common: the dataset gets used for something it was never authorised for.

The pattern is always the same. A biometric enrolment database is built for access control. Six months later someone asks whether it could confirm which staff were in the building during an incident. That is reasonable. Then whether it could flag people who appear frequently. Then whether it could feed a watchlist. No single step looks unreasonable, and the endpoint is a surveillance system that no one ever approved and that the original consent notice does not cover.

Defending against this is an architecture problem, not a policy problem, because policies lose arguments with executives and architectures do not.

• Purpose-bind at the schema level. The entry system gets a template store it can match against and nothing else. Match events go to an operational log with a short TTL. There is no join key connecting templates to a durable behavioural history, because you did not create one.
• Log every read, not just every write. Access to a biometric store should be as audited as access to a payroll system. If you cannot produce a list of every query against the template table last month, you cannot investigate misuse.
• Separate the identity check from the analytics. Crowd management genuinely benefits from knowing that section 118 is filling faster than expected. It does not need to know who is in it. Anonymous density counting and identity verification are two different systems that should not share a store — which is exactly why the stadium crowd cameras were described as detecting unusual density without necessarily identifying individuals. That distinction should be enforced by wiring, not by intent.

The fallback path is not optional#

Every biometric system has a false rejection rate. It is never zero, and it is never evenly distributed — accuracy across demographic groups has been a documented and persistent problem in face recognition, and no vendor claim removes your obligation to handle the failures.

So the design question is: what happens to the person the gate refuses?

If the answer is “they get pulled aside by security in front of a crowd”, you have built a system that produces a humiliating experience concentrated on the people it works worst for. If the answer is “there is a staffed manual lane, clearly signed, with no penalty for using it”, you have built something acceptable.

The same applies to opting out. A consent notice that technically permits refusal but routes refusers into a two-hour queue is not consent in any regulator’s reading, and increasingly not in any court’s either. The non-biometric path has to be genuinely usable, not nominally available.

Where we apply this outside stadiums#

Two verticals we work in are actively deploying biometrics right now, and both need this discipline more than a football tournament does because their subjects cannot walk away.

In a Hospital Management System, biometric staff authentication at medication cabinets and record terminals is a real improvement over shared passwords, which are the single worst control in healthcare IT. But patient-facing biometric identification is a different proposition entirely — it touches special category health data, involves people who are frequently not in a position to give free consent, and the temptation to reuse the identity graph for anything else must be designed out rather than promised away.

In a School ERP, biometric attendance and cashless catering are widely sold and widely deployed. Children cannot meaningfully consent, parental consent is often bundled into an enrolment pack nobody reads, and the retention question — does a template persist after the child leaves the school — is almost never answered in the contract. We advise on-device or on-card matching for these deployments wherever the vendor supports it, precisely so there is no central database to inherit.

A short checklist before you sign#

If you are evaluating a biometric system, get written answers to these before procurement, not after:

1. Templates or images, and can the vendor demonstrate the template is non-reversible?
2. On-device, on-card, or central matching?
3. What is the automated deletion schedule, and who can override it?
4. Is every read of the biometric store audited, and can you export that audit?
5. What is the documented false rejection rate, and is it broken down by demographic group?
6. What is the manual fallback, how is it staffed, and how is it signposted?
7. Under what contractual terms can the vendor access, aggregate, or train on your data?

Question seven catches more problems than the other six combined.

The stadium version of this worked because it had a hard end date, a narrow purpose, and enormous scrutiny. Your version will have none of those. The controls have to come from the design.

---

Biometrics are easy to buy and hard to retire. We design identity systems that stay inside the purpose they were approved for. Talk to us before you sign.