Sessions in Motion: The Commuter Test for Zero-Trust Networks You Do Not Own

The workplace moved; the policy did not

A zero-trust strategy is often described as a set of decisions about users, devices and resources. In practice, it is also a set of assumptions about the network between them. Many UK enterprises still build those assumptions around a managed office connection, a known wireless estate and a helpdesk that can be reached from a desk. The 07:42 from Reading, a station lounge at Manchester Piccadilly or a client meeting room in Leeds does not respect any of that.

The result is a familiar pattern. Authentication succeeds, the session starts, and then the network changes underneath it. A captive portal interrupts traffic. A roaming SIM hands over between operators. A train enters a tunnel and returns with a different public address. The user sees a login prompt, a timeout or a blank screen. The service desk sees an access incident. The security team sees a policy exception. None of these descriptions is quite right.

The real issue is that the zero-trust estate was designed for a stable perimeter of experience, even if not a stable perimeter of infrastructure. It needs to bend with the mobile workforce rather than snap.

Network provenance is a signal, not a gate

Zero trust already treats identity and device posture as inputs to an access decision. Network provenance deserves similar treatment, but with an important qualification: it should inform risk, not become a crude allow-or-deny test. A train Wi-Fi network, a hotel captive portal and a client guest network are not equivalent to an unknown internet café, but neither are they interchangeable with a managed corporate LAN.

A practical approach is to classify provenance without overclaiming precision. The categories might include managed corporate access, trusted partner access, public mobile data, public Wi-Fi behind a captive portal, and unknown or degraded access. The point is not to assign a perfect label to every packet. It is to give policy engines enough context to choose an appropriate assurance response: allow, allow with limited scope, require step-up authentication, restrict sensitive actions, or defer non-urgent work until the connection stabilises.

That distinction matters in the UK, where mobile coverage can vary sharply between operators and between routes. A policy that treats every non-office connection as hostile will generate friction on the very journeys where staff are trying to remain productive. A policy that treats every mobile connection as equivalent will understate risk. The middle ground is continuous evaluation with proportionate responses.

Captive portals and roaming SIMs expose two different failures

Captive portals are an interruption problem. They often break the first connection attempt, redirect traffic and expire at inconvenient moments. From a zero-trust perspective, the danger is not only that access fails; it is that users and support teams develop workarounds. Staff may tether to a personal device, disable a security agent to reach a portal, or reuse a session that should have been re-evaluated. Each workaround erodes the evidence base on which zero trust depends.

Roaming SIMs are a continuity problem. A session may begin on one network and continue on another, with a changed address, altered latency and different middlebox behaviour. If the access policy is tied too tightly to a single network characteristic, the session will be torn down precisely when the user needs it most. If it is tied too loosely, a genuine change in context may go unnoticed.

The design question is therefore not whether to trust mobile networks. It is how to preserve an auditable chain of decisions across a connection that is visibly changing.

A five-journey test for UK access design

A useful way to test whether a zero-trust estate can support mobile work is to model journeys rather than sites. Take five real journeys that matter to the business: a commuter route with intermittent coverage, a station lounge with a captive portal, a client site with guest Wi-Fi, a regional office with a different ISP, and a home-to-office transition using a roaming SIM. For each, ask four questions.

First, what does the policy know about the network at the moment of access, and how fresh is that knowledge? Second, what happens when the network changes mid-session: is the user re-evaluated, stepped up, or simply disconnected? Third, can the user reach the resources they need without disabling controls or borrowing credentials? Fourth, what evidence is retained so that an auditor can reconstruct the decision later?

The test should be run with real devices, real user profiles and real service desk involvement. A laboratory simulation of poor connectivity is useful, but it rarely reproduces the particular frustration of a portal that accepts the connection and then blocks the authentication flow.

Design for step-up, not tear-down

The most resilient pattern is usually step-up rather than tear-down. When provenance changes or posture information becomes stale, the policy should ask for a stronger signal before granting sensitive access. That might mean re-authentication, a device compliance check, a restricted session, or a requirement to use a managed route for particular applications. The aim is to keep ordinary work moving while raising assurance for actions that warrant it.

This requires product teams and identity teams to agree on which actions are truly sensitive. A blanket re-authentication prompt for every network transition will train users to click through without reading. A policy that never re-evaluates will fail the first serious audit. The workable middle is a tiered model, tested against the five journeys and measured in both assurance and friction.

Measure the commute, not just the login

Most access dashboards report authentication success. Fewer report session continuity across network change, step-up rates by journey, or the proportion of access incidents that originate from captive portals and roaming transitions. Those measures matter because they show whether the zero-trust estate is behaving as designed when the network is not.

For UK organisations entering 2026 with a mobile-first workforce, the commuter test is a sensible addition to assurance. It does not require a new architecture. It requires the existing one to be honest about the network it actually traverses. Zero trust should hold at line speed, including the line that runs through a tunnel.