Assurance Tiers
Blerify evaluates every credential presentation against one of three assurance tiers — Basic, Standard, or Premium. This page explains what each tier proves, how the evidence is collected, and how platform differences affect what's achievable on Android versus iOS.
What the tiers are
Blerify's tiers are Blerify-specific definitions. They are not claims of formal equivalence with eIDAS levels or NIST Authenticator Assurance Levels, though the mapping to those frameworks is informative. The names Basic, Standard, and Premium were chosen deliberately to avoid implying certifications that consumer smartphones don't currently hold end-to-end.
Each tier represents what a verifier can independently confirm from the evidence included in the presentation — not what the wallet does internally. A third-party wallet may use hardware-backed key storage and enforce biometric authentication, but if it doesn't include the attestation evidence, the verifier has no way to confirm it. The tier reflects the provable guarantee, not the internal security posture.
The three tiers
Basic
Basic validates that the credential is cryptographically intact, currently valid, and was presented by the device that holds the bound key.
What Basic proves:
Credential not tampered
Issuer signature over the credential data
Credential not revoked
Revocation check against the trust registry
Session is fresh
Nonce binding — the response is tied to this specific request
Presenter holds the device key
Device authentication — the wallet signs a challenge with the credential's bound key
What Basic does not prove: whether the device key lives in tamper-resistant hardware, whether the device running the wallet is genuine, or whether the person presenting the credential is the person it was issued to.
Any wallet that implements OpenID4VP can achieve Basic. Third-party wallets that don't include Blerify's attestation extensions are classified as Basic regardless of their internal security architecture.
Typical use cases: low-risk credential checks, age verification, access control, third-party wallet integrations.
Standard
Standard builds on Basic by adding cryptographic proof that the credential's signing key was created inside tamper-resistant hardware — a Trusted Execution Environment (TEE) or StrongBox on Android, or the Secure Enclave on iOS — and by collecting a signed audit evidence package.
Additional properties Standard proves:
Key resides in tamper-resistant hardware
Key attestation included in the presentation; the verifier validates the certificate chain independently
Biometric authentication required to sign
Attested in the key attestation certificate chain (Android); self-reported by the wallet (iOS)
Key invalidated if new biometrics are enrolled
Attested in the key attestation certificate chain (Android); self-reported by the wallet (iOS)
Audit trail with session correlation
signed_evidence JWT signed by Blerify, containing IPs, geolocation, device metadata, and all evidence fields
On Android, key attestation is a hardware-signed X.509 certificate chain. The chain records where the key lives (TRUSTED_ENVIRONMENT or STRONG_BOX), whether biometric authentication is required to use it (auth_timeout_seconds: 0 means biometrics are required on every signing operation with no reuse window), whether the key is destroyed if new biometrics are enrolled on the device (invalidated_on_enrollment_change: true), and which authentication types are accepted. This chain is generated at key-creation time by the hardware and is static — the key's location and access controls can't change after the key is created.
On iOS, the equivalent is an Apple App Attest attestation. App Attest proves that a genuine, unmodified instance of the registered wallet app on real Apple hardware possesses the signing key. It does not cryptographically prove Secure Enclave residency or biometric binding the same way Android's certificate chain does — those properties are self-reported by the wallet. See Platform Attestation for the full comparison.
Standard also includes a telemetry package automatically assembled by Blerify: the wallet's IP address captured when it submits attestation data, the verifier's session IP if provided when initiating the session, an IP correlation flag, server-side geolocation of both IPs with a country-match flag, device model and OS version, and a document render — an image of the credential with only the disclosed fields legible and everything else blurred, for audit and manual review. All of this travels in signed_evidence, a JWT signed by Blerify that any third party can verify against Blerify's public key.
None of this adds friction for the user. The wallet submits attestation data on a background channel; Blerify captures IPs and geolocation automatically; the signed JWT is emitted when the session completes. The user sees the same consent screen and biometric prompt as in Basic.
Standard is only achievable with a Blerify wallet that implements the attestation extensions.
Typical use cases: identity verification, KYC, account opening, standard banking operations, government service integrations.
Premium
Premium builds on Standard by adding device integrity verification and server-side biometric verification. It answers a question the lower tiers cannot: is the person presenting this credential the same person the credential was issued to?
Additional properties Premium proves:
Device and app are genuine
Device attestation (Play Integrity on Android)
Presenter is the credential subject
Server-side liveness — anti-spoofing analysis plus face comparison against the portrait embedded in the credential
Anti-spoofing
Passive and active attack detection: photo, video replay, deepfake, 3D mask
The liveness check runs on Blerify's infrastructure, not on the device. This produces independent evidence — the result comes from a party the verifier can audit, not from the user's own device. It also means server-side anti-spoofing catches sophisticated attacks that on-device checks miss.
The liveness data is processed and immediately deleted. Blerify retains only the boolean result and a match confidence score. No biometric templates are stored.
Premium also optionally provides an anti-coercion signal derived from the same camera frames captured during the liveness challenge. Gaze tracking and micro-expression analysis run silently alongside the liveness check, invisible to both the user and any potential coercer. If anomalies are detected, they're reported in the result — the flow is never interrupted and no error is shown to the user. Your backend decides how to act on the signal.
iOS and device attestation: iOS has no equivalent of Android's Play Integrity API for third-party apps. On iOS, device_attestation is always null with device_attestation_reason: "platform_not_available". This is a structural platform limitation, not a failure. The Premium delta on iOS comes entirely from the liveness layer, which works identically on both platforms.
Premium requires a Blerify wallet.
Typical use cases: high-value banking operations (loan applications, contract signing), legal proceedings, regulated processes that require independent identity re-proofing.
Choosing a tier
The right tier depends on the consequence of being wrong.
Use Basic when you need to confirm a credential is valid and the presenter holds it, and the downside of a false positive is limited. Any OpenID4VP wallet works.
Use Standard when you need confidence that the credential is bound to real hardware and authorized by its holder's biometric. Appropriate for KYC, account opening, and most government and financial service integrations. The additional evidence is collected transparently — no extra friction for the user.
Use Premium when you need to independently confirm the person physically present is the credential subject. Required for high-value operations where the cost of identity fraud is significant: loans, contract signing, legal proceedings. Adds a liveness step of a few seconds.
You can run different tiers for different operations within the same product. A bank might verify at Standard for standard transfers and require Premium for loan applications.
Decision shorthand. Ask what the consequence of being wrong is:
A teenager bypassing your age gate with an older sibling's credential → Basic is enough.
An attacker opens an account in a stolen identity's name → Standard raises the bar to needing physical access to the real person's phone and their biometrics.
An attacker signs a high-value contract as someone else → Premium adds liveness, making this essentially impossible without the real person physically present.
Evidence fields
The verification response includes an evidence object alongside the credential claims. Each field tells you what was checked and what was confirmed. For the full field-level schema and request/response examples, see the API reference.
Basic
timestamp
Blerify
Exact time the presentation was processed
Standard (includes Basic)
wallet_ip
Blerify
IP address of the wallet's connection to Blerify when submitting attestation data
client_reported_ip
Verifier
IP of the user's web session, reported by you when initiating the transaction
ip_match
Blerify
Whether wallet_ip and client_reported_ip match. A mismatch isn't necessarily suspicious (NAT, VPN, mobile carrier) but is a useful audit signal
geolocation
Blerify
Server-side IP geolocation for both IPs: country, region, and city per IP, plus a country-match flag. A risk signal, not location proof — defeatable with a VPN
device_model
Key attestation (Android) / wallet (iOS)
Device model. Attested by hardware on Android; self-reported on iOS
os_version
Key attestation (Android) / wallet (iOS)
OS version and patch level. Attested by hardware on Android; self-reported on iOS
device_metadata.attested
Blerify
true when device model and OS version come from the hardware-attested certificate chain; false on iOS
key_attestation
Wallet + Blerify
Whether the signing key resides in tamper-resistant hardware and how it's protected. See Key attestation fields
document_render
Wallet
Image of the credential rendered by the wallet with disclosed fields legible and all others blurred. Intended for audit and manual review
signed_evidence
Blerify
JWT signed by Blerify containing the full result and all evidence fields. Verifiable by any third party against Blerify's public key. Blerify does not retain this beyond the session TTL — you are the custodian
Premium (includes Basic and Standard)
device_attestation
Play Integrity (Android) / not available (iOS)
Device and app integrity. Confirms the device runs a genuine manufacturer image, has a locked bootloader, runs the legitimate app binary, and has recent security patches. Always null on iOS with device_attestation_reason: "platform_not_available"
liveness_verification
Blerify
Server-side liveness result: verified (boolean), match_confidence (0–1), spoof_detected (boolean)
coercion_check
Wallet + Blerify
Anti-coercion analysis from the liveness session: status (CLEAR, GAZE_ANOMALY, or EXPRESSION_ANOMALY), method ("facial"), alert (boolean convenience flag). Produced silently; never interrupts the flow
Key attestation fields
The key_attestation object and its key_biometric_binding sub-object describe the hardware-level key guarantees:
security_level
STRONG_BOX or TRUSTED_ENVIRONMENT, extracted from the hardware-signed certificate
SECURE_ENCLAVE, self-reported by the wallet
security_level_attested
true
false
key_biometric_binding.biometric_required
Attested — extracted from the key attestation certificate
Self-reported by the wallet
key_biometric_binding.auth_type
Attested — e.g. FINGERPRINT, FACE, or DEVICE_CREDENTIAL
Self-reported by the wallet
key_biometric_binding.auth_timeout_seconds
Attested — 0 means biometrics required on every operation, no reuse window
Self-reported by the wallet
key_biometric_binding.invalidated_on_enrollment_change
Attested — true means the key is destroyed if new biometrics are added to the device
Self-reported by the wallet
key_biometric_binding.attested
true
false (always)
The auth_type and biometric_required fields reflect the authentication factor bound to the key at creation time. On devices without a strong biometric enrolled, the key is bound to the device passcode or PIN — auth_type will be ["DEVICE_CREDENTIAL"] and biometric_required will be false. This is accurate, not a downgrade: the key is still in hardware and requires user authentication on every signing operation.
StrongBox versus TEE on Android
Android devices report either STRONG_BOX or TRUSTED_ENVIRONMENT as the security_level. Both are accepted at Standard and Premium.
A TEE (Trusted Execution Environment) is a hardware-isolated execution environment on the same processor, present on virtually all Android devices since 2016. A StrongBox is a dedicated tamper-resistant security processor with its own CPU and storage — present on many current flagships but not universally available on mid-range hardware. StrongBox offers stronger isolation guarantees than a TEE.
Both security levels appear in evidence.key_attestation.security_level so you can apply your own acceptance policy if a specific use case demands StrongBox. For most integrations, accepting both is the right default.
Absence reasons
When an optional evidence field is absent, a companion _reason field explains why. The reason field is always present — it's null when the evidence field itself is populated.
null
The evidence field is populated — no absence to explain
"platform_not_available"
The platform has no API for this capability (e.g., device_attestation on iOS)
"wallet_not_supported"
The wallet doesn't implement the Blerify extension
"not_requested"
The verifier didn't configure this tier or feature
"user_declined"
The user denied a required permission (e.g., camera for liveness)
"failed"
The check was attempted but rejected (e.g., spoof detected, integrity check failed)
"attestation_not_supported"
The device has a hardware key store but predates the Key Attestation API — the key is likely hardware-backed but this can't be cryptographically proven
The distinction between "platform_not_available" and "user_declined" matters for policy decisions. A user who refuses liveness is a different risk signal than a platform that structurally can't provide device attestation. Your verification policy can treat them differently.
Platform attestation asymmetry
Android and iOS provide fundamentally different attestation capabilities. They are not equivalent mechanisms with minor differences — the underlying architectures differ.
Key attestation
On Android, the key attestation certificate chain is generated by the hardware at key-creation time and signed by the TEE or StrongBox. Key properties including biometric requirements, authentication timeout, and invalidation behavior are all embedded in the signed certificate.
On iOS, there is no Apple API that produces an equivalent certificate for Secure Enclave keys in third-party apps. App Attest proves that a genuine, unmodified instance of the registered wallet app on real Apple hardware created and holds the key. Key properties like biometric binding are self-reported by the wallet. The key_biometric_binding.attested field is always false on iOS.
This does not mean iOS keys are less secure. The Secure Enclave enforces the access controls the wallet configured — including requiring Face ID or Touch ID for every signing operation and invalidating the key when biometric enrollment changes. The limitation is that these controls cannot be independently verified remotely. Apple has not provided a public API for this in third-party apps.
Device attestation
Android provides Play Integrity, which independently verifies that the device uses a certified manufacturer image, has a locked bootloader, runs the legitimate app binary, and has recent security patches applied.
iOS has no equivalent API for third-party apps. device_attestation is always null on iOS with _reason: "platform_not_available". This is a structural platform limitation, not a failure.
Summary by tier and platform
Credential valid
✅
✅
✅
✅
✅
Holder binding
✅
✅
✅
✅
✅
Key in hardware (attested)
—
✅
—
✅
—
Key in hardware (self-reported)
—
—
✅
—
✅
Biometric binding (attested)
—
✅
—
✅
—
Biometric binding (self-reported)
—
—
✅
—
✅
Audit telemetry + signed_evidence
—
✅
✅
✅
✅
Device integrity (Play Integrity)
—
—
—
✅
❌ not available
Liveness + face match
—
—
—
✅
✅
Recommended policy for iOS Standard
Accept Standard on iOS the same way you accept it on Android. An iOS device with security_level_attested: false and key_biometric_binding.attested: false is not a downgrade or a fraud signal — it reflects Apple's architectural choice not to expose an equivalent hardware attestation API to third-party developers. The Secure Enclave still enforces biometric requirements on every signing operation.
If your use case requires hardware-attested key properties regardless of platform, apply a platform-neutral control rather than treating these fields as a failure condition. For use cases where the absence of hardware attestation on iOS is unacceptable, Premium closes the gap — App Attest confirms the wallet app and device are genuine, and liveness independently re-proves the presenter's identity.
effective_tier versus assurance_level
Your verification configuration specifies an assurance_level — the tier you're requesting. The verification response also includes effective_tier — the tier the evidence actually supports.
effective_tier measures which classes of evidence arrived and were validated, not whether the content of that evidence is favorable. A Standard presentation can have effective_tier: "STANDARD" and still contain ip_match: false or geolocation.country_match: false. Those are content signals you evaluate against your own risk policy — they don't change the tier.
Common cases where effective_tier differs from assurance_level:
Requested
What arrived
effective_tier
BASIC
VP with valid signature
BASIC
STANDARD
VP + key attestation
STANDARD
STANDARD
VP with no attestation extensions (third-party wallet)
BASIC
PREMIUM
VP + all extensions + liveness confirmed
PREMIUM
PREMIUM
VP + all extensions, liveness failed
STANDARD
PREMIUM
VP + key attestation only (no liveness or device attestation)
STANDARD
PREMIUM
VP with no extensions (third-party wallet)
BASIC
Always check effective_tier when enforcing your risk policy.
Non-repudiation at Standard
Standard establishes a chain of evidence that makes it difficult for a credential holder to credibly deny having authorized a presentation. Each element addresses a specific argument:
"Someone copied my key"
The key resides in tamper-resistant hardware and cannot be extracted or duplicated. Key attestation proves this cryptographically
"Someone used my key without my consent"
Every signing operation requires the holder's biometric with no reuse window (auth_timeout_seconds: 0)
"Someone enrolled their biometrics on my device"
The key is automatically destroyed if new biometrics are added (invalidated_on_enrollment_change: true)
"The evidence was fabricated"
The signed_evidence JWT is signed by Blerify and verifiable by any third party against Blerify's public key — it cannot be altered without detection
On Android, each element in this chain is hardware-attested — the properties are signed by the TEE or StrongBox, not asserted by the wallet. On iOS, the properties are self-reported but corroborated at Premium by App Attest confirming the wallet app and device are genuine.
Zero biometric storage
Blerify's liveness model at Premium is structurally different from traditional identity verification services.
Traditional providers store a face image or a biometric embedding. They become custodians of biometric data subject to strict obligations under GDPR and equivalent laws. If their infrastructure is breached, biometric data is permanently exposed — unlike passwords, faces cannot be changed.
Blerify eliminates this risk by design. The credential issued by an authority already contains the holder's portrait, signed by the issuer. Blerify does not store a reference photo. When Premium verification runs, the selfie captured during liveness and the portrait extracted from the credential are compared and immediately deleted. The only artifact retained is the boolean result and a confidence score. Your backend never receives a face image, a template, or any biometric data.
For the full technical detail on how this works, see Biometric Binding.
Relationship to eIDAS and NIST
This section is informative. Blerify's tiers are not claims of formal regulatory equivalence.
Basic
~Low
~AAL1
Below SCA (single factor)
Standard
~Substantial
~AAL2
Satisfies SCA
Premium
Exceeds scope
Exceeds scope
Exceeds SCA
Standard and ~AAL2 / ~eIDAS Substantial. The device biometric that activates the hardware-bound signing key qualifies as multi-factor authentication under both frameworks — something you have (the device with the key in hardware) plus something you are (the biometric that activates it). The mapping is informative because consumer phones meet the security bar functionally but don't hold the end-device certifications required for a formal compliance claim.
Why Premium doesn't map to eIDAS High or NIST AAL3. Premium exceeds the authentication requirements of both — it adds server-side liveness and independent face matching, neither of which those frameworks mandate for authentication. However, both require hardware certifications at the highest tiers that consumer smartphones meet only partially at the end-device level. This is an industry-wide limitation for consumer phone-based wallets, not specific to Blerify.
Blerify uses its own tier names to avoid implying certifications that don't yet exist end-to-end for consumer devices.
Configuring tier requirements
You set the required assurance tier in your verification configuration in the Portal. When a presentation arrives, Blerify computes the effective_tier based on the evidence it can validate.
For the full evidence response schema, request parameters, and verification configuration details, see the API reference.
Next steps
Continue to Biometric Binding — how the credential's signing key is bound to the user's biometrics, what each tier guarantees about that binding, and where the limits are.
See also: Platform Attestation · Verify a Credential · API Reference
Last updated