How do candidates bypass browser lockdown tools during remote exams?

What lockdown actually controls

A lockdown browser restricts the exam device during the session: it blocks other applications and browser tabs, disables copy and paste and printing, and prevents navigation away from the exam. Against a casual, opportunistic attempt to look something up on the same machine, it works well and deters more than it catches.

Its boundary is the operating environment it runs in. Anything outside that environment, meaning another device, another computer, a helper in the room, or a layer beneath the operating system, is outside its field of view by design, not by failure.

The bypasses programs actually encounter

Virtual machines are the classic route: the exam runs locked inside a window while the host machine stays free for notes, messaging, and AI tools. Second devices are the simplest: a phone or tablet below camera line answers questions the locked screen never sees. Pre configured system settings and accessibility tools are misused to reopen blocked functions.

None of these require advanced skill anymore. Instructions and ready made setups circulate in candidate forums within days of any new exam launch, written for people with ordinary technical ability. A control that depends on candidates not finding those instructions has a short life.

Detection has to look beyond the browser

Programs catch bypasses by combining signals: environment checks that flag virtual machines and remote access tools before the exam starts, process monitoring during the session, webcam and screen recording reviewed for second device behavior, and answer pattern analysis after the fact.

Behavior is often the loudest signal. Eyes repeatedly dropping to the same off camera point, typing pauses that align with reading from elsewhere, and answers in a different voice from the candidate own short responses all point outside the locked screen. No single signal proves anything. Together they build a case worth human review.

Layering controls without punishing honest candidates

The workable model is layered: identity check at entry, environment scan before start, lockdown during, human or assisted review of flagged sessions, and a fair appeals route. Each layer is modest. Together they raise the effort of cheating above the effort of studying for most candidates, which is the realistic goal.

Friction discipline matters. Every extra check taxes honest candidates too, and a program that treats everyone as a suspect will lose registrations to competitors. Put the heavy scrutiny on flagged sessions, keep the standard path smooth, and explain the rules and the reasons before exam day.

What to do when a bypass is confirmed

Have the consequence decided before the incident: score invalidation, retest under stricter conditions, a waiting period, or referral to a licensing body, applied consistently to the evidence standard you published. Improvised punishments collapse under appeal, and inconsistent ones collapse under comparison between candidates.

Feed every confirmed case back into the control design. Which layer missed it, which signal appeared first in hindsight, and what would have caught it a session earlier. Bypass methods evolve in public. A program review cycle that ignores its own case history falls behind on a schedule.

Keep reading: How should testing programs verify candidate identity without making check in a nightmare?, How are candidates using AI tools to cheat on remote exams, and what actually detects it?, and How should testing programs secure an exam item bank before launch day? cover the nearby cases in this series.

Frequently asked questions