Identity Verification for Assessments

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why This Matters

If you issue a certificate, a license, a degree credit, or a hiring decision based on an online test, the value of that credential depends entirely on one fact being true: the right person took the test. Identity verification is the control that protects that fact, and getting it wrong fails in two expensive directions at once — a weak check lets impersonators through and devalues every credential you issue, while a heavy biometric check rejects legitimate people, collects regulated data, and has already produced multi-million-dollar privacy settlements in education. This article is written for the product manager, L&D director, or founder building a credentialing or assessment product, not for a biometrics engineer, though the engineering is accurate underneath. We have built identity, video, and assessment features for regulated products across e-learning and other verticals, and by the end you will be able to choose an assurance level, scope the subsystem, and name the privacy and fairness questions before you sign a vendor.

Identity Verification Is Not Proctoring

Start by separating two jobs that vendors sell together and beginners blur. Identity verification answers "who is this?" — it confirms, usually at the start of a session and sometimes throughout, that the test-taker is the enrolled person. Proctoring answers "what did they do?" — it monitors behaviour during the test for signs of cheating. They use overlapping hardware (the webcam) but they are distinct controls with distinct data and distinct risks, and proctoring gets its own article.

The plain analogy is the exam hall. Identity verification is the person at the door checking your ID card against your face before you are allowed in. Proctoring is the invigilator walking the aisles once you are seated. You can do one without the other: a low-stakes practice quiz needs neither, a take-home certification might verify identity strongly but not watch behaviour, and a high-stakes licensing exam does both. This article is only about the door check.

One more boundary. Identity verification for an assessment is also not the same as the everyday login to your learning platform. Logging in proves someone holds the account password; it does not prove a human face matches a government ID. The account login is part of your platform's general authentication layer (single sign-on, the standard that lets one login work across systems, called SSO). Assessment-grade identity is the stronger, exam-specific check layered on top — and it is the only kind this article covers.

The Methods, Weakest to Strongest

Almost every verification product combines a few of five building blocks. Knowing them in order tells you exactly how much assurance you are buying and what each block costs in privacy.

The first and weakest is knowledge-based verification (KBV) — asking something only the real person should know, such as a security question or a detail pulled from a public record. It is cheap and collects no biometric data, but it is weak: the U.S. National Institute of Standards and Technology (NIST), in its Digital Identity Guidelines (Special Publication 800-63-4, finalized 31 July 2025), removed knowledge-based authentication as an acceptable standalone method and permits knowledge-based verification only as a limited part of identity proofing, never sufficient on its own — because the answers are too easy for an attacker to find or guess.

The second is the ID-document check. The test-taker photographs a government ID — a passport, driver's license, or national ID card — and software checks that the document is genuine (security features, fonts, structure) and not a forgery or a screen-photo of one. This proves the document is real; it does not yet prove the document belongs to the person holding it.

The third closes that gap: the face match, technically a one-to-one (1:1) biometric comparison. The software measures the geometry of the face on the ID photo and the geometry of a live selfie and asks "are these the same person?", returning a similarity score. One-to-one matching ("is this face the same as that one face?") is far more accurate than one-to-many search ("which of a million faces is this?"), and assessment identity is almost always the easier 1:1 problem. The moment you compute that facial geometry, though, you are processing biometric data — and the law changes, as the next section explains.

The fourth is liveness detection, also called presentation-attack detection (PAD). A face match alone can be fooled by holding up a printed photo, replaying a video, or wearing a 3D mask. Liveness detection proves the face in front of the camera is a live human being presenting themselves in real time. The international standard for testing it is ISO/IEC 30107 — Part 1 (published 2016) defines the framework, and Part 3 defines how to measure a system's resistance to spoofs, with independent labs running thousands of attack attempts using photos, replays, silicone masks, and AI deepfakes. When a vendor says "ISO/IEC 30107-3 Level 2 certified," that is the claim to look for.

The fifth and strongest is continuous identity — re-confirming the same person throughout the session rather than only at the door. The system periodically re-checks the live face against the verified reference so that a different person cannot swap in after the initial check. This is the proctoring-grade identity control, and it is the most invasive: it means the camera is doing biometric processing for the whole exam, not just at the start.

Figure 1. The five building blocks, ordered from weakest to strongest. Moving right raises assurance but also raises the privacy and accessibility cost — biometric processing begins at the face-match step and intensifies through liveness and continuous identity.

How a Face-Match Verification Actually Works

Because face matching plus liveness is the core of almost every assessment-identity product, it is worth opening the box. The flow is short and each stage maps to a specific risk it defends against.

The test-taker first photographs their ID and takes a selfie. A document-authentication stage checks the ID is genuine. A face-detection stage finds and aligns the face in both images. The one-to-one match stage compares the two faces and returns a similarity score — a number, not a verdict. A liveness stage confirms the selfie is a live capture, not a photo, replay, or injected deepfake stream. A scoring layer combines the document result, the match score, and the liveness result into a pass / refer / fail outcome. And the critical last stage — the one teams under deadline pressure skip — is human review of anything that does not cleanly pass.

Figure 2. The face-match-plus-liveness pipeline. Each stage defends a specific attack: document authentication stops forged IDs, the 1:1 match ties the ID to the person, liveness stops photos and deepfakes, and human review stops a wrong score from becoming a wrong decision.

Two precise points matter, because popular write-ups get them wrong. First, a low match score is not proof of fraud. Faces change with age, lighting, glasses, weight, hairstyle, and camera quality; an honest person can score below threshold. The score opens a review; it does not close a case. Second, the threshold is a business decision, not a technical default. Set it strict and you reject more honest people (a higher false-rejection rate); set it loose and you admit more impostors (a higher false-acceptance rate). You are choosing where on that trade-off your credential should sit, and you should choose it deliberately.

A Worked Example: Where the Threshold Bites

Numbers make the trade-off concrete. Imagine a certification body verifying 20,000 candidates a month with a face match. Suppose the engine, at your chosen threshold, has a false-rejection rate (FRR) of 3% — three in a hundred genuine people wrongly told "you don't match your ID."

False rejections per month: 20,000 × 3% = 600 candidates

Six hundred honest candidates a month hit a wall at the door. If each needs a 5-minute human re-check to clear, that is:

600 re-checks × 5 min = 3,000 min = 50 staff-hours / month

Now tighten the threshold to cut impostors and the FRR climbs to 6%; the monthly wrongly-rejected count doubles to 1,200 and the review load doubles to 100 staff-hours. Loosen it to 1% and you save the labour but admit more impostors. There is no setting that is free — the only question is which error you can least afford for this credential, and whether your support team is staffed for the rejections the strict setting creates. The cheapest-looking "fully automated" verification quietly re-introduces human labour the moment you make it fair.

The Privacy Cost Is Specific — and Regulated

Here is the part vendors gloss over. The instant you compute facial geometry to match a face to an ID, you are processing biometric data, and several laws treat that as a distinct, high-risk class. The methods that collect no biometrics (knowledge checks, document authenticity) carry far less legal weight; the face-match and liveness steps carry the most. Walk the specifics.

Illinois biometric law (BIPA). The Illinois Biometric Information Privacy Act (740 ILCS 14) treats a faceprint — a measurement of facial geometry — as protected biometric data you may not collect without informed, written consent, and it gives individuals a private right to sue. This is not theoretical for education: Pearson agreed to an $18.2 million class-action settlement over biometric data including facial and palm scans at test centers and online proctoring, and Respondus settled a related student-face-scan case for $6.25 million. If any test-taker is in Illinois (or another state with a biometric statute), this law is live for you, not just your vendor.

Special-category data under GDPR. For test-takers in the European Union or United Kingdom, the General Data Protection Regulation (Regulation (EU) 2016/679) classifies biometric data processed to uniquely identify a person as "special category" data under Article 9 — the most protected tier. You need both a lawful basis under Article 6 and a specific Article 9 condition, usually the test-taker's explicit consent, and consent is legally fragile when the alternative is failing the exam. You also need a written data-processing agreement with the verification vendor under Article 28, with retention limited to what the purpose requires. The cleanest engineering answer is to delete the biometric template the moment verification is complete.

Student records under FERPA. In the United States, the Family Educational Rights and Privacy Act (20 U.S.C. § 1232g; 34 CFR Part 99) governs how an institution discloses education records — including verification images tied to a student — to third parties such as a verification vendor. The vendor usually has to fit the "school official" exception: under the institution's control and barred from re-using the data.

Assurance frameworks worth knowing. Two public frameworks tell you how much rigour a given assurance level demands. NIST SP 800-63-4 defines Identity Assurance Levels (IAL1 to IAL3) and, notably, now requires presentation-attack detection and deepfake-signature analysis for remote IAL2 proofing — a direct response to the deepfake threat below. In the EU, the eIDAS Regulation defines assurance levels of low, substantial, and high, where "substantial" expects stronger remote proofing including biometrics. You do not have to comply with these to run an exam, but they are the reference points a serious buyer or auditor will use.

The New Threat: Deepfakes and Injection Attacks

Identity verification used to defend mostly against a person holding up a photo. The 2025 threat is different and it changes the engineering. Synthetic faces are now cheap and convincing — fraudsters can generate a passable AI face for under $20, and the visual artifacts that betrayed 2022-era fakes are largely gone from 2025-era diffusion-model output. Worse than holding a fake to the camera is the injection attack: feeding a deepfake video stream directly into the verification app through a virtual camera, bypassing the lens entirely. One security firm recorded over 8,000 biometric-injection attempts against a single financial institution's liveness checks in 2025.

The defense is not "better photo inspection." It is, per the threats: validate the capture source (is this a real camera or a virtual one?), analyze multiple frames over time rather than one still, and read passive physical signals such as 3D depth that a flat injected stream cannot fake. This is also exactly why NIST SP 800-63-4 now mandates deepfake-signature analysis for remote proofing. The face-recognition and synthesis internals belong to a different field — for the model side, see the AI for Video Engineering section; this article covers the assessment wiring and the product decision.

Figure 3. The attack surface and its defenses. Presentation attacks (photo, replay, mask) are caught by liveness detection tested to ISO/IEC 30107-3; injection attacks bypass the camera and need capture-source validation and multi-frame passive signals.

Fairness and Accessibility: the Failure Mode That Sues You

Face recognition does not perform equally across people, and an assessment that depends on it inherits that inequality. NIST's Face Recognition Vendor Test (the long-running benchmark, FRVT) has measured this for years. Its demographic study found that false-positive (false-match) rates vary by orders of magnitude across groups — among top systems the false-match rate for West Africans averaged roughly 23 times that of Eastern Europeans, and the very top system as of early 2025 produced hundreds of times more false positives for older West African women than for the best-served group. False rejection — telling a genuine person they don't match — also skews by skin tone, lighting, and camera quality. A verification system that cannot reliably see a darker-skinned candidate in a dimly lit room is not a neutral tool; it is a barrier.

The harm is not limited to skin tone. The candidate with a facial difference or a disfigurement, the person whose appearance changed since their ID photo, the candidate using assistive technology, and the candidate on a cheap webcam in a shared space all fail the match more often. Where verification must not disadvantage a disabled learner, accessibility law and the WCAG 2.1 AA expectations of the rest of your platform pull against blunt biometric gating. The minimum fairness bar is concrete: a failed match never auto-fails the candidate, a human reviews every rejection with context, and there is a documented, fast appeal route and an alternative verification path for people the camera fails.

Common mistake: treating the verification score as a verdict and auto-rejecting anyone below threshold. It punishes the demographic groups the technology serves worst, it is indefensible when the rejection came from a biased matcher, and it converts a fixable false rejection into a discrimination complaint. A score opens a review; a human, with context and an appeal, makes the decision — exactly as with a proctoring flag.

Build vs Buy: Match the Assurance to the Stakes

Lead with the business question, not the technology. The right amount of identity assurance is set by what the credential is worth and what a successful impersonation would cost — not by what the vendor can sell. A formative quiz needs no verification. A course-completion certificate might need an ID-and-face check once, at the start. A professional license or a regulated compliance exam justifies document check, face match, liveness, and continuous identity, with human review throughout.

Figure 4. A one-pass decision tree. Start with the stakes and the cost of a successful impersonation; add only the verification strength that cost justifies. Most assessments need far less than vendors propose.

When you do need it, the build-vs-buy reality is clear: buy the verification engine, do not build it. Credible document authentication, demographically tested face matching, and ISO/IEC 30107-3 liveness are years of computer-vision work plus an ongoing arms race against deepfakes — almost no learning product should build that in-house. The right architecture is to integrate a specialist identity vendor into your platform through LTI 1.3, keep the candidate's experience inside your product, and own the two things that are genuinely yours: the policy (what you collect, the threshold you set, who reviews referrals, how a candidate appeals, how fast you delete biometric data) and the integration (clean launch, reliable result return, no orphaned faceprints sitting in a vendor's bucket). The full annotated blueprint — lockdown client, identity service, capture, scoring, and the LMS bridge — is the proctoring and assessment reference design, and identity is one control in the wider anti-cheating picture.

Where Fora Soft Fits In

Fora Soft builds video, real-time, and assessment features for regulated products across e-learning, telemedicine, and other verticals where what you capture and how you store it carries legal weight. In identity verification specifically, the value we add is rarely the matching model — it is the engineering judgment to integrate a specialist verification vendor cleanly through standard launch-and-return, to design the data flow so a faceprint is minimized, encrypted, and deleted on schedule, to set thresholds and a human-review path so a bad match never auto-rejects a real candidate, and to wire continuous identity only where the stakes justify full-session biometrics. We help teams weigh the build-vs-buy trade-off honestly: how much assurance the credential actually needs, and how to get it without inheriting the privacy liability.

What to Read Next

• Online proctoring: approaches, trade-offs, and privacy — the behaviour-monitoring half of integrity, and where verification stops.
• Anti-cheating: detection, deterrence, and assessment design — the controls that, with identity, protect a credential.
• Proctoring and assessment reference design — the full annotated blueprint, identity service included.

Call to action

• Talk to a e-learning engineer — book a 30-minute scoping call to talk through your identity verification online exam plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Identity Verification Readiness Checklist — A one-page gate to run before you add identity verification to an assessment: choose the assurance level by stakes, pick the lightest defensible method stack, clear the consent and biometric-law questions (BIPA, GDPR Article 9, FERPA),….

References

1. NIST Special Publication 800-63-4, Digital Identity Guidelines (final, 31 July 2025) — identity proofing, Identity Assurance Levels, PAD and deepfake-signature requirements for remote IAL2. U.S. National Institute of Standards and Technology. Tier 1. https://pages.nist.gov/800-63-4/sp800-63.html
2. NIST SP 800-63B / 800-63-4 — knowledge-based verification (KBV) limited in identity proofing; knowledge-based authentication removed as a standalone authenticator. U.S. National Institute of Standards and Technology. Tier 1. https://pages.nist.gov/800-63-FAQ/
3. ISO/IEC 30107-1:2016 — Information technology — Biometric presentation attack detection — Part 1: Framework. International Organization for Standardization. Tier 1. https://www.iso.org/standard/53227.html
4. NIST Face Recognition Vendor Test (FRVT) Part 8 / NISTIR 8429 — Demographic effects in face recognition; false-match-rate variation across demographic groups. U.S. National Institute of Standards and Technology. Tier 1. https://pages.nist.gov/frvt/reports/demographics/nistir_8429.pdf
5. General Data Protection Regulation (GDPR), Article 9 — Processing of special categories of personal data (biometric data for unique identification). European Union, Regulation (EU) 2016/679. Tier 1. https://gdpr-info.eu/art-9-gdpr/
6. General Data Protection Regulation (GDPR), Article 28 — Processor (data-processing agreement). European Union, Regulation (EU) 2016/679. Tier 1. https://gdpr-info.eu/art-28-gdpr/
7. Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. § 1232g; 34 CFR Part 99. U.S. Department of Education. Tier 1. https://www.ecfr.gov/current/title-34/subtitle-A/part-99
8. Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14. Illinois General Assembly. Tier 1. https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004
9. eIDAS Regulation — electronic identification levels of assurance (low / substantial / high). European Commission, Regulation (EU) No 910/2014. Tier 1. https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467110081/eIDAS+Levels+of+Assurance
10. "How Deepfakes and Injection Attacks Are Breaking Identity Verification" — capture-source validation, multi-frame and passive-signal defenses; injection-attack volume. BleepingComputer / Group-IB reporting (2025–2026). Tier 6. https://www.bleepingcomputer.com/news/security/how-deepfakes-and-injection-attacks-are-breaking-identity-verification/
11. Pearson $18.2M BIPA class-action settlement (facial and palm scans at test centers and online proctoring); Respondus $6.25M settlement context. ClassAction.org / reporting. Tier 6. https://www.classaction.org/news/online-test-taking-software-proctoru-violates-ill-privacy-law-class-action-alleges

Per the editorial conflict rule, where vendor marketing claims of "100% accurate" or "unspoofable" verification conflicted with the NIST FRVT demographic findings and the documented deepfake-injection attack volume, this article follows the primary NIST evidence and treats vendor claims as marketing, not proof.