On-device identification
On-device identification runs the entire recognition pipeline locally on the device — recognition works offline and biometric data never leaves the device. It supports face, palm, iris, and fingerprint via the on-device SDKs.
How it works
The device runs the whole pipeline locally, composing the Enrollment, Identification (1:N), and Verification (1:1) features — see those pages for the pipeline detail.
It is the recognition engine behind several scenarios that differ only in the trigger and the action after a match, not in the pipeline:
- Access control — grant or deny entry at a door, turnstile, or gate.
- Time & attendance — identify at a clock-in/out terminal and log identity + timestamp.
- Visitor / kiosk self-service — self check-in at an unattended kiosk (include passive liveness).
Because the flow is shared, scenario differences live in your application (trigger, UX, what happens on a grant) — not in the SDK calls.
Components & modalities
Choose a modality — or combine several — by capture ergonomics, available hardware, and assurance needs. Each modality is implemented by its on-device SDK, embedded natively in your application and running the full recognition pipeline locally.
| Modality | SDK | Passive liveness | Auto-capture |
|---|---|---|---|
| Face | SFE Toolkit | ✓ | ✓ |
| Palm | SFE Toolkit | ✓ | ✓ |
| Iris | SFE Toolkit | — | — |
| Fingerprint | IDKit / Enrollment SDK | — | — |
For the full modality × SDK × platform / accelerator matrix, see Supported Platforms and Supported Hardware Accelerators. For how each pipeline step maps to an SDK capability, see the feature pages: Identification (1:N), Verification (1:1), Liveness, and Enrollment.
Scenario tuning & constraints
Patterns and constraints specific to designing a physical access point (SDK-neutral). For capability detail, see the feature pages.
- Apply a spatial trigger before running recognition. From the per-frame detections, pick only the subject(s) that meet the access-trigger criteria — typically closest to frame centre, large enough (subject size as a fraction of frame), and inside a defined trigger-zone rectangle. Don't run the pipeline on every detection: in most access framings, most detections are passersby, not people presenting for access.
- Match the liveness operating point to the access form factor. Choose the passive-liveness configuration for your framing (distant kiosk/turnstile vs close-range handheld). See Liveness.
- Camera-side concerns are the integrator's responsibility. Exposure control, IR illumination, anti-glare, multi-camera framing, and motion handling are outside the SDK, which only consumes a decoded frame.
Getting started
Get the SDK for your modality and follow its getting-started; then implement the Enrollment, Identification, and Verification flows, using the per-step capability mapping on each feature page.
- Face / palm / iris — use the SFE Toolkit: get the package, set up licensing, and pick a build for your target — see Supported Platforms and Supported Hardware Accelerators.
- Fingerprint — use IDKit (matching) and the Enrollment SDK (capture / enrollment).
Demo & examples
Each SDK ships runnable examples that cover this use case end to end. For face / palm, see the SFE Toolkit — Example application (and the API Reference); for fingerprint, see IDKit and the Enrollment SDK.
Related pages
- Identification (1:N), Verification (1:1), and Enrollment (the flows this use case implements)
- Server-side identification (the server-based alternative)
- Embedded Biometrics — Solution Overview
- Embedded Biometrics — High Level Overview (SDKs comparison, platforms, accelerators)
- License Agreement
SDK documentation:
- SFE Toolkit — face & palm (Features, Solvers & Platforms, Licensing)
- IDKit — fingerprint
- Enrollment SDK — fingerprint capture & enrollment