Face ID does not use a conventional RGB camera for authentication. The TrueDepth module, housed in the notch or Dynamic Island cutout, is a structured-light depth sensor. It consists of six hardware components that work in concert every time authentication is triggered.
Projects 30,000 invisible infrared dots onto the face in a known pattern using a diffractive optical element (DOE).
Captures the dot pattern as deformed by facial geometry. Dot displacement encodes depth via structured-light triangulation.
Emits IR light for ambient compensation. Enables operation in low-light and near-darkness without visible flash.
Standard CMOS sensor. Not used for biometric matching — used for 2D context (attention detection framing).
Triggers the TrueDepth pipeline on face approach. Prevents unnecessary IR emission cycles.
Adjusts flood illuminator intensity. Provides consistent IR exposure across lighting conditions.
The IR wavelength used (~940 nm) is invisible to the human eye and operates safely at close range under FDA Class 1 laser product limits. The dot projector is technically a VCSEL (vertical-cavity surface-emitting laser) array, not an LED — precision that matters for depth accuracy.
Structured light works by projecting a known pattern and measuring how it deforms when it hits a surface. Because the geometry of the projector and receiver is fixed and calibrated at manufacturing time, any displacement in the captured dot positions can be converted directly to a distance measurement.
| Dot density | ~30,000 IR dots across the face region |
| Depth resolution | Sub-millimeter at 25–50 cm working distance |
| Capture rate | ~30 fps (ambient map) with burst capture for auth |
| Output | Depth map (Z-buffer) + IR intensity image |
| Liveness signal | Disparity consistency across multiple frames; checks for flat/planar surfaces |
The resulting depth map is a per-pixel distance value — essentially a 3D point cloud of the face. This is what gets fed to the neural matching stage. It is not an image in the conventional sense; a printed photo cannot replicate it because it has no surface variation.
Liveness detection: The system runs anti-spoofing checks on the structured-light data. Flat scenes (photos, screens) produce anomalous depth histograms. Silicon masks are harder but still distinguishable via micro-texture analysis and frame-to-frame motion correlation. Apple hasn't publicly detailed the exact liveness algorithm, but False Accept Rate specs imply multi-factor geometric + temporal checks.
Apple uses a dedicated neural network pipeline — executed on the Neural Engine inside the SoC (A11 Bionic and later) — to convert raw sensor data into a compact mathematical representation of the face, then compare it against the stored template.
Depth map and IR image are normalized, aligned, and segmented. Background, hair, and occluded regions are masked. Face pose is estimated and canonical-frame aligned.
A convolutional network produces a high-dimensional embedding vector from the depth and IR channels. The model was trained on diverse datasets including glasses, hats, facial hair, and aging effects. Exact architecture is not public.
The embedding is compared against the enrolled template (also a stored embedding vector) using a distance metric — likely cosine similarity or L2. A match threshold determines accept/reject.
Separately, the system verifies gaze direction and open eyes using the RGB front camera. This "require attention" check is an additional classifier, not part of the depth-matching network. Disableable in Accessibility settings.
On successful auth near the acceptance threshold, the stored template is updated with a weighted blend of the new embedding. This is how Face ID adapts to gradual appearance changes (beard growth, glasses, aging). Updates are gated — failed attempts don't trigger updates.
| False Accept Rate | 1 in 1,000,000 (Apple spec, single enrolled face) |
| False Reject Rate | Not publicly specified; Apple cites "exceptional performance" |
| With twin/sibling | FAR increases; Apple advises passcode fallback |
| Touch ID comparison | Touch ID FAR: 1 in 50,000 |
| Inference location | Neural Engine (A11+). Never sent off-device. |
The face template and all cryptographic material for Face ID live exclusively in the Secure Enclave — a dedicated security coprocessor within Apple silicon. It has its own boot ROM, AES engine, TRNG, and PKA. The main application processor cannot read its memory directly.
Separate OS: The Secure Enclave runs its own microkernel (sepOS). It is isolated from the main CPU's memory space via hardware memory protection. Even a full iOS kernel compromise does not grant access to Secure Enclave memory.
Unique ID (UID): Each device has a 256-bit AES UID burned in at manufacturing — unknown to Apple, not stored anywhere off-chip. All Face ID data is encrypted with keys derived from this UID.
Template storage: The enrolled face embedding vector is encrypted and stored inside the Secure Enclave's protected storage area. It never leaves the enclave in plaintext. It is not synced to iCloud, not accessible to apps, and not readable by iOS itself.
Biometric result signaling: When a match occurs, the Secure Enclave does not expose the template or the embedding. It signals a boolean authentication result to the Secure Key Store, which can then release a cryptographic key to the requesting app or iOS subsystem.
Apps do not receive face data. They request a key via the Local Authentication framework. The Secure Enclave is the only entity that can grant or deny that key release. The flow is:
App calls LAContext.evaluatePolicy() → iOS presents authentication UI → TrueDepth captures → Neural Engine evaluates → Secure Enclave either releases the requested key or returns an error code.
What an app receives is a keychain item or a signed assertion — not anything biometric.
Enrollment collects multiple depth maps across two rotational scans of the face. The system intentionally samples edge cases (tilted, turned, partially occluded) to build a robust initial template.
User moves head in a circle. System samples depth maps at multiple pose angles. Approximately 15–20 distinct captures across the first rotation.
A second rotation pass extends edge-case coverage — captures slightly more extreme angles to improve peripheral-view matching.
All captured embeddings are aggregated into a single enrollment template — likely a cluster centroid or multi-vector representation. Stored encrypted in Secure Enclave.
A second face can be enrolled via Settings → Face ID & Passcode → Set Up an Alternate Appearance. This stores a second template in the enclave, not a merge of both. iOS supports exactly two enrolled faces.
Legal note: In the US, biometric authentication (including Face ID) may be compellable by court order, whereas a memorized passcode has stronger Fifth Amendment protections. Users with elevated threat models should understand this distinction and know how to quickly trigger passcode-only mode (five button presses on iPhone 8+, or Side + Volume buttons).
These clarifications address common misconceptions:
| Cloud sync | Face templates are never uploaded to Apple servers or iCloud. They are bound to the device UID and cannot be decrypted elsewhere. |
| App access to face data | Apps have zero access to raw depth maps, IR images, or embedding vectors. They receive only a cryptographic key release or a denial. |
| Identifier sharing | Face ID does not generate a face hash usable across apps. Authentication results are isolated per app via the Secure Key Store. |
| Passive surveillance | Face ID only activates on explicit trigger (proximity sensor + raise gesture or tap). The TrueDepth system does not run continuously in the background. |
| Age / identity data | The model produces a similarity score against the enrolled template. It does not classify, label, or store demographic information. |
Face ID is a pipeline of four discrete systems: a structured-light depth sensor (TrueDepth), a neural embedding model running on the Neural Engine, a cryptographic key-release mechanism in the Secure Enclave, and a behavioral lockout policy enforced by iOS. Each layer is independent — hardware determines liveness, software determines identity similarity, hardware enforces key custody, software enforces usage policy. No single layer's compromise is sufficient to bypass the full chain.