Biometric Authentication and Hardware Enclave Security in Mobile Apps

How platform biometrics actually work

The application never sees biometric data. The operating system matches the fingerprint or face against templates held in the secure hardware and returns only a success or failure result, which is why the biometric cannot be extracted even from a compromised application.

The correct pattern is that biometric authentication unlocks a private key stored in hardware. The application requests a cryptographic signature, the operating system prompts for the biometric, and on success the hardware produces a signature the server can verify. The biometric is not transmitted or compared by the application at all.

This distinction matters because a common mistake is to receive a boolean result and then send a static credential to the server. That converts a hardware-backed guarantee into a client-side check that can be bypassed on a modified device.

• Use platform authentication only to unlock a hardware-backed key.
• Never transmit a biometric result as if it were a credential.
• Require a cryptographic signature that the server verifies.
• Understand that the OS reports only success or failure.

Generating and storing keys in hardware

Keys should be generated inside the secure element, secure enclave or hardware-backed keystore, with the private key marked non-exportable and requiring user authentication for use. The public key is registered with the server at device enrolment.

Attestation, where available, allows the server to verify that the key was generated in genuine hardware and to apply a policy based on the device model or security level. It is not available identically on every platform or device, so treat it as strengthening rather than as a universal control.

Invalidate keys when the device's biometric enrolment changes. Both major platforms support this, and it prevents an attacker who can add their own fingerprint to an unlocked device from gaining persistent access.

Binding to the session and handling fallback

A hardware-backed signature proves possession of a device key, not that the request should be authorised. The server must still validate the session, the device registration and the user's permissions, and it should bind the signature to the specific request or challenge so it cannot be replayed for a different operation.

Provide a fallback for users whose biometric fails or who have not enrolled one. Falling back to a device passcode is acceptable when the key remains hardware-protected and the server still enforces authorisation, but falling back to a weaker shared secret stored in the application is not.

Handle edge cases deliberately: biometric lockout after repeated failures, device passcode removal, application reinstallation and device transfer. Each should invalidate the enrolment and require re-authentication rather than silently degrading.

• Bind each signature to a server-issued challenge or request.
• Still enforce session, device and permission checks server-side.
• Fall back to device passcode, not to a weaker stored secret.
• Re-authenticate on enrolment change, reinstall or transfer.

The limits of biometric authentication

Biometrics do not encrypt data at rest on the device. Once an application has decrypted data into memory, biometrics offer no protection against a compromised runtime, a memory dump or a malicious accessibility service. Sensitive data should be decrypted only when needed, held briefly and cleared.

Biometrics are also not a substitute for server-side authorisation. A device can be rooted or jailbroken, the application can be repackaged, and a determined attacker with physical access and the enrolled biometric can authenticate legitimately.

Use biometrics as one control within a layered design: device attestation where available, certificate pinning, short-lived tokens, server-side permission checks and monitoring for anomalous device behaviour. No single control carries the whole burden.

• Do not treat biometrics as data encryption.
• Minimise the lifetime of decrypted sensitive data in memory.
• Layer biometrics with attestation, pinning and short-lived tokens.
• Monitor for anomalous device and authentication patterns.