SASE and Zero Trust for Australian Enterprises

By Stu Long, CTO, Orro

For a long time, network security had a shape. There was an inside and an outside, a firewall between them, and a set of rules that treated anything on the inside as broadly trustworthy. It was a sensible model for the network it was built to protect. That network no longer exists.

The perimeter did not fail in a single event. It eroded. Applications moved to Azure, AWS and Google Cloud, and into SaaS platforms that nobody inside the business runs. Workforces spread across home offices, regional sites and field operations. Supply chains opened permanent connections for vendors, integrators and maintenance contractors into environments that were once closed. Each of those changes made sense on its own. Together, they removed the assumption the whole model rested on: that where a connection comes from tells you whether it can be trusted.

Most large Australian organisations now run security architectures designed for the network they used to have, not the one they actually operate. The gap is usually managed reactively. Another VPN concentrator, another exception in the firewall rulebase, another point tool added after an incident. SASE and Zero Trust are the architectural response to that drift, but neither is something you can buy, and treating them as a purchase is one of the most common reasons these programmes stall.

Location stopped being a proxy for trust

The data on where Australian organisations sit is sobering. Cisco’s 2025 Cybersecurity Readiness Index found that only 3 per cent of Australian organisations have reached a mature level of readiness (Cisco, 2025). The same study found that 82 per cent of Australian organisations face increased security risk because employees connect to the network from unmanaged devices (Cisco, 2025).

That second figure is the one I would put in front of a board. It describes, in a single number, how far the old model has drifted from reality. A device the organisation does not own, on a network it does not control, is reaching applications that no longer sit in its data centre. There is no perimeter left to defend in that transaction.

Australia’s own guidance has moved accordingly. In its advice to senior decision-makers, ASD’s Australian Cyber Security Centre says organisations need to move beyond fixed perimeter-based security towards an approach centred on identities, devices and data, with continuous authentication and authorisation of every user, device and application regardless of location (ASD’s ACSC, 2025). This is not a forecast about where security is heading. It is a description of the problem most organisations are already carrying.

Zero Trust is a posture, not a product

“Never trust, always verify” has been printed on enough booth banners that it risks losing its meaning. It is worth restating plainly, because the idea underneath it is simple and genuinely useful for anyone who has to fund, govern or explain a security programme.

ASD frames Zero Trust around three principles: never trust, always verify; assume breach; and verify explicitly (ASD’s ACSC, 2025). In operational terms, that translates into three habits.

The first is continuous verification. Identity is checked every time access is requested, not once at the start of the day. The check can take in context too: whether the device is healthy and patched, whether the location or behaviour looks normal, whether the request fits the person’s role.

The second is least privilege. A user is granted access to the specific application they need, not to the network that application happens to sit on. A finance analyst reaching the ERP system has no business seeing the engineering file share, and in a Zero Trust design the network never offers them the route.

The third is assuming breach. The architecture is designed on the expectation that something, somewhere, will eventually be compromised. The question becomes how far an attacker can move from there, and the answer should be: not far.

None of these is a feature you switch on. ASD is direct on this point, noting that a modern defensible architecture cannot be bought off the shelf as a single product, service or toolset, and that for most organisations it is likely to be a generational effort across multiple projects (ASD’s ACSC, 2025). Zero Trust is not a certification either. There is no day on which an organisation “achieves” it. It is a posture that you move towards, measure, and keep adjusting as the environment changes.

SASE is a convergence, not a platform

If Zero Trust is the principle, SASE (Secure Access Service Edge) is the architecture that makes it practical for a distributed organisation. It brings together capabilities that most enterprises have historically bought, run and managed separately. SD-WAN handles how sites and users connect and how traffic is prioritised. A Secure Web Gateway inspects and controls access to the internet. A Cloud Access Security Broker governs how staff use SaaS applications and the data inside them. Zero Trust Network Access replaces broad VPN access with per-application, identity-checked connections. Delivered together as a cloud-native service, they allow one set of policies to follow the user and the application wherever each happens to be.

The operational case for that convergence is stronger than the technical one. When these capabilities live in separate tools, each has its own console, its own policy language and its own blind spots, and the gaps between them are exactly where problems go unnoticed. In Cisco’s Australian research, more than 76 per cent of organisations said complex security infrastructure built on more than ten point solutions was impeding their ability to respond quickly and effectively to threats (Cisco, 2025). Consolidating capabilities gives you consistent enforcement regardless of where the user or application sits, fewer handoffs between teams and tools, and a single view of what is actually happening across the environment.

The market is moving in that direction. Gartner forecasts that by 2028, 70 per cent of SD-WAN purchases will be part of a single-vendor SASE offering, up from 25 per cent in 2025 (Gartner, cited in SDxCentral, 2025). Yet the estates organisations actually run tell a more mixed story. Omdia research found that 58 per cent of organisations expect to use three or more vendors in their SASE environment once their initiative is complete (Omdia, cited in TechTarget, 2025).

Both of those things are true at once, and that is the point. Consolidation is the direction of travel, but SASE is not defined by how many logos sit in the stack. It is defined by whether identity, policy and visibility are consistent across whatever components are in place. At Orro we build these architectures with partners including Fortinet and Cisco, and the design question is the same either way: whether one policy decision can be enforced identically at the branch, in the cloud and on a laptop in a regional motel room.

Third-party and unmanaged-device access is where that question gets hardest, and where the Cisco figure above bites. Network controls alone struggle when the device belongs to a contractor. A managed secure browser, such as Island’s, applies Zero Trust access and data controls inside the browser session itself, so the controls travel with the session rather than depending on the device. It is one control among several, but it closes a gap that traditional network architecture was never designed to reach. The early evidence is encouraging: a Forrester Consulting study commissioned by Island modelled an organisation of 5,000 staff, including 500 contractors, and found security risk reduced by up to 90 per cent and access control changes made 50 per cent faster (Forrester Consulting for Island, 2026).

The Australian reality: hybrid, legacy and regulated

None of this happens on a greenfield site. Large Australian organisations typically run workloads across Azure, AWS and Google Cloud, alongside on-premise systems that cannot simply be moved or replaced, and in mining, utilities and transport, alongside operational technology that was never designed to be networked at all. Zero Trust architecture has to work with all of that, not replace it overnight. ASD makes the same point, advising that organisations continue hardening and protecting existing systems in parallel with implementing modern defensible architecture (ASD’s ACSC, 2025).

Operational technology is where Zero Trust looks most different. You cannot install an agent on a thirty-year-old controller, and you cannot take a production line down for a quarter to re-architect its network. In OT, Zero Trust mostly means segmentation, tightly controlled remote access and passive visibility of what is actually talking to what. The evidence that this works is starting to show. Fortinet’s 2026 State of Operational Technology and Cybersecurity Report found that the share of organisations reporting intrusions affecting both IT and OT systems fell from 60 per cent in 2025 to 24 per cent, a drop the report links to better segmentation (Fortinet, 2026). The same research found that only 14 per cent of respondents have full visibility into their OT environments (Fortinet, 2026). Segmentation is also what makes assume breach workable in OT: it gives operators the option to contain a problem around the systems that matter, rather than disconnecting and stopping the operation.

Regulation is adding weight to all of this. For government, the Protective Security Policy Framework was updated in 2025 to include requirements to embed a zero trust culture (ASD’s ACSC, 2025), a shift explored for federal and state agencies in Orro’s recent piece on building government networks beyond legacy MPLS. For responsible entities of critical infrastructure assets under the SOCI Act, the Critical Infrastructure Risk Management Program requires them to manage cyber and other hazards and to comply with the cyber security framework identified in their program, with a board-approved annual report (Cyber and Infrastructure Security Centre, 2023). Demonstrable, auditable access control is increasingly what sits underneath those obligations, and proposed reforms would extend elements of them to third parties with practical control over an asset, as covered in Beyond the Responsible Entity: What SOCI’s ‘Relevant Operator’ Concept Means for You.

Whether the SOCI Act applies to your organisation, and which obligations follow, depends on your specific assets and their classification, not on your industry alone. Confirm your position with your legal advisers before relying on any general guidance.

Where to start: the questions that set the sequence

The biggest challenge is rarely understanding the destination. It is knowing which decision comes first. Every organisation’s sequence will differ, but in my experience the most useful starting point is a small number of honest questions, asked in roughly this order.

The first is about identity. Can the organisation say, with confidence, who and what is requesting access to each critical system, and is that identity strongly verified every time? Zero Trust cannot be enforced without that foundation, and in most environments the identity picture is less complete than people assume: stale accounts, shared service credentials, contractors who left months ago and still have access.

The second is about devices. Does the organisation know the health of the devices connecting to its environment, and does that health actually influence what access is granted? A verified identity on a compromised laptop is still a compromised session.

The third is about applications. Is access granted to specific applications based on role and context, or does a successful login still hand users a route into the wider network? Replacing broad VPN access for a single high-risk group, third-party contractors being the usual candidate, is often the most practical first project, because the risk reduction is immediate and the scope is contained.

The fourth is about segmentation. If one system were compromised tomorrow, how far could an attacker move before something stopped them? In converged IT and OT environments especially, the answer to that question says more about real resilience than any maturity score.

Running underneath all four is visibility. You cannot write sound policy for traffic you cannot see, and you cannot verify controls you have no way to observe. That is why the practical work so often begins with understanding what is actually connected and what it is actually doing, before a single new control is designed.

The architecture follows the decisions

The organisations making real progress on this are not the ones that bought the most comprehensive platform. They are the ones that made a clear set of decisions about identity, access and segmentation, then chose and integrated technology to enforce those decisions consistently. The architecture follows the decisions, not the other way around.

Getting the human access model right also creates the foundation for what comes next. The same principles now need to extend to AI agents and other non-human identities, a challenge explored in Orro’s recent piece, Zero Trust Wasn’t Built for This: Securing the Rise of Non-Human Identities.

If your organisation knows it needs to move away from a perimeter model but is not sure where the first decision sits, that is a conversation worth having with Orro’s secure networking and SASE team. To see where your own organisation stands first, Orro’s NIST Cybersecurity Framework self-assessment benchmarks your current posture across identity, protection, detection and recovery.