Face ID isn't a liveness check: behavioral signals as companion

The marketing line is “biometrics + behavioral as defense in depth.” The engineering reality is more specific than that: Face ID and behavioral signals answer different questions, and the answer matters when threat-modeling.

Face ID asks: “Does this face match the enrolled template, to a confidence interval Apple has tuned for a False Accept Rate around 1 in 1,000,000?”

BehaviorGuard’s behavioral signals ask: “Does the way this device is currently being used match the way the enrolled user has used this device historically?”

These are different questions. The Face ID question is about the face in front of the sensor; the behavioral question is about the person behind the input. When the face matches and the behavior matches, you have high confidence the right person is driving. When the face matches and the behavior doesn’t, you have a specific class of threat, a verified-face user whose hands aren’t theirs, or whose attention isn’t on the device. That’s the gap behavioral signals close.

Threat models where Face ID alone isn’t enough

Four scenarios where Face ID returns success but the user isn’t the actor you think:

1. Coerced unlock

User is forced (gun to head, intimate-partner violence, kidnapping) to face the device. Face ID succeeds. The attacker now has 30 seconds (the default sleep-to-lock window) to act. The Face ID signal is true; the behavioral signal, input cadence, hand size on the touch surface, the way they hold the device, is the attacker’s, not the enrolled user’s.

2. Sleeping or unconscious user

Spouse / partner / nurse / EMT / arresting officer holds the device up to a sleeping or unconscious user’s face. Apple added “attention awareness” for Face ID (the user must have eyes open looking at the phone), but multiple researchers in 2023-2025 demonstrated that printed glasses with reflective patches defeat attention awareness in adversarial conditions. Even when attention awareness works, the user is unwilling, the face is real, the consent is not.

3. Twin / sibling attack

Identical twins fool Face ID more often than the population. Apple’s published FAR is roughly 1 in 1,000,000 for random pairs, but Apple itself warns that the probability of a false match is materially higher for identical twins and siblings who look like you (and for children under 13). The behavioral signature, typing rhythm, scroll velocity, the muscle memory of how each twin actually uses their own phone, is the differentiator.

4. Shoulder-surfed Face ID

Attacker observes the user unlock with Face ID, then grabs the phone (or borrows it under social pretext) and uses it while the screen is still in the unlocked-by-face-ID grace period. The face is correct; the hands are not. This is the Coerced unlock threat we explored in the BehaviorGuard introduction post, same threat surface, different attack mechanic.

What “liveness” means and what it doesn’t

Apple’s “attention awareness” is a consciousness signal, eyes open, gaze toward the screen. It is not, in any technical sense, a “are-they-the-right-person-driving” signal. It catches cases (3) above (sleeping user) reasonably well; it does not catch (1), (2.b), or (4).

What you actually want, as an app developer building for these threat models: a layered system where:

• Biometric is the entry gate. Face ID says “the right face is here.”
• Behavioral is the session-quality signal. BehaviorGuard says “the current input pattern matches the enrolled user.” The attacker cases this layer is built to catch are enumerated in the BehaviorGuard threat model.
• Step-up is the response when either signal is uncertain. The user re-authenticates with a stronger primitive (biometric + passcode, or out-of-band confirmation via a paired device).

The composition order matters. Behavioral signals are weak alone, input cadence, touch pressure, and 6 motion features can be mimicked over a short window by an attacker who has observed the user. They’re strong as a consistency check on top of an established biometric anchor: if Face ID just succeeded but the touch pressure histogram doesn’t match the enrolled user’s, that’s a signal that something is wrong even though the biometric was correct.

What BehaviorGuard adds, technically

BehaviorGuard’s contribution is not a competing identity primitive. It’s a continuous-evaluation layer that:

1. Collects 10 behavioral signals during normal app use (touch · typing · scroll · 6 motion features).
2. Maintains an enrolled baseline per signal per user.
3. Scores live input against the baseline using a two-member ensemble (a diagonal distance detector, plus Core ML).
4. Combines the scores into a 4-band risk score with hysteretic transitions (see step-up auth when risk rises).
5. Surfaces band transitions to the app’s policy layer, which decides whether to step-up auth or degrade permissions.

The integration with Face ID happens at the policy layer. A common configuration:

import BehaviorGuardSDK
import LocalAuthentication

// At session start: Face ID gates entry, then BehaviorGuard begins monitoring.
let context = LAContext()
context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics,
                      localizedReason: "Unlock") { success, _ in
    guard success else { return }
    Task {
        let behaviorGuard = try await BehaviorGuard.start(
            apiKey: apiKey,
            environment: .production
        )
        try await behaviorGuard.start()
        observe(behaviorGuard)
    }
}

// Throughout the session: BehaviorGuard observes and emits risk-level changes.
func observe(_ behaviorGuard: BehaviorGuard) {
    Task {
        for await event in behaviorGuard.events() {
            guard case .riskLevelChanged(_, let level) = event else { continue }
            switch level {
            case .suspicious:
                // Soft step-up, degrade permissions but don't lock.
                Application.shared.setPermissionLevel(.readOnly)
            case .critical:
                // Hard step-up, re-auth required.
                Application.shared.requireBiometricReauth(
                    reason: "Unusual usage pattern detected, please confirm it's you."
                )
                // If biometric fails or is dismissed, log out.
            case .nominal, .elevated:
                Application.shared.setPermissionLevel(.full)
            }
        }
    }
}

The Face ID success at session start sets the biometric anchor, BehaviorGuard knows “this session started with a verified biometric.” If the behavioral score later transitions to .critical, BehaviorGuard’s recommendation is to re-bind to a fresh biometric, not just to re-auth with passcode. The combination of “the right face plus the right behavior” is the verified state. Behavioral score alone doesn’t unlock; biometric alone doesn’t sustain.

What this catches that Face ID alone doesn’t

Sentinel Den is pre-revenue, so there is no production telemetry to cite. The shape of the problem is well understood from the threat models, though: here is an illustrative breakdown of the kinds of .critical band transitions this layer is designed to catch. The weightings are illustrative, not measured field data:

Trigger category	Illustrative share (not measured)
Verified-Face-ID-then-handed-to-someone-else	38%
Account-takeover replay (stolen credentials)	19%
User-on-the-move-in-poor-conditions (false positive)	22%
Twin / family member (false positive in family-shared device context)	6%
Coerced unlock under duress	4%
Other / unclassified	11%

The largest category, “verified-Face-ID-then-handed-to-someone-else”, is the one Face ID alone fundamentally cannot catch: the biometric was correct at start of session, and the person who started the session handed the unlocked device to someone else. BehaviorGuard’s behavioral observation is what would catch the actor change mid-session.

The “user on the move in poor conditions” category is the operational cost of the layer: step-ups that would interrupt legitimate users. The hysteretic transitions described in the risk transitions post are what keep that false-positive cost down; further reduction requires more nuanced context (location, motion, time-of-day) which BehaviorGuard’s ContextProvider protocol allows the app to feed in through Components(contextProviders:).

The compliance story

For HIPAA, PCI-DSS, FFIEC, and the EU’s eIDAS, the audit standard is “the right person, at the right time, for the right action.” Biometric alone is a one-time check; the audit standard is continuous. Behavioral signals are the continuous-evaluation layer that turns a session-start biometric into a continuous identity signal, probabilistic, not a guarantee. (This is engineering guidance, not legal advice; whether a given control satisfies a regulation is a determination for your auditor.)

The audit chain (BehaviorGuard’s AuditLog, entries typed as AuditLogEntry) records every band transition, every step-up request, every re-bind. The auditor can reconstruct: “user X started a session at 14:32 with Face ID, behavioral score remained safe until 14:47, transitioned to medium at 14:51, step-up requested at 14:52, biometric re-auth succeeded at 14:52:08, session continued until 15:18 logout.” That’s a defensible audit trail for the compliance reviewer.

What BehaviorGuard explicitly is not

It is not a biometric replacement. The 10 behavioral signals it collects do not constitute biometric data under GDPR’s Article 9 (sensitive biometric data) because they are behavioral patterns, not identifiers of physical / physiological features. BehaviorGuard intentionally avoids collecting voice, face, or fingerprint data, those belong to the device’s biometric subsystem.

It is also not a one-shot identity primitive. Behavioral baselines need 5-7 sessions to stabilize (see PSI drift detection for the operational details). During the enrollment period, the policy should default to “trust the biometric, observe the behavior, don’t yet enforce.”

The composition is what makes it useful: Face ID for the entry gate, BehaviorGuard for the session-quality signal, step-up for the response when either layer reports uncertainty. Three independent properties, each calibrated for what it’s actually good at, that’s the engineering shape of layered defense.

See /sdk/behaviorguard for the marketing summary, /docs/behaviorguard for the configuration reference, and the companion posts on continuous authentication, ten behavioral signals, PSI drift detection, and step-up auth on risk.