Biometric authentication is now the default way most people unlock their phone. Face ID, Touch ID, fingerprint sensors on Android — combined, these systems authenticate billions of unlocks every day.
A common concern follows naturally: your face and fingerprint are stored somewhere. Who has access to them? Can Apple or Google read your biometric data? What happens if there’s a breach? The answers are more nuanced than most coverage suggests — and they differ significantly depending on which device you’re using and which apps have been granted biometric access.
How iPhone Biometrics Work
Apple’s approach to biometric data is built around a component called the Secure Enclave — a dedicated security chip physically isolated from the main processor and operating system of the iPhone.
Touch ID
When you enroll your fingerprint for Touch ID, the sensor captures a mathematical representation of your fingerprint — not a photographic image. This representation, called a fingerprint template, is encrypted and stored inside the Secure Enclave. It never leaves the Secure Enclave. It is not sent to Apple’s servers. It is not backed up to iCloud. It is not accessible to the iOS operating system or to any app, including Apple’s own.
When you place your finger on the sensor to authenticate, the sensor reads your fingerprint and sends the data directly to the Secure Enclave, which compares it against the stored template. The authentication result — match or no match — is returned to the system. The raw fingerprint data never leaves the secure chip.
Face ID
Face ID follows the same architectural principle. When you enroll your face, the TrueDepth camera system captures a detailed 3D depth map of your face. This data is processed by the Secure Enclave into a mathematical representation and stored there, encrypted. The 3D depth map itself is discarded after enrollment. The stored template, like Touch ID’s fingerprint data, never leaves the Secure Enclave and is not accessible to Apple or to any app.
When you authenticate, Face ID captures a new 3D depth map, processes it in the Secure Enclave, and compares it to the stored representation — all inside the secure chip, without the data touching the operating system or the network.
The Secure Enclave has its own separate boot process and firmware, separate from iOS. Even if an attacker fully compromised the iOS operating system, they could not directly extract biometric data from the Secure Enclave.
How Android Biometrics Work
The picture on Android is considerably more varied, because Android runs on hardware from hundreds of different manufacturers.
The Trusted Execution Environment (TEE)
Android’s equivalent architecture to Apple’s Secure Enclave is the Trusted Execution Environment — a secure area of the main processor or a separate security chip, depending on the device. Biometric templates are supposed to be stored in the TEE, encrypted, and inaccessible to the Android operating system.
Google’s Android Compatibility Definition Document requires that fingerprint templates meet specific security requirements: they must be stored in a location inaccessible to other apps, encrypted with a hardware-bound key, and deleted when a user is removed from the device. These are requirements — enforcement varies by manufacturer and device tier.
The Manufacturer Variation Problem
On high-end devices from Samsung, Google, and major manufacturers with dedicated security chips, biometric data security is broadly comparable to Apple’s implementation. On lower-cost devices from smaller manufacturers, the secure storage architecture may be less robust.
A 2023 study found that 40% of Android phones tested could be unlocked with a printed photo. This reflects not a compromise of stored biometric data but poor implementation of the matching algorithm on the device’s camera. The stored template isn’t stolen — the recognition system is simply fooled. That’s a distinct problem from biometric data exfiltration, but it illustrates the implementation variance across Android hardware.
Google and biometric data
Google does not receive your fingerprint or face data through biometric authentication. The Android framework explicitly prevents apps and services, including Google’s own, from accessing raw biometric data. What Google does receive is standard analytics data from your device through the Google Play Services layer — usage patterns, app activity, crash reports. This is extensive, but it does not include biometric templates.
What Third-Party Apps Can Access
When an app asks for biometric authentication — to log in to your bank, to authorize a payment, to unlock a password manager — what actually happens?
The app does not receive your biometric data. What happens is:
- The app calls a system API (iOS’s LocalAuthentication or Android’s BiometricPrompt).
- The operating system presents the biometric authentication interface.
- The biometric check happens in the secure area (Secure Enclave or TEE), entirely outside the app’s access.
- The result — authenticated or not authenticated — is returned to the app, along with a cryptographic signature that proves the authentication came from the device’s secure hardware.
The app never sees your fingerprint or face data. It receives a boolean plus a proof of device-level authentication. This design is intentional: even a malicious app granted biometric permission cannot steal your biometric template.
Where It Gets Complicated
Apps that store their own biometric data
Some apps build their own biometric authentication systems rather than using the operating system’s APIs. Older banking apps, some enterprise apps, and some international apps have in the past captured and processed fingerprint or facial data independently.
Where an app does this — storing its own biometric template rather than delegating to the OS — the security properties change entirely. The template may be stored on the app’s servers. It may be transmitted over the network. It is subject to that app’s security practices rather than the device’s secure hardware architecture.
This pattern is increasingly rare on iOS and Android because the OS-level APIs are both convenient and more secure. But it’s worth verifying: if an app asks for camera access to “scan your face” for identity verification rather than simply requesting a standard biometric permission, it may be capturing your image independently.
Legal compellability
In many jurisdictions, law enforcement can compel you to unlock your device biometrically — with your face or fingerprint — under lower legal thresholds than compelling you to provide a passcode. A passcode is testimonial and may be protected by the Fifth Amendment in the US; a fingerprint or face is physical evidence and has been treated differently in court.
This legal distinction is well-established in the US and some other jurisdictions. The on-device security of biometric data is not the only thing that matters — the legal compellability of biometric authentication is also relevant to some security models.
You can’t change your biometrics
Unlike passwords, you can’t issue yourself a new fingerprint or face. You have ten fingers and one face. If biometric template data were ever successfully exfiltrated — despite the architectural protections described above — the compromise would be permanent in a way that a compromised password is not.
This is a standard argument for why biometric data requires particularly strong protection architecture. Apple’s Secure Enclave implementation and Google’s TEE requirements are responses to exactly this concern.
Biometric Privacy Laws
Illinois’s Biometric Information Privacy Act (BIPA) was the first major biometric data law in the US, and it remains the most consequential. It requires informed written consent before collecting biometric data and prohibits selling biometric data. Several lawsuits under BIPA have resulted in large settlements — including a $650 million Facebook settlement over facial recognition tagging in photos.
Several other US states have passed biometric privacy laws, with more enacting them each year. The EU’s GDPR classifies biometric data as “special category” data requiring explicit consent and prohibiting certain uses without that consent. India’s DPDP Act similarly restricts biometric data processing.
This regulatory environment covers apps that collect biometric data directly — primarily those that build their own systems rather than using OS-level APIs. The Secure Enclave and TEE architecture described above is generally outside the scope of these laws because biometric data never leaves the device.
Biometrics vs. Passwords: A Practical Comparison
A common concern is that biometrics are less secure than passwords because biometrics can be copied from physical evidence (a high-resolution photo for face recognition, a fingerprint from a glass). This concern is technically valid but conflates two different things.
Biometrics in modern phones aren’t compared against photos or lifted prints. Face ID uses a 3D depth map, not a 2D image — a photograph held up to an iPhone cannot authenticate. Fingerprint sensors on quality hardware use capacitive or ultrasonic sensing, not optical imaging, and are resistant to printed fingerprints.
The realistic attack surface for your biometric data isn’t someone spoofing your face or fingerprint to unlock your phone. It’s the apps running on your phone after you’ve unlocked it — the permissions they hold, the data they access, and the servers they transmit to. Biometric authentication is the gate. What’s on the other side of the gate is a separate question.
Practical Assessment
For the biometric authentication you use every day — unlocking your phone with Face ID or a fingerprint — the data is protected in ways that are technically meaningful. Apple’s Secure Enclave implementation has been examined by security researchers and holds up to scrutiny. The Android TEE implementation on quality hardware is comparably strong.
The risks worth watching are:
- Apps that capture biometric data independently rather than through OS APIs — rare, but worth verifying when you see camera-based face scanning for identity rather than a standard biometric permission prompt.
- Legal compellability in your jurisdiction, if your threat model includes law enforcement access to your device.
- Credential reuse — the most common path to account compromise is still stolen passwords reused across services, not compromised biometric data.
The thing your phone does when you unlock it in the morning is, at the data-architecture level, better-designed than most people assume. The things done with your data by the apps running on that unlocked phone are often a different story.