What the hardware actually provides
Secure Enclave is a separate hardware component that performs key operations and supports device authentication, with key material that does not leave the chip. It is a genuine security primitive and a good thing for a vault to use.
It is a component, not a design. It protects specific keys under specific policies chosen by the app — and every consequential decision about which keys those are remains the application's.
What the app still decides
The hardware does not encrypt your photo library. An application chooses the key hierarchy, the access-control policy on each key, how bulk content is encrypted, what happens to metadata, and how migration and recovery work.
A vault can invoke Secure Enclave correctly and still leave thumbnails cached in plaintext, or have no recovery path, or hold the content key in memory long after the session ended.
Biometric gating is not file encryption
The most common conflation is treating a Face ID prompt as evidence that files are encrypted. Biometric authentication authorises an operation; it does not describe how the data is stored.
Ask the two questions separately: what gates access to the app, and what protects the files if someone bypasses the app entirely.
Hardware-bound keys do not travel
A key that never leaves the chip cannot be moved to a new phone. That is the security property working as intended, and it is also why device migration needs its own deliberate mechanism.
Understand what happens after a passcode change, a device restore from backup, and hardware replacement. If the answer is that access is lost without a portable backup, that is normal — and it means the backup is not optional.
Questions worth asking
- Which keys are hardware-bound and which are portable?
- Is biometric gating separate from the file encryption design?
- What happens after a passcode change, a restore, or a new device?
- How does recovery work when the hardware-bound key is gone?
Claims to discount
- Using “Secure Enclave” as a complete security proof rather than one component.
- Assuming hardware-bound keys transfer to a new phone with the app.
- Treating a biometric prompt as evidence about storage encryption.
A fictional example
Noah starts with a non-sensitive test: “Separate biometric gating from file encryption.” Next, Noah follows the second check: “Ask which keys are hardware-bound and which are portable.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Using 'Secure Enclave' as a complete security proof
- Assuming hardware-bound keys transfer to a new phone
What this workflow does not change
- Using 'Secure Enclave' as a complete security proof
- Assuming hardware-bound keys transfer to a new phone
Questions people ask
Is Secure Enclave the same as Keychain?
No. They interact in Apple security architecture but are distinct concepts and services.