← Back to blog

Exam security has a deployment problem. The controls that actually work — network-layer enforcement, OS-level monitoring — traditionally require persistent agents, kernel drivers, and elevated privileges. That friction rules them out for most testing contexts. Candidates can't be expected to install kernel modules. Universities can't push driver packages to every personal device.

The emergence of WireGuard as the dominant VPN protocol changes this calculus. Its design properties — ephemeral per-session keys, user-space operation, sub-second setup — make it particularly well-suited for a use case that demands isolation that deploys fast and disappears completely.

What WireGuard Is and Why It Matters for Short-Lived Sessions

WireGuard is a modern VPN protocol built on the Noise Protocol Framework. Unlike OpenVPN, which layers TLS on top of TLS and carries years of backward-compatibility weight, WireGuard was designed from scratch with a minimal attack surface — fewer than 4,000 lines of code for the reference implementation.

For exam security, the relevant properties are:

Cryptographic identity via keypairs. Each party in a WireGuard tunnel is identified by a public/private keypair. The public key functions as a peer identifier; the private key never leaves the device that generated it. This means each session can have its own keypair, generated at session start and discarded at session end.

Fast handshake. WireGuard's handshake takes approximately one round-trip. Tunnel establishment completes in under a second from a cold start. Contrast with IPsec, which requires multiple exchange phases before data flows.

No persistent session state. When a WireGuard tunnel drops, it leaves nothing behind. There are no session tokens, no configuration artifacts, no cache entries. The tunnel either exists or it doesn't. This is a consequence of WireGuard's stateless handshake design — if no data has flowed recently, the tunnel is considered inactive and no teardown protocol is required.

Traditional VPN protocols — OpenVPN, L2TP, older IPsec implementations — write configuration to disk, maintain session state in memory, and often leave artifacts after disconnection. For an exam platform, these residual artifacts are a liability. For WireGuard, there is nothing to clean up.

The Per-Session Key Architecture

The practical consequence of WireGuard's keypair model is that exam sessions can be cryptographically isolated from one another at zero marginal cost.

When a candidate starts a session, the platform generates a fresh keypair for that session. The public key is registered with the gateway for the duration of the exam. When the exam ends, the keypair is discarded on both sides. The next session for the same candidate generates a completely different keypair.

This architecture has a specific security property: a compromised session key tells an attacker nothing about past or future sessions. Each session is cryptographically independent. There is no long-lived credential that, if obtained, provides ongoing access.

Compare this to always-on endpoint agents — the approach taken by most legacy proctoring tools. These agents maintain a persistent cryptographic identity for the device. Once that identity is established, it is reused across sessions. Compromise it once, and you have a persistent foothold. More practically: the agent is always present, always consuming resources, and always a target for tampering.

Ephemeral per-session tunnels have no persistent state to tamper with. When the exam is not in session, the tunnel does not exist. There is nothing to attack.

User-Space Deployment — Why It Matters

WireGuard's other operationally significant property is that it runs entirely in user space on the candidate's device. No kernel module is required on modern systems — WireGuard is included in the Linux kernel since 5.6, and user-space implementations exist for Windows and macOS that operate without any driver installation.

This changes the deployment story substantially.

A kernel-mode VPN client requires administrator privileges to install, often requires a reboot to activate, and touches the OS in ways that make candidates and IT administrators nervous. Kernel bugs in third-party drivers have caused system crashes and security vulnerabilities in the past. Enterprise security teams have learned to treat kernel driver deployments with appropriate skepticism.

A user-space WireGuard implementation installs like any other application. No kernel interaction. No reboot. Elevation is needed for network interface configuration — creating the tunnel interface — but this is a contained, standard OS operation, not a persistent kernel-mode driver.

The practical result: a network-layer security agent can install in approximately 30 seconds on a candidate's machine without a kernel driver, without a reboot, and without the kind of system-level access that triggers IT policy reviews.

What the Tunnel Enables for Exam Enforcement

The tunnel itself is infrastructure. What matters for exam security is what the platform enforces through it.

When all device traffic is routed through a WireGuard tunnel to a policy enforcement gateway, the gateway becomes the single exit point for the candidate's device during the exam. The gateway applies an approved-domain list — only domains explicitly whitelisted for the exam can be reached.

The enforcement happens at the gateway, not at the device. This is the important distinction.

A device-side enforcement approach — browser extensions, application-layer controls, DNS configuration — is always vulnerable to the candidate manipulating it. Rename a binary. Modify a hosts file. Use a different browser. Device-side controls have a surface area that a motivated candidate can probe.

Gateway-side enforcement has no such surface area on the device. The candidate's machine does not make the policy decision. The gateway does. Whatever process on the candidate's device makes the outbound request — regardless of its name, regardless of which binary it runs — the request exits through the tunnel and hits the gateway. If the destination is not on the approved list, the request is dropped.

An AI overlay running under an arbitrary process name still cannot reach its inference endpoint. The request goes to the gateway. The gateway checks the destination. The destination is not whitelisted. The connection fails. The process name is irrelevant.

The Key Insight

WireGuard's design — ephemeral keys, user-space operation, sub-second setup — maps unusually well onto the constraints of exam security: sessions that need to start quickly, provide strong isolation, and leave no trace when they end.

The combination of per-session cryptographic isolation and gateway-side policy enforcement closes the gap that browser-based proctoring leaves open. Network requests don't reach their destinations because the gateway doesn't allow them — not because the candidate's device is configured to block them. That distinction is what makes the enforcement tamper-resistant.

Network-layer exam security platforms use per-session encrypted tunnels to enforce approved-domain policies before any tool can make an outbound connection. See how the architecture works →