Most exam security budgets go on watching the candidate. Meanwhile the fastest growing attack never appears in front of the lens: manipulated video injected straight into the verification pipeline, so the liveness check sees a flawless face that no camera ever recorded. One in every hundred identity check failures now involves a deepfake, and blink prompts do not catch it.
That figure comes from the LexisNexis Risk Solutions Cybercrime Report published on 14 July 2026, which also recorded deepfake attacks rising 180 percent year on year. It covers identity verification generally rather than exams specifically, and that is rather the point. Exams sit downstream of the same verification technology that banks and marketplaces use, so we inherit the same weaknesses on the same timeline.
Presentation attacks and injection attacks are not the same problem
A presentation attack is the one everybody designed for. Somebody holds a photo, a mask or a phone screen in front of the webcam. Depth cues, texture analysis, blink and head turn prompts all work here, because the sensor genuinely is looking at a scene, and a printed face behaves nothing like a real one.
An injection attack skips the scene. A virtual camera driver, a manipulated stream, a tampered mobile client, and the verification service receives video that was generated rather than captured. Ask that stream to blink and it blinks, convincingly, because the generator knows the prompt catalogue as well as your vendor does.
Ask your proctoring vendor which of these two columns their liveness check actually covers. The answer is rarely both.
Defending against the second column means inspecting the capture path rather than the face. Is this a real camera device or a virtual one? Does the client attest that it has not been tampered with? Does the stream carry the sensor artefacts a genuine capture would have? Those are different engineering questions from “does this person look alive”, and a vendor who only answers the second one has left the door open.
Why this hits exams harder than it hits banks
A bank verifies identity once, at account opening, then leans on behavioural signals and transaction monitoring for years afterwards. An exam usually verifies once, at the start, then hands the candidate 90 unsupervised minutes in which the only thing binding the answers to the person is the assumption that nobody swapped seats.
Proxy test taking has always been the highest value fraud in assessment, because the payoff is a credential rather than a single transaction. It is organised, it is priced, and the people running it treat a one time door check as a solved problem. Adding a deepfake to that operation removes the last requirement that the proxy resemble the candidate at all.
Behaviour analytics help, and we have written about what typing and navigation patterns catch that a webcam misses. They are the right instinct applied to the wrong half of the problem here. If the person at the keyboard has been the same person all along, and that person simply is not your candidate, no amount of keystroke analysis will say so.
Identity as a session property
The design change worth making is small to describe and awkward to retrofit: stop treating identity as a gate and start treating it as something the session carries.
Re-checks do not make impersonation impossible. They make it expensive and leave something reviewable behind.
In practice that means four things. Bind the session to the device and browser at check-in, so a mid-exam handoff to another machine is visible. Re-verify at unannounced points rather than only at the start, because a scheduled check is a scheduled swap. Verify the capture path each time, not just the face. And seal the evidence, so a review two months later reads a short trail of timestamped artefacts instead of replaying an hour and a half of video.
None of that is free. Each extra check is more biometric data you are holding, more processing to justify, and more chances to wrongly flag a student whose webcam driver is simply old. Anyone selling this as pure upside has not run it at scale.
The part I would not automate
A flag is not a finding. An injection detector that fires on an unusual capture path is describing a technical anomaly, and technical anomalies have boring explanations most of the time: a virtual camera left installed from a video call, a corporate laptop with an unusual driver stack, a student on a borrowed machine.
Every flag needs a human who can look at it, ask the candidate, and decide. That is the same conclusion we reached about proctoring signals in why hybrid proctoring won the argument, and it is worth restating because identity flags feel more definitive than they are. A machine saying “this stream was not captured by a physical camera” is useful. A machine deciding somebody cheated is a lawsuit.
What to ask your platform this month
Four questions, and you can ask them in a single email:
- Does your liveness check detect injected streams and virtual cameras, or only presentation attacks at the lens?
- Is identity verified more than once per exam session, and can we choose when?
- Is the session bound to a device, so a mid-exam machine change shows up?
- When a candidate disputes a flag six weeks later, what exactly do we hand the review board?
The last question is the one that separates a demo from a defensible system, and in my experience it is the one vendors answer least confidently. If the honest answer is “the recording”, the review is going to cost somebody a full afternoon per case.
Frequently asked questions
What is an injection attack in exam identity verification?
It is when manipulated video or images are fed directly into the verification software, usually through a virtual camera or a tampered client, instead of being shown to a real camera. The liveness check receives a stream that was generated rather than captured.
Can standard webcam liveness detection stop deepfakes?
It stops the ones held up in front of the lens. It does not, on its own, stop a stream injected behind the lens, which is why detection has to look at the capture path and device as well as the face.
How common is this really?
The LexisNexis Risk Solutions Cybercrime Report published in July 2026 found that one in every hundred identity check failures involved a deepfake document, image or liveness video, with deepfake attacks up 180 percent year on year. That is across identity verification generally, not exams alone.
Does re-checking identity mid-exam upset candidates?
Less than people expect, if it is quick and disclosed in advance. What upsets candidates is an unexplained flag after the fact, which is an argument for better evidence rather than fewer checks.
Is more biometric data a privacy problem?
Yes, and it should be treated as one. Collect the minimum that supports the decision, set a retention period, delete on schedule, and tell candidates plainly what is kept and for how long.
Related resources
- AI flags, humans decide: why hybrid proctoring won
- Why behaviour analytics catches what a webcam misses
- AI proctoring and exam integrity: signals, fairness, privacy
- How a smart online exam stays credible
- AI grading rules and what your platform owes candidates
Running exams that hold up
ICTExam is a smart online exam platform with AI assisted grading and a review trail built for the moment somebody questions a result. If you are auditing how your current platform handles identity, or you want to talk through re-verification without turning your exam into a surveillance exercise, open a support ticket and we will go through it with your exam format in mind.