When the Last Mile Fails: Designing a Zero-Trust WAN That Bends Without Breaking
Photo: SwarmCheng, CC BY-SA 4.0, via Wikimedia Commons
Most UK zero-trust plans assume the underlying wide-area network will stay up. Identity providers will be reachable, policy engines will return decisions, and branch traffic will find a path to the cloud. That assumption is understandable: zero trust deliberately treats the network as untrusted. But untrusted is not the same as unimportant. When an Openreach fibre cut, an exchange failure or a carrier backhaul incident takes out the last mile, a cloud-first branch can lose the very connectivity it needs to enforce policy. The result is not a graceful security posture; it is a stranded site and a queue of users on mobile hotspots.
A resilience playbook for 2026 should treat connectivity as a trust dependency. The aim is not to keep every link alive. It is to ensure that the organisation can degrade predictably, preserve access to critical services, and restore trust decisions when paths return.
Map the failure modes before choosing the fix
Not every outage is the same. A local fibre cut may affect one site; an exchange power failure may affect a town; a carrier control-plane incident may affect many customers at once. Map critical branches, distribution centres, clinics and remote teams against their tolerance for downtime. Identify which applications can be reached over alternative paths and which require local survivability. Include the less obvious dependencies: DNS resolution, authentication callbacks, VPN concentrators and the supplier's own support portal. A WAN that is up but cannot reach the identity provider is still down for practical purposes.
Independence must be engineered, not purchased
Two circuits from the same provider are not two paths. They may share ducts, exchanges or backhaul. When buying diversity, ask for physical route maps and contractual commitments about separation. Check whether the secondary path is fixed wireless access, a different fibre altnet or a 5G service with adequate coverage at the site. For smaller locations, dual-SIM routers with different mobile networks can provide useful diversity. But independence is a property to be tested, not a checkbox. A quarterly route review is more valuable than a one-off design workshop.
Identity-aware failover, not just link failover
Traditional SD-WAN failover reacts to link state. Zero-trust access reacts to identity, device posture and context. The two must be designed together. When traffic moves to a 5G backup, policy should not silently relax. Device compliance checks, conditional access and session limits should still apply. At the same time, a backup path may have lower capacity and higher latency, so policy should degrade gracefully: prioritise voice and critical SaaS, restrict bulk transfer, and step up authentication for sensitive actions. Avoid a break-glass account that bypasses every control; if it exists, make it time-bound, monitored and tested.
5G backup is useful, not magical
5G has become a credible backup for many UK branches, but it is not a universal replacement for fibre. Coverage varies inside buildings, capacity falls under contention, and some plans use carrier-grade NAT that complicates inbound tunnels. Test at peak hours, not in an empty office. Use multiple mobile networks where the site is critical, and confirm that the backup path can reach your cloud security edge and identity provider. Data caps and latency matter for real-time applications. For remote or rural sites, fixed wireless or satellite may be more appropriate.
Tabletop testing should include the boring parts
Resilience exercises often focus on the dramatic moment: the fibre is cut, the link fails, the backup comes up. The harder questions are operational. Who notices? How is the incident declared? Can the service desk see which sites are affected? Are users told what to do? Can the identity team revoke sessions if a path is suspected of being compromised? Run tabletop exercises that include the WAN provider, the MSP and the application owners. Simulate an Openreach outage at a specific branch and measure time to failover, user impact and the number of manual steps. Test the runbook when the primary path is down and the secondary path is congested.
Monitor the chain, not just the link
End-to-end observability is essential. Synthetic transactions can show whether a branch can reach the identity provider and critical SaaS, not merely whether the router has an uplink. Integrate carrier notifications into incident management. Track mean time to detect and restore by site tier. Report resilience metrics to the board alongside security metrics, because a zero-trust programme that cannot survive a last-mile outage is not resilient.
Conclusion
Connectivity is a chain of trust decisions: device, identity, policy engine, network path and application. Zero trust does not remove the need for resilient paths; it raises the cost of losing them. The organisations that cope best with the day Openreach goes dark will be those that have engineered independent paths, tested identity-aware failover and rehearsed the unglamorous operational details. Resilience is not a single backup link. It is the discipline of knowing which dependencies can fail, and how trust will be maintained when they do.
