SASE

SASE moves the security stack from a box in the data centre to a set of points of presence in the cloud that users and sites connect to. Traffic is routed through that edge, where the controls are applied together: a secure web gateway filters outbound web access, a cloud access security broker governs use of cloud applications, ZTNA provides per-application access to private resources, and firewall-as-a-service handles the rest. The networking half (software-defined WAN) steers traffic efficiently to the nearest edge. The security-only subset of this bundle, without the WAN piece, is often called SSE. The appeal is one policy applied consistently to every user, wherever they work, instead of a different control set per location.

Consolidation concentrates trust. A SASE platform sees and can decrypt a large share of an organisation’s traffic, so its own configuration and access controls become high value: a weak admin account or an over-broad policy affects everything routed through it. In deployments we review, the common gaps are inconsistent coverage (some traffic bypasses the edge and reaches the internet directly, undoing the filtering), TLS inspection that is enabled unevenly so data loss prevention and web filtering only see part of the flow, and egress rules that are permissive because tightening them broke something once. The platform is only as good as the traffic it actually intercepts.

We assess a SASE deployment by coverage and by the strength of its own controls: does all intended traffic actually traverse the edge, is inspection consistent, are the outbound and application policies enforcing what the client believes, and how is administrative access to the platform protected. Findings are written against the bypass or the weak policy, with the uncontrolled path demonstrated. Because the platform aggregates so much, its administrative security is assessed with the same rigour as a domain controller.