Conversations about secure browsers tend to be opinionated. Over time, I’ve noticed that many of the same assumptions and concerns come up again and again, often shaped by past experiences, incomplete information, or differences in how vendors approach security. In this post, I want to walk through a few of the most common misconceptions about secure browsers I hear and explain what’s often missing from those conversations.

Misconception #1: Secure browsers require administrative rights

This is probably the most common assumption I hear, and it’s also one of the easiest to overgeneralize. Secure browsers don’t inherently require administrative rights. Do admin rights make certain things easier? Yes. Do they provide additional control? Absolutely. But they aren’t necessarily required to run a secure browser.

In many environments, candidates simply can’t install anything that requires admin privileges, either because their devices are corporate‑managed or because those permissions aren’t available to them. That reality shapes how a secure browser needs to be designed. If you can meet your security goals without requiring admin rights, you can run in far more environments and on far more devices, while avoiding unnecessary friction for candidates.

This misconception often comes from past experience. Programs work with a vendor that requires admin rights, and that experience gets generalized into a rule that applies to all secure browsers. In practice, vendors may share the same goals but take very different technical paths to achieve them. A requirement imposed by one implementation shouldn’t be treated as a universal limitation of the technology.

Misconception #2: Recording the screen will catch the cheating apps

Hiding a window from screen recorders is trivial at this point. It’s a standard capability in most cheating tools, often using the exact same OS-level APIs that secure browsers rely on, just without any restrictions. It can also go further with direct OS manipulation, which those tools aren’t constrained from doing.

On top of that, many recording-based approaches require the exam content itself to be captured. From a security perspective, this is like an intentional back door that could be used by other cheats that rely on screen captures. This also creates a separate risk, because high-quality copies of test material now exist outside your control, leaving you dependent on the vendor to manage and protect them properly.

A secure browser avoids both problems. It doesn’t depend on what’s visible in a recording. Instead, it uses layered detection of windows, processes, and system behavior, so even if something is hidden visually, it can still be identified and blocked, or the session can be terminated.

Misconception #3: We don’t need a secure browser

A secure browser is not a silver bullet, and it’s not the only control in exam delivery. But it is the most critical layer. Everything else builds on top of it.

Secure browsers are the only component with direct control over the testing environment at the OS and application level. Without it, other controls, such as video monitoring or recording, are reactive and easy to bypass. With it, you gain active enforcement through visibility into windows and processes, the ability to block or terminate unauthorized activity, and a controlled environment for the exam itself.

In practice, the effectiveness of every other security measure depends on the secure browser being in place and doing its job. If you’re relying solely on a standard browser or a browser extension, your visibility into what’s actually happening on a device is limited. You may get heuristics or access to a small set of exposed APIs, but you don’t have meaningful control over the exam environment.

Claims that a browser alone can reliably detect things like virtual machines don’t hold up technically. You’ll miss real issues and encounter many false positives. Ultimately, meaningful endpoint control requires an application that can interface directly with the operating system.

That said, security decisions should always be made intentionally. For low-stakes assessments, running a secure browser may be unnecessary, and that can be a perfectly valid choice. The issue isn’t what decision you make, but how you make it. Problems arise when programs skip a secure browser based on the assumption that lighter-weight tools can provide the same protections. They simply can’t.

Why these distinctions matter

Most of these misconceptions don’t come from bad intent. They come from real constraints, past experiences, and the understandable desire to reduce friction. But security decisions work best when they’re made deliberately and with a clear understanding of tradeoffs.

Secure browsers aren’t automatically the right solution for every situation. However, assuming they all work the same way or dismissing them based on incomplete information leads to decisions that don’t reflect the actual risks involved. Better conversations about security lead to better outcomes for programs and candidates alike.

About the Author

Chris Glacken is the Director of Innovative Technologies at ITS. Chris has 11 years of experience in assessment, including over a decade in business and technical system requirements. He’s responsible for the ITS Secure Browsers and developed an in-house ‘white hat’ tool to identify Secure Browser vulnerabilities. He’s also the mastermind behind the ITS remote proctoring technology, ProctorNow™. He earned his bachelor’s degree in information science studies at Salisbury University, Perdue School of Business. When he’s not pioneering innovative ideas for testing software, you can find him playing Minecraft with his two sons.