Your face is not a password: designing biometric flows people can trust

You can change a leaked password in a minute. You can cancel a stolen card in five.

You can't change your face.

That's the whole dilemma of biometrics in one sentence. Fingerprints, faces, irises and voices make identity checks fast and convenient, and they're becoming the default in banking, payments, travel and government services. But they're also permanent, intimate and, once they leave your device, very hard to take back.

Most of the debate about facial recognition happens at the level of policy and ethics. That matters. But a lot of the real decisions get made somewhere much less glamorous: in the onboarding flow, the consent screen, the error state and the database schema. In other words, by people like us.

Not a neutral tool

Biometric systems are often presented as purely technical: a camera, a model, a match score. But every one of them is designed by people with priorities, trained on data that reflects the world as it is, and deployed in places with very different power relationships.

The Argentine-Mexican anthropologist Néstor García Canclini has written about how, in societies shaped by insecurity, people increasingly accept surveillance and control as the price of feeling safe. Biometrics fit that pattern perfectly: they're sold as protection, and they often are. But the same infrastructure that verifies your identity at a bank can also be used to track, profile or exclude.

This is happening at national scale. In Mexico, for example, 2026 brought a biometric version of the CURP (the national population ID) being rolled out progressively, and a requirement to link every mobile phone line to a person's identity. Whatever you think of those policies, they mean that millions of people will go through identity flows designed by product teams, often on cheap phones and slow networks.

The question for us isn't only "should this exist?" It's also "if we're building it, how do we build it so it respects the person on the other side?"

Four places where design decisions matter

1. Consent that is actually consent

A pre-checked box under a wall of legal text is not consent. Neither is a flow where the only way forward is to accept.

Good biometric consent is:

• Specific: say exactly what you capture (a face template, not "your data") and what for.
• Separate: not bundled with terms of service or marketing permissions.
• Optional when possible: if there's another way to verify identity, offer it on the same screen, with the same visual weight.
• Reversible: tell people how to withdraw consent and delete their data, and make that path real.

<fieldset>
  <legend>How do you want to verify your identity?</legend>
  <label><input type="radio" name="verify" value="selfie" /> Take a selfie (we compare it once with your ID photo, then delete it)</label>
  <label><input type="radio" name="verify" value="document" /> Upload your ID and answer a few questions</label>
  <label><input type="radio" name="verify" value="branch" /> Verify in person at a branch</label>
</fieldset>

Notice what's not there: a default.

2. Bias is a product bug, not an edge case

Facial recognition systems don't fail equally for everyone. In 2018, Joy Buolamwini and Timnit Gebru's Gender Shades study found commercial gender classifiers performed far worse on darker-skinned women than on lighter-skinned men. In 2019, NIST's large evaluation of face recognition algorithms found demographic differences in error rates across many of the systems it tested, varying by algorithm.

Fingerprints have their own version: scanners struggle with worn or dry skin, which affects older adults and people who do manual work.

For a product team, that means:

• Ask your vendor for error rates broken down by demographic group, not just one global accuracy number.
• Monitor your own failure rates by device type, region and age band, if you can do it without collecting more sensitive data than you need.
• Never make biometrics the only door. When the model fails, a person should have a dignified alternative, not a dead end.

3. Errors that don't accuse

When a face match fails, the person usually hears something like "We couldn't verify your identity." To them, that can sound like "We think you're lying."

Most failures are about light, angle, camera quality or network, not fraud. Say so:

"We couldn't get a clear photo. Try facing a window or a lamp, and hold the phone at eye level. You can also verify with your ID instead."

Give a reason, a next step and an exit. And never lock someone out after a few failed attempts without a human path.

4. Keep less, for less time

The safest biometric data is the data you never stored.

• Match on device when you can. Platform features like Face ID and Android's BiometricPrompt keep templates on the phone; your server never sees them.
• Store templates, not images, and only when strictly necessary.
• Set a retention period and actually delete. "We might need it later" is not a reason.
• Separate biometric data from the rest of the user record, with stricter access and audit logs.
• Write it down in plain language in the flow itself, not only in the privacy policy.

Transparency is part of the interface

People trust what they understand. If your verification flow explains what's happening at each step ("Comparing your selfie with your ID photo… done. The selfie has been deleted."), it does more for trust than any badge in the footer.

And accountability starts inside the team. Someone should own the answers to: What do we collect? Where is it? Who can access it? When is it deleted? What happens when it fails? If nobody can answer, that's the first bug to fix.

The dilemma doesn't go away

Biometrics will keep spreading because they're convenient, and often because laws require identity checks. Security and privacy will keep pulling in opposite directions.

We won't resolve that tension from a pull request. But we decide, every day, whether consent is real, whether a failed match humiliates someone, whether there's another way in and how long a face lives in our database.

Your users can't change their faces. The least we can do is design as if that mattered.

This piece builds on an essay on facial recognition and digital human rights I wrote during my master's in Communication and Digital Humanities. It's part of my series on the human side of interfaces.

Have you built or used a biometric flow that got this right, or very wrong? Tell me in the comments.

References

• Buolamwini, Joy, and Timnit Gebru. "Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification." Proceedings of Machine Learning Research, 2018.
• García Canclini, Néstor. Ciudadanos reemplazados por algoritmos. Bielefeld University Press / CALAS, 2019.
• Grother, Patrick, Mei Ngan, and Kayee Hanaoka. Face Recognition Vendor Test (FRVT) Part 3: Demographic Effects. NIST, 2019.