Platform selection is the easy part. Sequencing is the discipline.
SASE is the architecture. Zero Trust is the access model. Both depend on identity readiness — and that is what most SASE deployments underestimate. SASE brings network access and security controls together around the user, device, application and session, but it is not a single product purchase. The right deployment usually starts with identity cleanup and application dependency mapping, then a staged transition from VPN to ZTNA and Secure Web Gateway before broader controls are added.
See the staged deployment phasesSASE is not one product; it is one access and security model. It converges up to five capabilities — SD-WAN, Zero Trust Network Access, Secure Web Gateway, CASB and Firewall as a Service — into a consistent policy model for distributed users, branch sites, SaaS and cloud applications. Most organisations do not activate every capability on day one. ZTNA and Secure Web Gateway usually come first; CASB follows as SaaS and AI-tool governance matures; SD-WAN is often already in place.
SASE converges five capabilities into one policy model.
The practical value is architectural: it brings networking and security controls closer to users, devices, applications and sessions, rather than assuming traffic will always pass through an office, datacentre or perimeter firewall. For many Australian organisations the first visible value is not only VPN replacement — it is visibility into SaaS, browser-based work and AI-tool usage that was previously outside policy and reporting.
SD-WAN
Application-aware connectivity across sites and users, with intelligent routing, multi-link failover and direct cloud breakout. In SASE it is the network foundation branch access and cloud performance depend on — and it is often already in place before the program begins.
ZTNA
Identity-based application access. Users authenticate with MFA and device compliance, then reach only the specific applications they need, not the underlying network — replacing the legacy VPN model where one connection grants broad network access. Usually the first capability to deploy.
Secure Web Gateway
Inspects and filters internet-bound traffic, enforcing application allow-listing, threat prevention and data-loss policy regardless of where the user works — giving remote and hybrid users the same posture as office users without backhauling all traffic.
CASB
Visibility and control over SaaS applications and cloud data — identifying shadow IT, unsanctioned SaaS, risky AI-tool usage and data movement. Becomes more important as governance matures and SaaS usage expands outside centrally managed platforms.
Firewall as a Service
Cloud-delivered network firewall policy enforcement, giving consistent network-level security for branch and remote users without deploying hardware at every location. Relevant when distributed inspection is needed without increasing appliance complexity.
SASE is strong when the access model is ready. It is risky when the foundation is not.
Not every organisation is ready to deploy SASE today, and the cost of deploying before the foundation is right is operational, not just technical. The signals below separate "the right next conversation" from "preparation work needs to happen first."
- VPN is the primary remote-access model and ZTNA migration is overdue
- SaaS and AI-tool usage is outside policy and visibility
- Essential Eight or cyber insurance is driving Zero Trust and MFA
- Microsoft 365 or Fortinet SD-WAN is already the foundation
- Consistent policy is needed across office, remote, hybrid and contractor access
- Access decisions must weigh identity, device posture, application sensitivity and session context
- Entra ID has stale accounts, orphaned groups or inconsistent MFA
- Application inventory is incomplete and VPN access patterns undocumented
- Device management is not in place and compliance cannot be assessed
- No one owns Conditional Access, ZTNA entitlements and CASB rules ongoing
- A platform is being selected before the access model and dependency map are understood
- The business expects instant VPN replacement without pilot, rollback or staged decommission
Where the situation sits in not ready, preparation — identity cleanup, application mapping, Conditional Access remediation — needs to happen before any SASE platform decision is committed to.
Platform selection should follow the existing identity and edge stack.
Two platform paths cover many Australian SASE deployments. The right choice should follow the existing identity stack, network edge, operating model, sovereignty requirements and application dependency map — not vendor preference. In larger environments the two can coexist.
Built on the same identity platform as Microsoft 365 and Conditional Access, it requires no new branch-edge hardware. For organisations already standardised on Microsoft, this is often the most natural SASE or SSE path.
Best fit: organisations already on Microsoft 365 and Entra ID with Conditional Access in use, where the primary use case is user access to SaaS, internet and cloud applications.
For organisations with Fortinet SD-WAN already deployed, SASE capabilities activate on the same FortiGate hardware without a network redesign — particularly relevant where Fortinet already handles both networking and security at the branch edge.
Best fit: organisations with Fortinet SD-WAN deployed, FortiGate managing both network and security at the edge, and multi-site environments where hardware consistency and Fortinet operating depth matter.
SASE enforces the identity model you bring to it.
Conditional Access and ZTNA policies applied to a disorganised identity estate will either miss users or block access unexpectedly. The assessment and cleanup phase is not optional — most failed SASE rollouts are identity problems before they become technology problems.
Accounts for former staff still active in Entra ID create unnecessary exposure. Groups with no current owner, no clear purpose or inaccurate membership create unreliable policy targeting — Conditional Access and ZTNA policies applied to them produce unpredictable outcomes.
SASE assumes MFA is a reliable signal. If enrolment is inconsistent — some on authenticator apps, some on SMS, some without coverage — device compliance and identity verification cannot be enforced uniformly. Exceptions must be documented, minimised and reviewed before rollout.
ZTNA grants access to specific applications. If inventories are incomplete, the migration will block legitimate access that was implicit in the old VPN model. A full dependency map is required before policy is written.
The required foundation before SASE policy is deployed:
The more mature the existing estate — device compliance, named locations, sign-in risk, group hygiene — the more effective the SASE policy layer is from day one.
Device-posture checks require devices enrolled in Intune or compatible MDM. Unmanaged devices using VPN today need a compliance pathway before ZTNA can enforce device health.
Every application accessed through VPN catalogued — owner, user groups, authentication method, internal dependencies and legacy access constraints. This is the map ZTNA policy is written against.
SASE transitions fail when policies are applied before identities, applications and dependencies are understood.
Deployment starts with discovery and cleanup so Conditional Access and ZTNA policies land on a clean foundation. A structured transition typically runs 8 to 16 weeks from identity audit to full VPN decommission. The critical path is identity and dependency mapping, not technical configuration.
Every user group, application, VPN tunnel and legacy access control list is catalogued before any policy is written. Access patterns are mapped per group, shadow IT identified, MFA and device-compliance status reviewed. Output: a dependency map of who needs which applications and what breaks if VPN is removed too early.
Stale accounts and groups removed or resolved, duplicate and conflicting identities merged, Conditional Access prerequisites confirmed across all groups, device-compliance baselines established. This phase determines whether policy deployment is clean or chaotic.
ZTNA and Secure Web Gateway policies deployed to a representative segment while the legacy VPN stays operational. The pilot validates access, performance, policy coverage, device compliance, support paths and user experience under production conditions. Rollback remains available until cutover is confirmed.
Validated policies rolled out progressively by user group, not through a hard cutover. The legacy VPN is decommissioned only after the new environment is confirmed for each group. CASB and FWaaS are activated as governance requirements mature, with continuous compliance reporting aligned from day one.
Running SASE alongside VPN without a migration plan means users revert to VPN when they hit friction — and the security gaps SASE was deployed to close remain open.
Sovereignty is a design decision, not a default.
Both Microsoft Entra SSE and Fortinet FortiSASE can support Australian traffic inspection, but residency should not be assumed from the platform name alone. For organisations with Privacy Act obligations, regulated-industry requirements or government-aligned policy, sovereignty is decided at the architecture stage. The design should document precisely:
- Where traffic is processed
- Where logs are retained
- Where management data resides
- Who has administrative access
- Which support personnel can access management data
- Which data types may cross borders
- Which controls and contractual settings apply
Identity-led residency
Supports Australian points of presence for Global Secure Access. Traffic can be designed to use Australian infrastructure where available; management and policy data should be reviewed against Microsoft's Australian residency commitments and the tenancy configuration.
Edge-led residency
Supports Australian management and inspection architecture when designed accordingly. Where in-country management is required, review FortiManager, FortiAnalyzer, FortiSASE points of presence and log handling explicitly — particularly where Fortinet already manages the branch edge.
Cross-border accountability
Where SASE telemetry, access logs or identity events are processed by a management plane outside Australia, APP 8 creates accountability obligations for cross-border disclosure. Document where each data type is processed and confirm handling before deployment.
The output should be an auditable residency record, not only a vendor assurance. Local traffic inspection can reduce cross-border data-transfer exposure under the Australian Privacy Principles when designed correctly.
SASE can support Essential Eight controls, but architecture alone does not deliver compliance.
SASE addresses several of the most operationally difficult Essential Eight controls in a distributed environment. Correct configuration, operational discipline and documented evidence still determine the outcome.
- Restrict Administrative Privileges — ZTNA can enforce just-in-time, application-level access for privileged connections; administrators hold no standing network-level access, and access is scoped, verified at connection and logged
- Multi-Factor Authentication — Conditional Access enforces MFA for remote access, privileged operations, internet and application access from one control plane; value depends on coverage and exception control
- Application Control — Secure Web Gateway supports application allow-listing, web filtering and policy enforcement regardless of user location, especially for SaaS, browser-based tools and AI services
- Patch Management and device compliance — Conditional Access can enforce device compliance including patch status as a condition of access, with a continuous (not point-in-time) posture signal
- Audit evidence — a continuous record of who accessed what application, from which device, when, under which policy and with what compliance status — the evidence perimeter-led stacks cannot capture consistently for a distributed workforce
Most SASE deployment failures are identity, sequencing and ownership failures.
These are the specific failure modes that appear consistently in deployments that did not start with the right foundation — each with the fix that prevents it.
Policies applied to a disorganised identity estate produce unpredictable outcomes. Stale groups grant access to the wrong users; orphaned accounts create gaps; MFA exceptions become permanent access exceptions. Fix: complete identity and access mapping before any policy is deployed.
VPN often provides implicit access to services no one has documented — legacy applications, file shares, printers, RDP paths, service accounts and protocol dependencies. When ZTNA replaces VPN without mapping these, legitimate access breaks. Fix: complete an application dependency map before pilot rollout.
A platform is purchased before access policy, identity readiness, support ownership or application scope is understood. The result is a technically deployed product that does not change the risk model. Fix: define the access architecture, identity prerequisites and operating model before platform selection.
Parallel running can be necessary during migration, but keeping VPN indefinitely undermines the control model — users and support teams revert to the legacy path when friction appears. Fix: define staged VPN decommission criteria before rollout begins.
Policy does not stay clean without ownership. Groups change, users move roles, new SaaS tools appear, contractors come and go. Without a defined owner for Conditional Access, ZTNA entitlements, CASB rules and exception review, drift begins quickly. Fix: assign policy ownership and review cadence as part of deployment scope.
What a staged SASE transition can look like.
As an illustration of the pattern rather than a specific engagement: a Microsoft 365-heavy, multi-site branch-operations group was running legacy VPN for remote users and branch-to-application access. Users reported Teams degradation on VPN, and contractors had network-level access to systems they had no business reason to reach. The identity review found 34 stale accounts, inconsistent MFA enforcement and multiple contractor accounts with broad access.
The transition started with identity cleanup and application dependency mapping before any ZTNA policy was deployed. A controlled pilot validated access to key applications while the legacy VPN remained available; ZTNA and Secure Web Gateway policies were then rolled out progressively by user group. The VPN was decommissioned only after each group was validated against the new access model. That is the difference between deploying a SASE product and sequencing an access transition.
SASE is not a product decision. It is an operating-model decision about trust.
The most common mistake is treating SASE as a replacement for VPN rather than a redesign of access. VPN asks whether a user can reach the network. SASE asks whether this user, on this device, in this context, should access this application now — and that difference is the whole point. For Australian organisations the best architecture usually follows one of three paths, and the right one depends on the existing identity stack, edge architecture, data-residency position and operating model:
- Microsoft-led — where Entra ID, Microsoft 365 and Conditional Access are already the control plane
- Fortinet-led — where Fortinet SD-WAN and FortiGate already form the network and security edge
- Combined — where Microsoft handles identity-led access and SaaS visibility while Fortinet handles branch edge and SD-WAN
Inlight IT helps Australian organisations assess, design and transition SASE architecture across Microsoft, Fortinet and combined environments — usually starting with current access architecture, identity readiness, application dependencies, VPN usage, data-residency requirements and Essential Eight alignment. The recommendation follows the environment, not a default vendor preference: platform fit, sovereignty and management-plane requirements are designed in rather than retrofitted under audit pressure, deployment is sequenced as a defined engagement, and access policy, exception review, logging and evidence continue after deployment with named ownership.
The discipline is not technical. It is sequencing identity, applications and ownership before platform.
Sequencing beats platform choice: the deployments that stall are the ones that bought the stack before mapping identity and applications.
Sequence it first →Questions that come up before a SASE deployment.
What are the five pillars of SASE?
How long does a SASE deployment take?
What is the difference between Microsoft Entra SSE and Fortinet FortiSASE?
Does SASE keep Australian data in Australia?
How does SASE support Essential Eight compliance?
Can SASE be deployed without SD-WAN?
What is the difference between SSE and SASE?
Should we choose single-vendor SASE or a combined architecture?
Does SASE require replacing our existing identity platform?
Will SASE disrupt users during migration?
What evidence does SASE provide for auditors and insurers?
Start with the identity estate, not the platform shortlist.
A practical conversation about remote-access architecture, Microsoft Entra ID readiness, VPN transition, SASE platform fit, Australian sovereignty and deployment sequencing, so the access model is designed before a platform is chosen.
Discuss SASE and Zero Trust