Biometrics: on-device vs in the cloud

Two systems can both say "we verify your fingerprint" and be profoundly different. In one, your fingerprint is read by a sensor, matched inside a secure chip on your device, and the only thing that ever leaves is a signed "matched" message. In the other, an image of your fingerprint is uploaded to a server, matched against a database of stored templates, and retained. Same sentence in the marketing; opposite risk profiles in reality.

The difference matters because biometrics break the most basic rule of credentials: they cannot be changed. A password caught in a breach is rotated; your face and fingerprints are yours for life. Any architecture that accumulates biometric material is accumulating unrevocable risk — so the central design question is not accuracy, but where the biometric lives and travels.

Modern phones contain a separated secure environment — Apple's Secure Enclave, Android's hardware-backed Keystore and equivalents — that the main operating system cannot read into. When biometric capture happens "on device" in the strong sense, the sensor hands its reading to this environment; the template is created, stored and matched inside it; and applications receive only the verdict. Even a fully compromised operating system sees results, not biometrics.

Templates deserve a note of their own: a template is a mathematical summary derived from a biometric, not a photograph. Good systems store only templates, and treat even templates as sensitive — because "cannot easily be reversed into an image" is an engineering claim, not a law of nature, and the safe assumption is that leaked templates are harmful.

• It builds the honeypot: a server that matches biometrics must hold templates for everyone, in one place, indefinitely — the exact structure the honeypot analysis warns against.
• It moves data through more hands: every upload transits networks, load balancers, logs and backups, each a place where "we don't retain images" can quietly fail.
• It invites function creep: a database built for verification can be queried for search — matching one template against everyone — which is a surveillance capability, not a security one.
• It centralises compulsion: whoever can compel the operator inherits the database. On-device biometrics give a compelled party nothing to hand over.

The wallet capture app keeps the biometric pipeline at the edge. Fingerprint and iris capture at higher verification levels happens through the platform's secure hardware APIs; liveness processing runs during capture on the phone; and everything that leaves the device is encrypted before transmission using envelope encryption (X25519-XSalsa20-Poly1305), with device integrity attested via Play Integrity or App Attest.

The network's role is verification and record-keeping, not browsing: encrypted payloads are held in a vault the chain references but cannot read, verification produces signed results, and services receive outcomes — never templates, never images. The commitments are structural and published: biometric data is never sold or traded regardless of consent, never shared raw with services, never stored unencrypted on-chain, and always optional.

On-device processing has real limits. It depends on device hardware quality, which varies; it makes cross-device recovery more involved, since templates do not follow you to a new phone — you re-verify on new hardware instead; and fraud systems lose the (genuinely useful, genuinely dangerous) ability to search across enrolments. The wallet accepts these costs deliberately: the alternative capabilities are exactly the ones that turn a verification system into a surveillance system.

When you evaluate any identity product — including this one — ask where capture happens, where matching happens, what leaves the device, and what the operator could produce under compulsion. The answers separate systems that use biometrics from systems that collect them.