The pitch makes it sound like a single platform you can procure, deploy, and tick off the roadmap. The reality is different. SASE works when you treat it as a way to operate networking and security as one system. It fails when you treat it as a vendor SKU bought during a refresh cycle.
This insight covers what changes when SASE is adopted as an operating shift, why the network underlay determines whether the security overlay performs, and what a readiness review should examine before any platform decision.
Buying a SASE platform without adapting how the team works produces a more expensive version of the same operating problems. Three questions frame the decision honestly.
The technology change is the smaller half of the work. SASE moves networking and security from boxes at sites to services in the cloud, with identity as the access decision. That shift only delivers if policy ownership, monitoring, escalation paths and the day-to-day operating model also change.
Identity moves from a login step to the access decision. Policy moves from device-by-device firewall rules to centrally managed cloud policies. Network and security stop operating as two separate functions. Monitoring centralises into one view. Branches simplify. Each is manageable, but only when the operating changes are planned alongside the platform, not after it.
The network underlay and whether it can support local internet breakouts at branches. The identity platform, MFA enforcement and conditional access. The application map and which workloads still rely on VPN. The security stack, the team and operating model, and the performance baseline that SASE will be measured against.
If a rollout is scoped without a parallel conversation about who owns policy and how the operating runbook will change, it is a technology project, not a SASE adoption.
Each of the five shifts is well within the engineering capability of any competent IT team. None requires learning an entirely new discipline. What they require is a deliberate change to how the team operates. The hard part is rarely the technology. The hard part is the practice.
Your SASE framework is only as good as the network it is built on. Cloud-delivered security at the edge does not compensate for branch links that cannot reach the edge reliably, for sites still on a single fragile broadband connection, or for an underlay that has not been measured in years. Routing Microsoft 365 traffic from a branch through a central data centre and then out to the cloud is like flying from Paris to London via New York — it works, it just costs more, takes longer and breaks more often than the direct path. SASE enables the direct path. It does not build the runway.
Local internet breakouts at branches are the practical expression of the SASE promise — and underlay quality is the precondition, not the consequence, of a good rollout.
A SASE readiness review is not a vendor demo. It is a current-state assessment that determines whether the organisation is positioned to actually adopt the operating shift, and which sequence of work matters most. The output is a map of where the business is now, not a slide deck recommending a specific product.
A SASE readiness review is the input. Platform selection, ZTNA rollout, branch standardisation and managed network support are possible outputs, sequenced by what the review actually finds.
Inlight IT's view is that most SASE conversations start too late in the decision. By the time the vendor shortlist is being compared, the more important questions should already have been answered: which branches can support direct internet breakout, which applications still depend on VPN, whether MFA and Conditional Access are consistently enforced, what the current performance baseline is, and who owns policy changes once network and security controls converge. Inlight IT runs that review and operates the resulting architecture as part of cyber-first managed services for Australian businesses.
SASE does not fix a weak underlay, unclear policy ownership, or identity controls that are not consistently enforced.
Make the current state visible first
Answer the underlay question honestly
Treat identity systems as primary infrastructure
Plan the operating model alongside the platform
The argument on this page — that SASE is an operating shift rather than a product purchase, that identity and network underlay are prerequisites rather than parallel projects, and that readiness review precedes platform decision — describes how Inlight IT delivers SASE & Zero Trust Access. For a focused VPN-replacement view, the ZTNA vs VPN and SASE vs VPN vs Zero Trust comparisons cover the access-model decision.
Identity readiness, application dependency mapping, ZTNA suitability, SASE architecture fit and migration sequencing.
The deeper architectural decisions behind a SASE rollout.
The ZTNA layer of the architecture, covered in depth.
Review network, identity and application readiness before committing to SASE. Scoped to your environment — Inlight IT remains the accountable service owner throughout.
Discuss SASE & Zero Trust