Probabilistic recognition
Biometric recognition compares measured biological or behavioral characteristics with a reference. Examples include face, fingerprint, iris, voice, gait, and typing behavior. Measurements vary, so a matcher uses a threshold and produces false matches and false non-matches rather than exact equality.
A biometric characteristic is not a secret. It can be observed, copied, injured, changed, or impossible to replace.
Roles and measures
Separate sensor, sample, feature extraction, reference template, matcher, threshold, presentation-attack detection, authenticator, verifier, and relying party. Measure false-match rate, false-non-match rate, failure to acquire, demographic performance, spoof resistance, environment, and retry behavior for the deployed population.
The operating point changes security and availability. A stricter threshold can reduce false acceptance and increase lockout and fallback use.
Safe use in authentication
Use the biometric to activate a physical authenticator or other bounded local mechanism when the assurance profile permits it. Protect sensor-to-matcher integrity, templates, retry limits, fallback, and deletion. Require clear user intent for each operation. Provide a non-biometric alternative.
Avoid central storage when a local comparison can meet the requirement. Treat biometric data as sensitive personal data and limit collection, purpose, access, retention, and sharing.
Failure and residual risk
Photos, recordings, masks, latent prints, replay, sensor injection, template theft, coercion, and look-alike errors can attack the system. Presentation-attack detection adds assurance and can fail. A fallback PIN, support reset, or device recovery can be weaker than the biometric path.
Biometrics can create exclusion, accessibility, surveillance, linkability, and irreversible breach harm. A match does not prove intent, current control of an account, or authorization for an action.
Pomerium boundary
Pomerium can rely on an identity provider or WebAuthn authenticator result. It does not receive or match the raw biometric in a normal WebAuthn flow. The platform authenticator and provider own sensor, local activation, retry, template, presentation-attack, and fallback behavior. Pomerium still authorizes the route, not the biometric characteristic.
Evaluation checklist
- Which sensor, template, matcher, threshold, retry, presentation-attack, and fallback mechanisms form the system?
- What false-match, false-non-match, acquisition, demographic, and environmental results apply to the deployed population?
- Is the biometric a local authenticator activation factor or a centrally reusable identity record?
- Can spoofing, sensor injection, coercion, template theft, fallback, or support bypass the intended assurance?
- Are purpose, consent, alternative access, retention, deletion, linkability, and breach response explicit?
