Let me be honest about what we actually know, because the launch coverage won’t. Preorders opened, demand was “extraordinary,” deliveries slipped to late January, and Verizon wants ten dollars a month for a handoff feature. That’s it. That’s the confirmed record. Nobody has published a spec sheet for Apple’s foldable, Apple hasn’t said a word about its biometrics, and the loud claim bouncing around — Touch ID on the power button, no Face ID — is a rumor wearing a confident voice. I can’t source it. Neither can anyone selling you a hot take on it.
So I treated it as a drill, not a fact. If the leaks are right and Apple ships a flagship with Touch ID instead of Face ID, what in my stack quietly assumes otherwise? The only way to answer that is to break the assumption on purpose and watch. I spent a week pretending an iPad Air and an iPhone SE in the drawer were the foldable — Touch ID only, Face ID off — and the findings had nothing to do with hardware I can’t buy yet. They were about the lazy shortcuts we baked in over five years of Face ID being the default on every phone that mattered.
First, the part that would be a non-story even if the rumor holds: the Secure Enclave doesn’t care. Touch ID and Face ID both enroll templates that never leave the SEP, and the matching happens inside the enclave regardless of sensor. A power-button capacitive sensor talking to that same enclave has shipped on the SE and the iPad line for years. There is no new security story in a modality swap. If your threat model trusted Face ID’s enclave, it trusts this one.
Day one, the app audit. This is where it bit. We had code — written by someone long gone — that treated LABiometryType.faceID as a proxy for “modern device, do the fancy flow.” On the SE it reported .touchID and the UI drew a Face ID glyph with the confidence of a man reading yesterday’s weather. The fix is dull and you already know it: never branch on a specific modality. Call canEvaluatePolicy first, then read biometryType, and adapt to whatever it tells you.
The passkey question, settled fast. I re-enrolled a WebAuthn credential through ASAuthorizationPlatformPublicKeyCredentialProvider under Touch ID. The ceremony is identical. The relying party gets the same UV flag set, the same attestation path, the same enclave-bound key. Touch ID is just the user-verification gesture in front of the credential; it changes nothing the server can see or should care about. If anyone’s passkey backend special-cases Face ID devices, that’s a bug regardless of what the foldable ships.
The MDM part everyone will get wrong. The restriction that governs biometric unlock is still named allowFingerprintForUnlock — a key that predates Face ID and silently started governing Face ID too. There was never a “Face ID required” MDM control; that was always a policy fiction built in a UEM console on top of passcode rules. So no new payload is needed for a Touch ID flagship. What’s needed is for you to stop pretending the toggle means what its name says.
Audit your fleet now, so you’re not finding out in January:
Here’s what I’d tell anyone tempted to run the same drill. You don’t need the rumor to be true for this to be worth your afternoon. Whether the foldable ships Touch ID, Face ID, or something Apple hasn’t named yet, a fleet that hard-codes one modality is already broken — it just hasn’t met the device that proves it. Grep your codebase for faceID. Grep your policy docs for “Face ID required” and find out what that sentence actually compiles to in your MDM. Do it on a rumor in October. In January, when the spec is finally real, you’ll be reading tickets instead of fielding them.