Biometric Authentication for Mobile Apps:Face ID, Touch ID, BiometricPrompt, and the Law Around Them

Biometric authentication on a modern phone is a local, on-device comparison — not a lookup against a stored photo, and not a transmission of your fingerprint or face anywhere. A sensor captures a physical measurement, a matching algorithm compares it against a template, and both the capture and the comparison happen inside a piece of hardware specifically isolated from the rest of the operating system and from every app running on the device, including yours.

On iOS, that hardware boundary is the Secure Enclave — a separate coprocessor with its own encrypted memory that the main application processor cannot read directly. On Android, it is a Trusted Execution Environment or, on higher-end devices, a discrete secure element, enforced through the Android Keystore system. Both platforms are built around the same design principle: your app requests an authentication, the operating system performs the actual biometric capture and comparison inside hardware it controls, and your app receives back either a simple success/failure result or — in the pattern every serious implementation should use — permission to operate a cryptographic key that was generated inside that same hardware boundary and can never be extracted from it.

This architecture is also why headlines about a "biometric data breach" at a company like Clearview AI describe a fundamentally different system than the one this guide covers. Those systems build a central database of biometric templates to match one face against millions of others — a one-to-many identification problem. Face ID unlocking your phone, or BiometricPrompt unlocking your banking app, is a one-to-one verification problem: is the person in front of the sensor right now the same person who enrolled on this specific device. The two use cases get conflated constantly in both press coverage and vendor marketing, and the legal and architectural stakes are genuinely different for each one — a distinction this guide keeps coming back to.

We wrote this guide because most of what's published on biometric authentication either stops at "call this one API method" — a real integration path, but not the full picture of what a correct implementation, a correct threat model, and a correct compliance posture actually require — or comes from an identity-verification vendor whose interest is in selling a KYC platform for a problem (new-identity verification) that most mobile teams don't actually have, when what they need is much simpler: gate app re-entry and a handful of sensitive in-app actions behind the device's own biometric hardware.

Apple's LocalAuthentication framework is the entire supported surface for biometric authentication on iOS, iPadOS, and macOS. It exposes an LAContext object with a small number of policies, the two that matter for almost every app being deviceOwnerAuthenticationWithBiometrics (Face ID or Touch ID only, no fallback) and deviceOwnerAuthentication(biometrics with an automatic fallback to the device passcode). Apple's own guidance and every serious implementation we've reviewed default to the second policy — a biometric failure should never be a dead end for a legitimate user.

There are two distinct ways to use LocalAuthentication, and the difference between them is the difference between a real security control and a convenience feature that looks like one. Logging a user into your app with Face ID or Touch ID — a bare call to evaluatePolicy— returns a boolean result your app then acts on. That pattern is appropriate for re-entry into an already-authenticated session: "let this returning user back into the app without retyping their password." It is not, by itself, a cryptographic guarantee of anything, because the check and the decision both happen in your app's own process.

For anything of higher value — releasing a stored credential, authorizing a payment, signing a document — the correct pattern is accessing a Keychain item protected by Face ID or Touch ID, or generating a key directly inside the Secure Enclave with SecKeyCreateRandomKeyand an access-control object requiring biometric presence. In both cases, a successful biometric check is what actually unlocks the operation — there is no separate boolean for an attacker to intercept and forge, because the key material never leaves the Secure Enclave regardless of what your app's own code does or doesn't check.

• Face ID: Uses the TrueDepth camera system to build a depth map of the user's face, compared against an enrolled representation entirely inside the Secure Enclave.
• Touch ID: Uses a capacitive fingerprint sensor, with the resulting fingerprint data likewise processed and compared only inside the Secure Enclave.
• Device passcode fallback: Built into deviceOwnerAuthentication automatically — Apple treats a correctly entered passcode as an equally valid proof of device ownership, not a downgrade.

If you're weighing a native Swift implementation against a React Native or Flutter cross-platform base, this is one of the places worth double-checking directly: verify that whichever biometric plugin you use actually wraps Keychain/Keystore key protection rather than simply calling the OS prompt and returning a boolean to JavaScript or Dart with no hardware-backed key behind it — the red flags section below covers exactly this failure mode.

Android's equivalent surface is BiometricPrompt, part of the androidx.biometric library, which superseded the older, fingerprint-only FingerprintManagerAPI. The reason Android's design differs meaningfully from iOS's starts with a fact iOS developers rarely have to think about: Android ships across thousands of hardware configurations from dozens of manufacturers, so a fingerprint or face sensor on one device is not a guaranteed match in security quality for the sensor on another.

Google's answer is a strength classification defined in the Android Compatibility Definition Document and exposed to developers through BiometricManager.Authenticators: BIOMETRIC_STRONG (Class 3, formerly called "Strong"), BIOMETRIC_WEAK(Class 2, formerly "Weak"), and a lower Class 1 tier not exposed through BiometricPrompt at all. Only a Class 3 authenticator meets the false-acceptance-rate ceiling and spoof-resistance bar required to gate a cryptographic key or a payment; Class 2 hardware can unlock the device's screen but should never, by itself, authorize anything of real value.

Google's own documentation is direct about the recommended pattern for combining these: use Credential Manager for a user's very first sign-in on a device, and BiometricPrompt — or Credential Manager again — for subsequent re-authorizations, with BiometricPrompt favored when you need finer control over the prompt's appearance and behavior. Critically, setNegativeButtonText() and setAllowedAuthenticators(BIOMETRIC_STRONG or DEVICE_CREDENTIAL) cannot be set on the same prompt — the platform treats the device-credential fallback as replacing the need for a separate "cancel and use password" button, not supplementing it.

The Keystore-integration half of this is what turns a biometric prompt into an actual security control. Generating a key with setUserAuthenticationRequired(true) ties that key's availability to a successful biometric (or device-credential) check; for operations that must re-verify presence every single time rather than relying on a time window, setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG or KeyProperties.AUTH_DEVICE_CREDENTIAL) forces authentication on every key use, with no cached grace period. A CryptoObject wrapping a Cipher, Signature, or Mac is what BiometricPrompt actually unlocks in this pattern — not a plain boolean your own code then has to trust.

React Native, Flutter, and similar cross-platform frameworks do not reimplement biometric authentication — they cannot, because Face ID, Touch ID, and Android's biometric sensors are only reachable through Apple's and Google's own native APIs. What they offer instead is a plugin that bridges JavaScript or Dart code to a native Swift/Kotlin implementation underneath, and the quality of that bridge is exactly where the guarantees this guide describes can quietly disappear.

A well-built bridge does what a native implementation should: it generates and gates a Keychain item or a Keystore key on the native side, and only exposes a signature or a decrypted payload to your cross-platform code after that hardware-backed check succeeds. A poorly built one — and we have reviewed several in production apps during security audits — calls the native biometric prompt purely for its UI, discards whatever hardware-backed result it produced, and returns a plain true/false to JavaScript with no cryptographic artifact behind it at all. The visible prompt looks identical to a user in both cases; the security posture is not remotely equivalent.

• Verify the plugin's native source: Before adopting a biometric plugin in a cross-platform project, read its native Swift/Kotlin implementation directly — specifically, confirm it creates a Keychain item or Keystore key with a biometric access-control flag rather than only invoking LAContext.evaluatePolicy or BiometricPrompt.authenticate and returning a boolean.
• Test the failure path, not just the happy path: Force a biometric failure (wrong finger, covered camera) in a debug build and confirm the fallback to passcode/PIN actually fires through the bridge — this is the integration point most often left broken because it's rarely exercised in a quick demo.
• Don't trust a boolean across the bridge for high-value actions: For anything beyond app re-entry, require the native side to produce and return a signed payload your server verifies — never a boolean that crossed the JavaScript/native boundary with nothing cryptographic behind it.

A passkey is a FIDO2/WebAuthn credential: a public-private key pair where the private key is generated on, and never leaves, a specific device. The biometric prompt a user sees when signing in with a passkey is not a separate feature from the Face ID or BiometricPrompt integration this guide covers — it is the exact same platform mechanism, invoked by the operating system to satisfy what the WebAuthn specification calls "user verification": proof that the person requesting use of the key is its legitimate device owner.

This matters for a mobile team for two practical reasons. First, if you have already built a correct biometric-gated Keychain or Keystore integration for your own app's authentication, you have already built most of the hard part of supporting passkeys for sign-in — the remaining work is largely a WebAuthn/FIDO2 protocol integration on top of hardware access you've already wired up. Second, the trend line makes this decreasingly optional: the FIDO Alliance's 2026 State of Passkeys report, drawn from a Sapio Research survey of 11,000 consumers across ten countries conducted in April 2026, estimated roughly five billion passkeys in active use worldwide, with 90% consumer awareness, 75% having enabled a passkey on at least one account, and 49% using one regularly when available.

Liveness detection — formally, presentation attack detection, or PAD — is the set of techniques a biometric system uses to confirm it is looking at a live person in front of the sensor right now, as opposed to a photo, a silicone mask, a video replay, or a synthetic image injected directly into the camera's data stream by software rather than presented to the physical lens at all. It is not a concern that applies to Face ID or Touch ID unlocking your own phone — Apple's Secure Enclave-based matching already accounts for presentation attacks as part of its own hardware design, and you have no ability to alter that regardless. It is a serious, active concern for any identity-verification or KYC flow where your app — or a vendor you've integrated — is deciding whether a new, unknown person's face matches a document they've presented.

The threat has changed shape recently. Generative AI has made convincing synthetic faces and real-time face-swap video cheap and fast to produce, at exactly the moment biometric identity verification became the default onboarding step for banking, fintech, and marketplace apps. Group-IB, a threat-intelligence firm, documented 8,065 biometric injection-attack attempts against a single financial institution over an eight-month span in 2025. iProov, a liveness-detection vendor, separately reported a 2,665% year-over-year rise in virtual-camera injection attacks across 2024 — attacks that bypass the physical camera lens entirely by injecting a fabricated video feed directly into the software pipeline a device normally trusts as camera input.

A concrete example of the pattern: in August 2024, an Indonesian financial institution reported that attackers had obtained victims' government IDs through illicit channels, digitally manipulated the photos on them, and used the falsified images to bypass the institution's biometric identity-verification system during account opening — a real-world instance of exactly the injection-attack category the statistics above describe, not a hypothetical.

Three separate testing frameworks matter here, and they answer three different questions. OWASP's MASVS-AUTH control group, verified through the specific procedure in MASTG-TEST-0018, answers "did this specific app implement biometric authentication correctly" — checking that a biometric check actually gates a hardware-backed key rather than a bare boolean, among other things. It's the right framework for a penetration test or an internal code review of your own implementation.

ISO/IEC 30107-3:2023 answers a different question — "how good is this liveness-detection system at telling a live person apart from a spoof" — using two core error-rate metrics: how often a spoof (a photo, mask, or replay) fools the system, and how often a genuine, live user gets wrongly rejected as a spoof. Independent labs such as iBeta run conformance testing against the standard at defined levels, roughly: Level 1 and Level 2 require both error rates to stay under approximately 15%, and Level 3 tightens that to approximately 10%. This is the certification to ask for by name from any identity-verification vendor — a specific level, from a specific named lab, with a confirmation letter you can read yourself.

NIST's Face Recognition Vendor Test (FRVT)program answers a third question, relevant mainly to teams evaluating a specific face-matching algorithm rather than a full authentication flow: how accurately does a given vendor's matching algorithm perform against a large, standardized dataset, independent of any liveness claim. A vendor citing FRVT results is making a claim about matching accuracy; a vendor citing ISO/IEC 30107-3 conformance is making a claim about spoof resistance. They are not substitutes for each other, and a serious identity-verification integration should ask about both separately.

The United States has no single federal biometric privacy statute; exposure is a patchwork of state and municipal law, and it is worth being precise about what each one actually reaches rather than treating "biometric law" as one undifferentiated risk.

Illinois's BIPA remains the most litigated of these by a wide margin, and its 2024 amendment is worth understanding precisely rather than as a headline. Before the amendment, the Illinois Supreme Court's 2023 decision in Cothron v. White Castle Systems held that each separate scan of the same biometric identifier from the same person could count as its own violation — a reading that turned routine repeat authentication (a worker clocking in with a fingerprint scanner every shift, for instance) into potentially enormous aggregate statutory damages. Public Act 103-0769, signed August 2, 2024, amended BIPA so that multiple collections of the same identifier from the same person by the same method constitute a single violation, capped to one recovery per person. The Seventh Circuit held in Clay v. Union Pacific Railroad Co. (decided April 1, 2026) that this amendment applies retroactively, because it changes only the damages remedy, not the underlying substantive duty to obtain consent — that duty, and the exposure for skipping it entirely, is untouched.

Texas's CUBI is enforceable only by the state Attorney General, with no private right of action, yet it has produced the two largest biometric-privacy settlements on record: $1.4 billion from Meta in July 2024 over the Tag Suggestions feature's unconsented facial-geometry capture, and roughly $1.375 billion from Google in 2025 covering biometric, geolocation, and search-privacy claims together. Both settlements are worth reading precisely for what they were about: server-side facial-recognition features built from photos users had already uploaded for an unrelated purpose, not on-device authentication like Face ID or BiometricPrompt. The lesson for a mobile team building its own app's login screen is different from the lesson for a team building a photo-tagging or "find your friends" feature that runs facial recognition against uploaded images — the second category is where CUBI and BIPA exposure actually concentrates.

New York City's Local Law 3 of 2021 is the one most often over-applied in internal compliance conversations: it covers only "commercial establishments" — places of entertainment, retail stores, and food and drink establishments using biometric identification technology on their physical premises — and does not, on its own text, reach a typical consumer mobile app with no connection to a physical retail or entertainment venue. If your app has a genuine tie to a physical commercial establishment (an in-store kiosk, a venue entry system), confirm applicability with counsel directly; otherwise, do not let this statute drive design decisions for a general-purpose app.

The FTC's 2021 settlement with photo-storage app Everalbum is worth knowing as the clearest federal-level example of what "did wrong" looks like in this space for an app, as opposed to a state statute: Everalbum enabled facial-recognition tagging by default for most users, with no way to turn it off, contradicting its own stated privacy promises — a deception theory under the FTC's general unfairness and deception authority, not a dedicated biometric statute. The remedy required express consent going forward and deletion of models trained on the improperly collected data.

Under GDPR Article 9, biometric data is a special category of personal data specifically when it is "processed for the purpose of uniquely identifying a natural person" — language worth reading carefully, because it means not every image of a face automatically triggers Article 9's heightened protections. A photo taken for an employee ID badge is not, by itself, special-category data; the same photo becomes special-category data the moment it is run through a recognition system for identification or verification purposes. Once that threshold is crossed, processing is presumptively prohibited unless a narrow Article 9(2) exception applies — explicit consent being the one most relevant to a consumer mobile app — layered on top of a separate, independently required Article 6 lawful basis.

The UK's Information Commissioner's Office, in its guidance on special category data, and EU regulators more broadly have been consistent on one specific point that matters for implementation: consent for biometric processing must be explicit and specific to that purpose — a general terms-of-service acceptance, or a bundled consent covering several unrelated processing activities at once, does not satisfy it. If your app's onboarding flow buries a biometric-processing consent inside a broader "I agree to the Terms" checkbox, that consent is very likely not valid under Article 9 regardless of what the checkbox text says.

It is also worth being precise about what does not directly govern a typical consumer mobile app: the European Data Protection Board's most developed formal guidance on facial recognition addresses its use by law enforcement, a different legal basis and a different risk calculus entirely from a commercial biometric-authentication feature. There is no dedicated, EDPB-adopted guideline specifically addressing commercial biometric device authentication as of this writing. That gap is not a safe harbor — Article 9's text still applies directly and has been enforced under it — but it does mean a general-purpose app should look to the statute's own text and to sector-neutral regulator guidance like the ICO's, rather than to law-enforcement-specific guidance that answers a different question.

As with the US patchwork, the practical distinction that should drive your actual design decisions is the same one: on-device authentication, where Apple or Google is the entity performing the biometric capture and comparison and your app receives only a downstream result, sits in a meaningfully different position than a feature where your own servers or a vendor you've integrated perform facial matching directly against biometric data your systems process. Confirm which category a given feature actually falls into with counsel before assuming either one is automatically low-risk.

The failure mode we see most often is not a missing feature — it's the steps below built out of order, with the fallback and the server-side verification treated as an afterthought instead of a prerequisite.

Consider a consumer fintech app that lets a user check their balance with a simple biometric unlock, but requires a second, explicit biometric confirmation before sending a wire transfer above $1,000 — a common "step-up authentication" pattern in fintech app development and one worth walking through as an illustrative scenario, not a claimed real client outcome.

On app open, a BIOMETRIC_WEAK-or-stronger check (Class 2 acceptable) unlocks a cached, low-sensitivity session — enough to view a balance, not enough to move money. That distinction matters: a Class 2 sensor on a budget Android device is a legitimate gate for "let this person glance at their balance," and treating it as equivalent security to a payment authorization would be the exact strength-tiering mistake this guide has warned against throughout. When the user initiates the $1,200 transfer, the app requests a second, explicit BIOMETRIC_STRONG check tied directly to a Keystore key generated specifically for transaction signing — not a re-use of the app-unlock check from a few minutes earlier, and not a cached "already authenticated" flag. A successful check produces a cryptographic signature over the specific transaction details (amount, recipient, timestamp), which the server verifies against the public key it has on file for that user's device before releasing the funds.

Worked arithmetic on what this buys: if the app instead trusted a bare client-side "authenticated: true" boolean for the transfer step — the single most common shortcut we flagged earlier — a compromised device or a modified app binary could potentially force that boolean without ever touching the Secure Enclave or Keystore at all, since the check would be happening entirely in application code the attacker already controls. Requiring a signature produced inside hardware the attacker cannot extract or forge closes exactly that gap, at the cost of one additional, well-justified biometric prompt on the highest-value action in the app — the transfer, not the balance check. That's the shape of a defensible step-up design: the friction scales with the value of the action, not with a blanket policy applied uniformly regardless of stakes.

One general principle underlies most of the row above: if your team, or a vendor you're evaluating, cannot clearly explain where the biometric sample goes, what hardware boundary the comparison happens inside, and what cryptographic artifact (if any) is produced by a successful check, that is a sign the implementation has not been designed against the actual threat model — regardless of how polished the prompt UI looks to a user.

Limitations of this guide, stated plainly.We were unable to directly retrieve the full body text of Apple's LocalAuthentication documentation pages through our research tooling due to a network restriction, and relied on Apple's documentation index, related Apple developer pages we could retrieve directly (Secure Enclave key protection, Keychain biometric access), and corroborating third-party technical write-ups instead — the API behavior described here is consistent across all of those sources, but if a specific method signature or edge case matters for your implementation, confirm it against Apple's live documentation before you ship. The deepfake-injection-attack figures in this guide (Group-IB, iProov) are vendor- and threat-intel-reported, not independently audited, and we've flagged that explicitly rather than presenting them as neutral statistics. NYC's Local Law 3 is included for completeness of the US legal landscape and, on its text, applies narrowly to physical commercial establishments — we deliberately did not extend its reach to general mobile apps, and neither should you without counsel confirming your specific fact pattern. And nothing in this guide is legal advice: BIPA, CUBI, CCPA/CPRA, and GDPR all turn on the specifics of your data flow, and a qualified attorney reviewing your actual implementation is the only substitute for that.

If you're deciding whether to build this in-house against the native APIs described above or bring in outside help, the same logic from custom mobile app development generally applies: device-level biometric authentication is a solved, well-documented problem worth building directly against LocalAuthentication and BiometricPrompt yourselves; identity verification against an external document is a specialized problem worth buying from a vendor with a named, checkable ISO/IEC 30107-3 conformance level.