Most web traffic is now encrypted (HTTPS), so our platform is built to inspect it rather than work around it. At full capability, SSL/TLS inspection decrypts traffic against policy and re-encrypts it — giving category-level control and safeguarding keyword visibility inside encrypted sites, not just at the domain name. This works because the platform inspects inline, in the path of the traffic, using a trusted certificate deployed to school devices via your MDM or group policy.

Modern encryption is exactly the “dynamic, encrypted environment” the 2026 guidance highlights, and we maintain visibility across its newer layers:

• TLS 1.3 — supported and inspected via the deployed certificate. TLS 1.3 defeats older passive monitoring appliances that relied on a copy of the server’s key; because we inspect inline, we are not affected by that. The few exceptions are covered below.
• Encrypted Client Hello (ECH) — ECH hides which site is being visited. We resolve DNS through our own servers, so ECH is not negotiated, and the plain destination is exposed for filtering.
• QUIC / HTTP-3 — where a browser tries to use QUIC (which is built to resist inspection), the platform declines it, so the browser falls back to standard HTTPS, which is then decrypted and filtered as normal.

This is a dialable control. A school can run with full inspection for the strongest safeguarding visibility, or scale it back — for example, inspecting pupil traffic but not staff, or excluding specific categories — and change that balance at any time on request.

In the interests of transparency, a minority of traffic cannot be content-inspected and is instead filtered at domain level (allowed or blocked): apps that “pin” their certificate and services using mutual (two-way) certificate authentication — for example some banking and operating-system services — reject any inspection certificate by design; and a small number of sites that operate in ways incompatible with inline inspection are bypassed for compatibility. In all these cases, the site is still subject to allow/block at the domain level; only its content is not decrypted. We will always tell you plainly which traffic is inspected and which is not.

Filtering and monitoring are delivered from our cloud platform: your broadband traffic is filtered and logged centrally, so protection applies without any filtering software on the device. This is the model for the large majority of in-school use. 

What sits on the device is light-touch, and dialable to the level a school wants: 

• An inspection certificate — to filter inside encrypted (HTTPS) sites, a trusted certificate is deployed to managed devices via your MDM or group policy. Deploy it widely for full visibility or to a subset of devices — your choice, changeable on request. Without it, encrypted sites are still allowed/blocked at the domain level. 

• An authentication helper (where used) — a lightweight agent, identifies the signed-in user so the correct policy (staff/pupil/admin) follows them. It authenticates the user; it does not filter. 

Our own filtering and monitoring run in the cloud, not on the device. 

Off-network use (a device taken home, or on mobile data) no longer passes through our platform automatically, but it can still be filtered. We provide an off-site explicit proxy that managed devices are configured to use when away from school (typically enforced through your MDM). You choose the level: 

• With user identification — if you run a local Active Directory we can connect to, off-site users sign in at a captive portal and are placed in their correct filtering group, so activity is filtered and attributed by username on reports, just as on-site. 

• Without identification — devices use the off-site proxy mapped to a single filtering group: traffic is still filtered to policy, but activity is not attributed to named users. 

For a device-resident approach instead, we work with a specialist partner (Smoothwall). In every case, enforcing the proxy or agent on the device sits on your side, so off-network protection is something you switch on and scale as you choose. We set out clearly what the network protects and what depends on device configuration, so the boundary is never a surprise.