SASE transition pressure rises as WAN and security converge

At a glance

What this is: EMA’s report looks at enterprise migration from SD-WAN to SASE and finds that the convergence of connectivity and security is forcing a major architectural and operating-model shift.

Why it matters: It matters because SASE adoption changes how teams govern access, service boundaries, and operational ownership across networking, security, and identity functions.

Context

SD-WAN to SASE migration is not just a product refresh. It is a control-plane and operating-model change in which network connectivity, security enforcement, and policy governance become harder to separate cleanly.

For identity and access teams, the relevance is indirect but real: SASE decisions influence how remote users, service traffic, and policy enforcement points are controlled across distributed environments. The article positions the shift as a broad architectural transition rather than a narrow networking tweak.

Key questions

Q: How should security teams choose between SASE and SD-WAN?

A: Choose SD-WAN when the primary problem is traffic engineering, branch connectivity, or WAN simplification. Choose SASE when the requirement includes security policy enforcement, Zero Trust access, and cloud-delivered inspection across distributed users and applications. In many enterprises, SD-WAN remains a transport layer while SASE becomes the control layer.

Q: When does SASE create more complexity than it removes?

A: SASE adds complexity when organisations adopt it without aligning service model, ownership, and enforcement boundaries. If the architecture centralises policy but leaves accountability fragmented, teams may inherit new control points without clearer decision rights, which can make change management and troubleshooting slower rather than simpler.

Q: What are the signs that WAN modernisation is failing?

A: Warning signs include inconsistent policy enforcement, unclear escalation paths, duplicated control ownership, and repeated debates over which team owns a change or incident. Those symptoms usually mean the organisation has modernised the stack faster than it has modernised governance.

Q: What is the difference between SASE and SD-WAN for access governance?

A: SASE combines networking and security into a cloud-delivered control model, while SD-WAN focuses on virtualizing and managing network paths. For governance, the difference is whether security decisions travel with the connection or remain separate from it.

Technical breakdown

Why SD-WAN and SASE are converging

SD-WAN optimises connectivity across sites and users, while SASE combines networking with security enforcement and policy at the edge. The architectural shift happens because enterprises no longer want separate, loosely coordinated controls for routing and protection. Instead, they need a model where access policy, traffic inspection, and service delivery are enforced together across distributed environments. That convergence changes governance, because the control owner is no longer only the network team. It also changes assurance, because policy outcomes depend on how multiple tools and teams cooperate.

Practical implication: Map ownership for policy enforcement across network, security, and identity teams before you migrate control boundaries.

How service models affect transition risk

A SASE transition is not only a technology choice but also a sourcing and operating-model decision. Managed, co-managed, and self-operated service models shift responsibility for policy design, change control, logging, and incident response. Those differences matter because a migration can fail even when the technical stack is sound if accountability is split or unclear. The report’s emphasis on vendor evaluation and service models reflects that the hard part is often governance of the operating model, not simply feature comparison.

Practical implication: Define who owns policy, telemetry, and escalation paths before selecting a service model.

Why identity governance sits inside network modernisation

SASE increasingly depends on contextual access decisions rather than static network trust. That means user identity, device posture, and application context become part of the access decision even when the article is framed as a networking report. For IAM teams, this matters because the transition can expose gaps between access policy design and enforcement points. A modern WAN architecture without clear identity inputs risks reproducing old perimeter assumptions in a new form.

Practical implication: Align access policy inputs with identity and device assurance signals before extending SASE control points.

NHI Mgmt Group analysis

SASE migration is really a governance redesign, not a topology upgrade. Enterprises often describe the move from SD-WAN to SASE as an architecture refresh, but the deeper change is who owns policy, enforcement, and exception handling. Once connectivity and security converge, the operating model becomes part of the control surface. Practitioners should treat the transition as an identity-and-access governance exercise that happens to use network tooling.

The hardest failure mode is fragmented accountability across network and security teams. The report’s focus on vendor evaluation and service models points to a recurring issue: organisations buy capability before clarifying decision rights. When logging, policy changes, and incident response are split across teams, the architecture becomes harder to trust. Practitioners should map ownership before migration, not after deployment.

Policy portability is the real architectural test. The value of SASE depends on whether enforcement remains consistent as users, devices, and traffic paths change. That makes the control model more important than the transport model. For readers running hybrid identity and access programmes, the question is whether policy follows the subject everywhere it connects, or only where the old perimeter still exists.

Identity signals now influence network trust decisions in ways traditional WANs did not. The article’s architectural frame shows why IAM and network teams can no longer work in separate design cycles. Contextual access, remote work, and distributed services all force identity inputs into what used to be a routing-only problem. The practical conclusion is that network modernisation now inherits identity governance debt if the two functions remain disconnected.

What this signals

Policy ownership will become the main migration risk. As enterprises move from connectivity-led WAN design to policy-led access enforcement, the control question shifts from throughput to governance. Teams that do not define who can change policy, who validates exceptions, and who owns logs will struggle to operationalise the transition.

Identity-aware network control is now part of the WAN baseline. Remote access, device posture, and application context are no longer separate concerns from transport design. Readers should expect SASE programmes to pull IAM and network operations into the same design conversation, especially where distributed work and hybrid access are already normal.

For practitioners

• Clarify policy ownership across teams Define which team owns access policy design, enforcement exceptions, and incident escalation before changing the WAN operating model.
• Assess service model accountability Compare managed, co-managed, and self-operated SASE models by who controls telemetry, configuration change, and response workflows.
• Align identity inputs to enforcement points Verify that identity, device posture, and application context are available where access decisions are enforced, not only in upstream systems.
• Standardise transition criteria Set measurable criteria for when an SD-WAN segment is ready to move into SASE, including policy consistency and logging coverage.

Key takeaways

• The report frames SD-WAN to SASE migration as an architectural and governance shift, not a simple platform replacement.
• The main operational challenge is coordinating policy ownership across networking, security, and service delivery teams.
• Identity signals and access decisions now influence WAN design, which means modernisation efforts need cross-domain governance from the start.

Key terms

• SASE: A cloud-delivered architecture that combines networking and security capabilities such as SD-WAN, SWG, CASB, FWaaS, and ZTNA. It centralises enforcement across distributed environments, but it does not replace identity governance or privilege design. The model is operationally broad, not a substitute for entitlement control.
• SD-WAN: Software-defined wide area network is a centrally managed approach to connecting users, sites, applications, and data across multiple links. It combines routing policy, visibility, and traffic optimization so organisations can steer traffic dynamically instead of relying on a single fixed path.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Service Model: A service model describes how a capability is delivered and who operates it, such as managed, co-managed, or self-operated. In SASE transitions, service model decisions affect responsibility for policy changes, logging, escalation, and recovery, not just technical feature fit.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need clearer control over access, lifecycle, and governance across modern security programmes.