Notifications
Clear all
Topic starter
01/08/2026 8:59 pm
TL;DR: Online identity checks combine document extraction, document authenticity testing, selfie matching, liveness detection and fraud intelligence to decide whether a person is genuine, according to Yoti. The real governance issue is not whether any single check works, but whether the assurance model is resilient enough to stop spoofing, deepfakes and reused identity data.
NHIMG editorial — based on content published by Yoti: How does an identity check work?
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should organisations use identity verification results in access decisions?
A: They should treat verification as an input to risk-based access decisions, not as a permanent entitlement.
Q: Why do identity checks need liveness detection as well as face matching?
A: Face matching compares two images, but it does not prove that a live person is present during capture.
Q: How do security teams know if continuous identity verification is working?
A: Look for a reduction in fraud that progresses beyond first-touch checks, plus faster escalation of risk scores when behaviour changes.
Practitioner guidance
- Tighten document quality gates Reject blurred, cropped or low-light document images before OCR and authenticity checks, and log capture failures so teams can spot recurring user or device issues.
- Require layered assurance for higher-risk journeys Combine document validity, face matching, liveness detection and fraud intelligence when the transaction or account action carries elevated risk, and define where manual review overrides automation.
- Separate identity proofing from entitlement decisions Do not treat successful verification as lasting access approval.
What's in the full article
Yoti's full explainer covers the operational detail this post intentionally leaves for the source:
- Step-by-step walkthrough of document extraction, including how OCR and validity checks are applied to supported IDs
- More detail on liveness detection and injection attack detection for deepfake and replay resistance
- Explanation of how trained verification specialists and Super Recognisers are used for edge cases
- Additional context on encryption and secure storage for personal data in identity checks
👉 Read Yoti's explainer on how online identity checks work →
Identity verification checks: where trust is built, and where it fails?
Explore further
01/08/2026 9:06 pm
Identity verification fails when organisations treat biometric confirmation as proof of entitlement. A matched selfie only says the person resembles the document holder, not that the document was obtained legitimately or that the session is free from spoofing. The deeper governance issue is verification scope, because many programmes stop at identity proofing and never link it to downstream access lifecycle controls. For IAM and IDV teams, the verification result must be treated as one signal in a broader trust model, not as a permanent statement of who someone is.
A question worth separating out:
Q: Who is accountable when identity verification data is reused downstream?
A: The application owner remains accountable for how verification output is consumed, even when an SDK or external provider performs the checks. If verified data is reused for onboarding, access decisions, or pre-filled forms, the organisation must still govern retention, scope, and auditability. Shared tooling does not transfer accountability.
👉 Read our full editorial: Online identity checks rely on layered verification, not a selfie alone
