Systems About 2 min read

Biometric access control systems

Biometric systems compare a sample with a stored reference. Record the match threshold, operating conditions, uncertainty and recovery process used by the application.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Architecture and assurance only; no biometric capture/template, threshold recommendation, identity claim, or product accuracy claim.

Verification and testing

Overview#

Biometric matching is probabilistic. A result depends on sensor, sample quality, algorithm/version, threshold, population, environment, presentation attack controls, and workflow. A biometric characteristic isn't secret and is difficult to replace after compromise.

Lifecycle and roles#

text
notice/authority -> identity proof -> supervised enrollment/capture
 -> quality check/template creation -> protected storage/binding
 -> presentation + liveness/PAD -> comparison -> policy decision
 -> adjudication/fallback -> update/revoke/delete/audit

Distinguish 1:1 verification (claim then comparison) from 1:N identification/search. Their error rates, privacy, scale, and authorisation consequences differ.

Metrics and thresholds#

Evaluate false match/non match, failure to acquire/enrol, transaction time, quality rejection, presentation attack outcomes, and operator fallback at the deployed threshold and population. Report confidence/score according to the product contract; scores from different algorithms/versions aren't directly comparable.

ISO/IEC 19795 is the multi part biometric performance testing/reporting family in the ISO catalogue. NIST's ongoing/official biometric evaluations and FRVT demographic effects report show why performance must be disaggregated across relevant demographics and conditions. A lab result isn't site validation.

Template/data protection#

  • Prefer matching/storage architectures that minimize centralized raw biometric data and use cancelable/protected templates where supported.
  • Encrypt in transit/at rest, isolate keys, restrict enrolment/export/admin, and audit every access/change.
  • Don't store raw captures or templates in generic PACS logs, SIEM, analytics, ordinary backups, tickets, or documentation repositories.
  • Define retention, deletion (including replicas/backups/device caches), portability/non reuse, breach response, and subject rights.
  • Prevent cross purpose correlation through scoped opaque subject/template IDs.

Legal consent/authority, workplace fairness, accessibility, children/vulnerable people, surveillance law, and biometric specific regulation vary sharply by jurisdiction.

Device and PACS boundary#

ONVIF Profile D's public access control peripheral scope includes biometric readers. Verify where matching occurs, what traverses reader controller/network links, template format/lock in, reader/controller identity, secure channel, offline cache, and revocation.

The PACS should receive the minimum result needed, with provenance/quality, not unrestricted templates. A match is one authentication signal; authorisation still applies schedules, areas, antipassback, risk, and account state.

Fallback and safety#

Design accessible, non discriminatory fallback and manual adjudication. Attackers often target fallback/recovery rather than the biometric algorithm. Rate limit and review repeated failures without locking people into unsafe areas. Required egress/emergency behaviour must not depend on successful biometrics.

Change control#

Model, firmware, sensor, threshold, camera/illumination, population, mask/PPE, enrolment process, or environment change requires re evaluation. Preserve versioned score/decision evidence without retaining excessive biometric data.

Return to Access control systems.