> For the complete documentation index, see [llms.txt](https://docs.blerify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blerify.com/introduction-to-verification/learn/biometric-binding.md). # Biometric Binding Biometric binding is the chain of evidence connecting the person physically present during a verification to the person who was identity-proofed when the credential was issued. This page explains what Blerify verifies at each assurance tier, what secure hardware guarantees, where the limits are, and how server-side liveness closes the gap that hardware alone cannot close. *** ## What biometric binding means in practice When someone presents a digital credential, three questions matter: 1. **Is the credential authentic?** Was it issued by a trusted authority, is the cryptographic signature valid, and has it not been revoked? 2. **Does the presenter control the credential?** Is the private key bound to this credential on the device being used right now? 3. **Is the presenter the credential subject?** Is the person in front of you the same person the credential was issued to? {% hint style="info" %} A trusted authority — the credential's issuer — is the entity that identity-proofed the holder and signed the credential: typically a government agency, civil registry, or national ID authority. This is independent from the country where you, the verifier, operate — a bank in one country can accept a credential issued by an authority in another, as long as that issuer is on your trust list. {% endhint %} Basic verification answers question 1 and confirms question 2 via a holder binding proof. Standard adds hardware-attested evidence about how the private key is protected. Premium answers all three — including question 3 — through server-side liveness and face matching. *** ## How the device key works Every credential in the Blerify Wallet is bound to a private key stored in the phone's secure hardware: the Secure Enclave on iOS, StrongBox or a Trusted Execution Environment (TEE) on Android. The key never leaves that hardware. The wallet never holds it in software. The key is configured with two constraints at the moment of creation. **Authentication required on every use.** The key can only activate after the user authenticates with a biometric or device credential (PIN, pattern, or password). No app can trigger a signing operation silently in the background — every presentation requires an active unlock, with no caching window. **Invalidation on biometric enrollment change.** If someone registers a new biometric on the device after the key was created, the key is automatically destroyed. A person who adds their own fingerprint to a stolen phone cannot use the credential: the key is already gone, and the legitimate holder would need to go through full re-enrollment — including identity proofing — to get a new one. The wallet selects the authentication factor based on what the device supports. On devices with a strong biometric sensor enrolled, the key is biometric-gated and configured to invalidate if new biometrics are added. On devices without a strong biometric, the key falls back to the device credential, enforced at the hardware level. Either way, the signing key is always hardware-backed. The wallet refuses enrollment on any device that lacks hardware-backed secure storage or has no screen lock configured. When a wallet presents a credential, it performs a signing operation using this key. The resulting holder binding proof demonstrates two things: the presenter holds the specific device the credential was bound to at issuance, and they were able to unlock its secure hardware. *** ## What each assurance tier verifies ### Basic Blerify validates the credential's cryptographic signature, checks it against the issuer's revocation registry, verifies the issuer is on your configured trust list, and confirms the presenter completed a device authentication challenge proving they hold the credential's signing key. A passing Basic result tells you the credential is valid and the presenter controls a device key bound to it. It tells you nothing about how that key is stored or what is required to unlock it. Basic is also the effective tier for presentations from third-party wallets. Those wallets may internally operate at a higher security level, but without hardware-attested evidence in the presentation, that cannot be confirmed. The assurance Blerify reports reflects what the verifier can independently verify, not what the wallet may do internally. Basic is appropriate for operations where the cost of a wrong answer is low: age checks, access control, low-value identity lookups. ### Standard Standard extends Basic with key attestation. The wallet submits a certificate chain — signed by Google's or Apple's hardware root — alongside the presentation. Blerify validates that chain to confirm: * The signing key lives in tamper-resistant hardware (StrongBox, TEE, or Secure Enclave), not in software. * The key requires user authentication for every signing operation, with no caching window. * The key is configured to be destroyed if someone adds a new biometric to the device after issuance. This information appears in the `key_attestation` and `key_biometric_binding` fields of the verification result. On Android, these fields are signed directly by the TEE or StrongBox and are verifiable against Google's hardware attestation certificate roots — the wallet app cannot forge them. On iOS, Apple's attestation API confirms the app and device are genuine but does not carry the key's access-control flags, so `key_biometric_binding.attested` will be `false` in iOS results. The Secure Enclave still enforces the biometric requirement locally; it is simply not remotely attestable through Apple's current API. [Platform Attestation](/introduction-to-verification/learn/platform-attestation.md) covers these differences in detail. Standard also includes signed audit evidence: IP addresses observed at presentation time, approximate geolocation derived server-side, device model and OS version, and a `signed_evidence` JWT you can retain for your own compliance records. That JWT is signed by Blerify and verifiable by any third party against Blerify's public key — without contacting Blerify — using the JWKS endpoint described in the [API reference](https://dev.blerify.com). Standard does not prove that the person presenting is the credential subject. It proves that whoever holds the phone and can unlock its biometric sensor is presenting. That distinction matters for high-value operations. Standard is appropriate for account opening, KYC, routine banking, and government service access. ### Premium Premium adds server-side liveness verification on top of everything Standard provides. The wallet captures a short camera session during the presentation. Blerify runs that session through: * An anti-spoofing check that detects photos, videos, 3D masks, and deepfake imagery. * A face match against the portrait embedded in the credential — the photo the issuing authority placed in the credential at the time of issuance. A passing Premium result means the person in front of the camera was a live human whose face matches the credential portrait with high confidence. Combined with Standard's key attestation, this closes the gap Standard cannot address on its own: you have independent, server-produced evidence that the presenter is the credential subject. Premium also includes device attestation. On Android, Play Integrity provides explicit verdicts on whether the device has been rooted, the bootloader tampered with, or the app modified. On iOS, there is no equivalent API available to third-party apps — `device_attestation` will be `null` with `_reason: "platform_not_available"` in iOS Premium results. Liveness and face matching run identically on both platforms. The selfie captured for liveness is never stored. Blerify processes it for the comparison and deletes it immediately. Only the boolean result and a confidence score are retained in the verification record. Your backend never receives raw biometric data. Premium is appropriate for loan applications, high-value contracts, legal proceedings, and any operation where confirming physical presence justifies the additional step for the user. *** ## The biometric binding gap — and why it exists Standard tier proves the signing key is in hardware and configured to require biometric authentication. It does not prove that the biometrics enrolled on the device belong to the credential holder. If someone else's biometric was registered on the device before the credential was issued, that person can unlock the key. The invalidation-on-enrollment-change mechanism does not cover this case — it only catches biometrics added *after* key creation. This is not a Blerify-specific limitation. iOS and Android deliberately do not expose biometric template data to applications. There is no platform API that lets a wallet verify whose biometrics are enrolled on a device. Any wallet that delegates biometric authentication to the OS faces the same constraint — passkeys, mobile banking apps, and device login all share this design. For Basic and Standard, this gap is accepted as consistent with how device-based authentication works across the industry. For operations where physical presence matters, use Premium: server-side face matching against the credential portrait closes the gap at verification time, independent of what is enrolled on the device. *** ## Why server-side liveness rather than on-device face matching An on-device face match would add complexity without providing what Premium is designed to deliver: independent, auditable evidence from a server outside the holder's control. A result produced fully on the user's device — even on a certified device with hardware-attested code — is a statement from the holder's own equipment. When a transaction is disputed, evidence from the holder's phone carries less weight than evidence from an independent server. Financial institutions that use face matching for high-risk operations today — loan applications, new device enrollment, high-value contract signing — route users through a server-side verification step for exactly this reason. Server-side liveness also provides stronger anti-spoofing. On-device passive checks detect casual attacks: photo printouts, simple video replay. Server-side processing using 3D face mapping and temporal video analysis catches sophisticated attacks: deepfakes, 3D-printed masks, and high-fidelity video replay. Device attestation confirms the app is genuine and unmodified, but cannot confirm that what the camera sees is a real person. That confirmation requires server-side analysis. The combined result — device attestation confirming the environment, plus server-side liveness confirming physical presence — gives you independently auditable evidence that does not require sending biometric data to a centralized database. *** ## Zero biometric storage Blerify's liveness model is structurally different from traditional identity verification services. Traditional providers typically store a face image or a mathematical embedding of it. They become custodians of biometric data subject to strict obligations under GDPR and equivalent laws. If their infrastructure is breached, the biometric data of every user they have ever verified is exposed — and unlike passwords, faces cannot be changed. Blerify's model eliminates this risk by design. The credential issued by a government authority already contains the holder's portrait, signed by the issuer. Blerify does not store a reference photo. When Premium verification runs: 1. The portrait is extracted from the signed credential during validation. Because it travels inside the signed credential, any tampering would have invalidated the issuer's signature before this step. 2. The wallet captures a short liveness session and sends it to Blerify. 3. Blerify compares the session against the portrait and deletes both immediately after the comparison. 4. The only artifact retained is the boolean result and a confidence score. Your backend receives the result. It never receives a face image, a template, or any biometric data. Blerify never builds a face database. The practical consequence is that a breach of Blerify's verification infrastructure would expose boolean results ("credential verified at time Y with confidence 0.97") but zero biometric data — because there is none to find. *** ## What credentials need for Premium Premium requires a portrait field in the credential. Without it, Blerify has no reference image to match against and cannot perform liveness verification. **ISO 18013 mDoc credentials** always contain a `portrait` field in the standard namespace. This is a required element of the ISO 18013-5 specification. **W3C Credentials and SD-JWT credentials** may or may not include a photo, depending on the issuer. If the photo claim is selectively disclosed and the holder does not disclose it, liveness cannot proceed. When Premium is requested but the credential contains no usable portrait, Blerify caps the result at Standard and includes `"liveness_not_possible": "credential_has_no_photo_claim"` in the response. You decide in your own logic whether Standard is acceptable for that operation. Photo quality also matters. The face comparison engine needs the face to be recognizable at a reasonable resolution. The issuer controls portrait quality at issuance time — by the time a presentation reaches Blerify, whatever the issuer encoded is what the comparison runs against. Heavily compressed portraits, very small face regions, or images with significant glare or occlusion will reduce match confidence. *** ## Non-repudiation and audit evidence Standard tier produces a non-repudiation chain. If a holder later disputes having authorized an action, the hardware attestation evidence addresses each common argument: | Holder's argument | Why it doesn't hold | | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "Someone copied my key" | The key lives in tamper-resistant hardware and cannot be extracted by software. Key attestation proves this cryptographically. | | "Someone used my key without my consent" | Every signing operation requires hardware-enforced authentication with no reuse window. | | "Someone enrolled their biometric on my device" | If a new biometric was added after key creation, the key was automatically destroyed. The presentation could not have occurred. | | "The audit evidence was fabricated" | The `signed_evidence` JWT is signed by Blerify and independently verifiable against Blerify's public key by any auditor. It cannot be modified after issuance. | For Premium, the liveness record adds that the person physically present matched the credential portrait, strengthening the chain further for operations that require evidence of physical presence. Blerify signs the `signed_evidence` JWT but does not retain it after the session expires. You are the custodian of the audit record — store it according to your own retention requirements. *** ## Coercion detection Premium includes an additional signal: analysis of gaze patterns and facial micro-expressions captured during the liveness session. This runs silently alongside the face match — the user sees only the standard liveness challenge, and a potential coercer sees the same thing. If the analysis flags an anomaly — sustained gaze toward a fixed off-camera point, or involuntary stress expressions — the `coercion_check` field in the verification result will carry a non-clear status. The verification flow is never interrupted on a coercion signal. Blerify reports the signal; you decide how to respond based on your own risk policies. Interrupting the flow on a coercion detection would reveal to the coercer that a signal was triggered, potentially escalating the danger. Coercion detection is Premium-only. The platform biometric APIs on both iOS and Android deliberately do not expose which biometric template was matched. This makes a duress-finger signal impossible to implement at the Standard tier. The camera-based liveness session at Premium enables gaze and expression analysis that the Standard flow structurally cannot support. *** ## Regulatory context Blerify's tier names — Basic, Standard, Premium — are Blerify-specific definitions. They are not formal certifications of eIDAS or NIST equivalence. **Basic** is below eIDAS Substantial and NIST AAL2. It establishes single-factor possession of the credential's signing key with no attestation of how that key is protected. **Standard** aligns informally with eIDAS Substantial and NIST AAL2: two factors from different categories (possession and inherence), with the signing key in tamper-resistant hardware. Individual hardware security components in consumer phones often hold relevant security certifications, but no consumer end-device currently holds the certifications required by a strict reading of eIDAS High or NIST AAL3 at the whole-device level. This is an industry-wide constraint for mobile wallet deployments, not specific to Blerify. **Premium** exceeds what eIDAS, NIST, PSD2, or banking regulators in most jurisdictions require for per-transaction authentication. Server-side liveness and face matching are controls designed for operations where identity re-proofing at a specific friction point is warranted — account opening, loan applications, high-risk device enrollment. Neither eIDAS nor NIST requires that biometrics enrolled on a device belong to the credential holder. Both frameworks assume the device owner enrolled their own biometrics. The EU Digital Identity Wallet Architecture Reference Framework (EUDIW ARF) goes further and requires that biometric enrollment be linked to identity proofing. Blerify's roadmap is aligned with this direction. For the detailed informative mapping between Blerify tiers and eIDAS/NIST levels — including the specific certification gaps that prevent formal equivalence — see [Assurance Tiers](/introduction-to-verification/learn/assurance-tiers.md). *** ## Next steps **Continue to** [**Platform Attestation**](/introduction-to-verification/learn/platform-attestation.md) — how Android and iOS produce different evidence shapes in the verification result, and how to write a risk policy that accounts for the iOS attestation asymmetry. See also: [Assurance Tiers](/introduction-to-verification/learn/assurance-tiers.md) · [Read a Verification Result](/introduction-to-verification/build/read-a-verification-result.md) · [API Reference](https://dev.blerify.com) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.blerify.com/introduction-to-verification/learn/biometric-binding.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.