SASE and Zero Trust: your workforce no longer operates inside a perimeter. Your security still assumes that it does.
VPNs, perimeter firewalls and fragmented point products were not designed for a workforce using Microsoft 365, SaaS platforms, AI tools and unmanaged networks from everywhere. A user authenticates once, then has broad access to a network segment. A web filter only protects traffic that passes through the office. Contractors get more access than the work requires. The controls exist. They do not behave as one policy engine.
SASE replaces location-based trust with identity-led, cloud-delivered control that follows the user, not the office. For many Australian organisations already standardised on Microsoft 365, that architecture can run through Microsoft Entra Internet Access and Private Access, with traffic inspected through Australian points of presence where the design supports it. Inlight IT designs and sequences these transitions, starting with identity readiness, application dependencies and the sequence, not the platform.
The situations that move SASE from roadmap item to active decision
SASE rarely becomes the conversation because someone read a vendor whitepaper. It becomes the conversation because a specific pressure has made the legacy access stack feel indefensible: an insurer asks for evidence the environment cannot produce, a contractor incident exposes broad VPN access, an AI tool moves sensitive data through a channel no one is inspecting, or Essential Eight surfaces a control gap the perimeter model cannot close.
flat network
verified access
SASE is not one product. It is one policy engine across access, inspection and identity
Most legacy access stacks contain controls that are individually useful: VPN for remote access, firewall policy for site-based control, web filtering at the perimeter, endpoint protection on devices, identity policy in Microsoft Entra ID, separate controls for SaaS and cloud applications, separate logging paths. Each control may work as intended on its own. The weakness is that they do not behave as one policy engine.
SASE changes the architecture by making identity, device posture, access policy, web inspection and application access part of one enforcement model. The user authenticates once. Policy follows the user, device and session regardless of location. Internet, application and SaaS traffic is inspected close to the user rather than backhauled. Privileged access is scoped to specific applications rather than granting network reach.
Every layer answers to the same identity-led policy engine. For Microsoft-aligned environments, Entra Internet Access and Private Access provide the top layers; where Fortinet SD-WAN is already in place, the foundation may already exist.
Users access applications, not network segments
Zero Trust Network Access gives users access to the specific applications they are authorised to use, brokered through identity-led policy rather than network routing and firewall rules. Microsoft Entra Private Access delivers this for Microsoft-aligned environments. The outcome is reduced lateral movement risk, cleaner contractor access scoping and a defensible path away from broad VPN access.
Web policy follows the user, not the office
Secure Web Gateway inspects internet-bound traffic based on identity, device posture and policy, regardless of whether the user is in the office, remote or on an unmanaged network. Microsoft Entra Internet Access provides this capability for users connected through the Microsoft identity layer. The outcome is consistent web security for the entire workforce rather than a posture gap between office and remote staff.
Inspection at the cloud control plane, not the central datacentre
SASE extends firewall policy and threat inspection into the cloud control plane so internet traffic, SaaS access and remote application access can be inspected without forcing traffic back through a central office. Physical firewalls remain where they belong: at sites, branches and operational networks. Cloud-delivered inspection covers everything the perimeter never could.
A successful login is no longer enough
Access decisions consider identity, MFA status, device compliance, user risk, location, application sensitivity and session context. Conditional Access in Microsoft Entra is the policy engine that evaluates each of these signals at the point of use, not just at authentication. The architecture only delivers on this when the underlying identity signals are clean.
The most important SASE decision is not the vendor. It is whether the identity foundation is ready
Conditional Access, ZTNA and Secure Web Gateway policies are only as reliable as the users, groups, devices and applications they are applied to. Stale users, orphaned accounts, duplicate identities, shared accounts, legacy service accounts, MFA exceptions, unmanaged endpoints, overbroad administrator roles, contractor identities that should have been disabled six months ago, and application access groups that no longer reflect the business, all of these silently weaken the policy engine that SASE depends on.
Before SASE policies are written, the identity estate needs to be understood and remediated. None of this is glamorous. All of it determines whether the SASE deployment that follows will deliver what it promises or inherit the same trust gaps that made VPN risky in the first place.
Data residency needs to be designed, not assumed
For Australian organisations, the design needs to confirm where traffic is inspected, where logs are stored, who has access to management data and whether the chosen platform supports local points of presence for the users and applications in scope. Microsoft Entra Internet Access and Private Access can operate through Australian points of presence, including Sydney.
For organisations with data residency requirements under the Privacy Act, APP 8 or government-aligned policy settings, the SASE design should document precisely where traffic is processed, where management infrastructure sits, where logs are retained and who has administrative access to that data.
Discover, clean, pilot, deploy. In that order
The SASE transition should be sequenced. Moving too quickly to platform deployment creates avoidable access failures, user disruption and security exceptions that the organisation then has to unpick later.
Discover: map every dependency and user group
Every user group, application, VPN tunnel, legacy access rule, contractor connection, privileged path and protocol constraint is catalogued before any change is made. Cloud and on-premises applications, remote access patterns, SaaS and AI tool usage, internet-bound traffic controls and legacy applications that may need exceptions are all captured at this stage.
The dependency map is the design input that ZTNA platforms cannot generate themselves.
Clean: identity cleanup before any policy is written
Stale groups, orphaned accounts, duplicate identities, MFA exceptions, Conditional Access gaps, device compliance baseline, privileged access groups, service account posture and third-party identities are resolved before Conditional Access and ZTNA policies are deployed. Policies applied to a messy identity estate miss targets and create unintended gaps.
This is the step many ZTNA deployments skip and later regret.
Pilot: ZTNA and SWG validated with a controlled group
ZTNA policies and Secure Web Gateway rules are deployed to a controlled user segment while the legacy VPN remains operational. Application access, performance, identity policy, device compliance, logging and support workflows are validated under production conditions.
Issues are resolved here, not during the main deployment.
Deploy: progressive rollout, legacy decommissioned last
Validated policies roll out progressively across the full user population. The legacy VPN and web filter remain operational until the new environment is confirmed working for every user group. Architecture documentation, monitoring, support handover and evidence capture happen as part of deployment, not as a separate project afterwards.
The legacy VPN is decommissioned only after the new environment is confirmed working.
SASE materially supports Essential Eight when it is implemented properly
SASE does not make an organisation Essential Eight compliant on its own. It can, however, strengthen access control, privileged access, application control and logging when the identity foundation is clean and the implementation is properly operated.
What changes when access is designed properly
Access transitions, evidenced
SASE designed around identity, network paths and the way users actually work
SASE is not just a security product. It changes routing, identity, remote access, user experience, application delivery, logging and support. Inlight IT approaches SASE as an engineering and operating model decision, not a vendor selection exercise.
01Identity-first architecture
SASE starts with identity, not appliances. Microsoft Entra ID, Conditional Access, MFA coverage, device compliance and group hygiene are assessed before ZTNA or Secure Web Gateway policy is deployed. The goal is to prevent the SASE environment from inheriting the same trust issues that made VPN risky.
02Network and access architecture together
SASE changes how users reach applications and the internet. The work includes application dependency mapping, underlay quality, DNS, routing, branch access, remote access, SaaS traffic and user experience, not only security policy.
03Microsoft Entra and Fortinet awareness
Many Australian organisations already run Microsoft 365 and Entra ID. Others already operate Fortinet SD-WAN and FortiGate infrastructure. SASE architecture accounts for both the identity platform and the network and security estate already in place. The recommendation follows the environment, not a predetermined vendor preference.
04Australian data residency by design
PoP location, traffic inspection point, log retention and management infrastructure are designed against Australian residency requirements from the start, not retrofitted under audit pressure.
05Practical transition, not big-bang replacement
VPN and legacy controls usually remain in place during the transition. SASE is piloted, validated and expanded progressively. The goal is to reduce risk without disrupting access to the applications users rely on.
Recent SASE and Zero Trust work
Questions that come up before a SASE conversation starts
What happens in a SASE and Zero Trust scoping conversation?
A scoped review of the current access model: VPN architecture, web filtering, Microsoft Entra ID posture, Conditional Access coverage, device compliance, application dependencies, contractor access, SaaS and AI tool exposure, and data residency requirements. The output is a clearer view of identity readiness, a sequenced migration path and whether the platform fit is Microsoft Entra Internet Access and Private Access, a vendor SASE platform, or a phased combination. It is not a vendor presentation.
What is SASE and how is it different from a VPN?
SASE, Secure Access Service Edge, converges network connectivity and security into a cloud-delivered architecture. A VPN creates an encrypted tunnel that grants broad access to a network segment. SASE replaces that model with Zero Trust Network Access: users authenticate with MFA and device compliance checks, then access only the specific applications they are authorised to use. Traffic is inspected at cloud points of presence close to the user rather than being backhauled through a central datacentre.
Why is identity infrastructure cleaned before SASE policies are deployed?
Conditional Access and Zero Trust policies are only as reliable as the identity estate they are applied to. Stale groups, orphaned accounts, MFA exceptions and duplicate identities mean policies miss targets and create unintended gaps. Identity cleanup before policy design is the difference between ZTNA that delivers its security promise and ZTNA that inherits the same trust problems VPN had.
Does SASE keep Australian data in Australia?
It can, but it depends on the platform, tenant configuration, points of presence, log retention and management access model. Microsoft Entra Internet Access and Private Access can operate through Australian points of presence, including Sydney. Traffic inspection should be designed to occur at Australian PoPs where the architecture supports it, with the design documenting where traffic is processed, where logs are retained and where management infrastructure is hosted. For organisations with requirements under the Privacy Act, APP 8 or government-aligned policy settings, this should be captured as part of the architecture record.
Can we migrate from VPN to SASE without disrupting operations?
Yes, when the migration is staged. SASE runs alongside the existing VPN during the transition. The work begins with dependency mapping. ZTNA policies are piloted with a controlled user segment, validated against the existing access model, and then progressively rolled out by user group. The legacy VPN is decommissioned only after the new environment is fully validated.
How is SASE different from SD-WAN, and do we need both?
SD-WAN solves the network connectivity problem: intelligent routing across multiple WAN links with application awareness. SASE solves the security problem for distributed users and cloud access: identity-based access control, traffic inspection and threat prevention delivered from the cloud. SASE includes SD-WAN as its networking foundation where branch connectivity is in scope. If SD-WAN is already in place, the SASE foundation may already exist. What SASE adds is the identity-first access and inspection layer that legacy VPN and web filtering cannot provide.
Is Microsoft Entra SASE enough on its own?
For organisations already invested in Microsoft 365 and Entra ID, Microsoft Entra Internet Access and Private Access can cover important SASE and Security Service Edge requirements: identity-led internet access, private application access, Conditional Access integration and consistent access policy. But Microsoft Entra SASE does not replace every security control. It does not remove the need for endpoint protection, email security, backup, recovery, vulnerability management, patch governance or security monitoring. The right answer depends on the identity estate, endpoint posture, application architecture, Fortinet or firewall footprint, and the level of inspection and operational control required.
What are the main risks of a SASE deployment?
Three practical risks. First, SASE depends on internet and cloud service availability: if the underlay is weak, user experience suffers even if the security architecture is sound. Second, migration complexity is real: application dependencies, legacy authentication, DNS, certificates, user groups and exceptions must be mapped before rollout. Third, vendor lock-in can increase if the platform is chosen before the architecture is understood. These risks are managed by methodology, not avoided by limiting scope.