Architecture comparison
ScreenComply vs Respondus LockDown Browser
Respondus LockDown Browser replaces the student's browser with a locked exam environment that prevents navigation, copying, and access to other browser functions, with Respondus Monitor adding webcam recording. ScreenComply works below the browser, at the operating-system level, where AI assistants, answer overlays, remote access, and secondary displays operate. Institutions commonly keep the lockdown browser for exam-environment control and add ScreenComply where AI assistance is the specific concern.
What LockDown Browser is built to see
LockDown Browser is a well-established control on the exam environment itself. It is widely deployed, integrates cleanly with major LMS platforms, and is familiar to faculty and students alike.
- A locked exam window with navigation, printing, and copy functions disabled.
- Prevention of other browser tabs and many browser-based workarounds during the exam.
- Webcam and audio recording through Respondus Monitor where enabled.
- LMS-integrated setup with instructor review of flagged recordings.
What a locked browser cannot observe
Locking the browser controls what happens inside the browser. Applications running beside it on the same machine are a separate layer, and a locked exam window has no visibility into that layer.
Modern assistance is specifically designed to live there: native overlays drawn above the exam window, often excluded from screen capture, that never interact with the exam page at all.
- Native AI assistant applications and answer overlays running next to the locked window.
- Remote-control sessions and virtual machines.
- Keyboard input that did not originate from local physical hardware.
- Additional displays not visible to the exam window.
- A phone or tablet used entirely off the monitored machine.
Layer-by-layer comparison
This compares what each layer is architecturally able to observe. It is not a scorecard: the two products are designed for different parts of the problem.
| Capability | Respondus LockDown Browser | ScreenComply |
|---|---|---|
| Browser tab and navigation control | Core capability — the browser itself is locked for the exam. | Not the primary layer — complementary to the browser control already in place. |
| Webcam and room monitoring | Available through Respondus Monitor where enabled. | Camera and audio signals where enabled by policy; not the primary detection layer. |
| Desktop AI assistant processes | Outside the browser boundary, so not observed. | Process enumeration against a maintained list of AI assistants and answer tools. |
| Always-on-top and transparent overlays | Not observed; overlays are often excluded from screen capture. | Overlay, transparency, and always-on-top window detection at the OS level. |
| Remote access and virtual machines | Limited or not observed from inside the browser. | Remote-control, virtualization, and capture-driver detection. |
| Secondary displays | Inferred at best, typically from gaze. | Displays enumerated directly from the operating system. |
| Input-source integrity | Not observed. | Verification that keyboard input originates from local physical hardware, plus clipboard and cadence signals. |
| Blocking restricted applications | Blocks browser functions and some known applications at launch; not an OS-level enforcement layer. | Prevent mode blocks restricted applications during the assessment window. |
| Evidence output | Recording review and flagged-behaviour indicators for instructors. | Timestamped evidence timeline with executive verdict, PDF export, and secure share links. |
Based on publicly available product information. Capabilities change; verify current functionality with each vendor.
When LockDown Browser alone is enough
For a large share of coursework, a locked browser is a proportionate control and adding device-level detection would be over-engineering.
- Routine quizzes and formative assessment with limited grade weight.
- Assessments where the realistic risk is notes and web search rather than AI assistance.
- Courses that need the simplest possible student launch path.
- Programs already using in-person or invigilated final assessments for the high-stakes components.
Running both together
The lockdown browser continues to control the exam environment; ScreenComply reports what was running on the machine around it. Detect mode observes and flags, while Prevent mode blocks restricted applications from launching during the exam window.
In Canvas, ScreenComply can keep the assignment or quiz sealed until the student is genuinely proctored and unlock it the moment the session goes live, so the enforcement sits in the workflow faculty already use.
Where to go next
Frequently asked questions
Is ScreenComply a lockdown browser?
No. It is a device-level detection layer with an optional Prevent mode. It runs alongside a lockdown browser rather than replacing the locked exam environment.
Can LockDown Browser stop desktop AI assistants?
It restricts the browser environment and can block some known applications at launch, but it is not an operating-system-level detection layer, so native overlays and assistants remain a gap.
Do students install two things?
Students launch from a single link. The ScreenComply agent runs for the assessment window and closes afterwards.
How are accessibility tools handled?
Major screen readers and magnifiers are whitelisted by default and are never treated as restricted tools; accommodations are configured per session by the institution.
What evidence does a flagged session produce?
A structured integrity report with an executive verdict, a timestamped evidence timeline, PDF export, and secure sharing for academic-integrity review.
ScreenComply is under contract with the State of Montana. SOC 2 Type 2 examination in progress.
See the device-level layer for yourself
A short walkthrough of live detection, Detect versus Prevent mode, and the integrity report your reviewers would actually receive.