I’m starting to think that SD-WAN might be the Trojan horse secure access service edge (SASE), or rather the cloud-delivered security part of it, needs in order to see widespread adoption.

SASE has gotten a lot of attention in recent months, propelled by the pandemic and hyped up by a flurry of high-profile, multi-million bordering on billion-dollar acquisitions. And the nascent product category has proven to be remarkably competent at addressing the needs of remote workers.

But at least in the near term, I think it's SD-WAN that’s going to get the rest of the SASE security stack in the door.

SASE encompasses a broad range of networking and security technologies, some more mature than others. This is especially true of SD-WAN, which has been around in some capacity for more than a decade.

A recent 650 Group report found SD-WAN and firewall-as-a-service (FWaaS) vendors would likely be the two largest drivers of SASE adoption. “Those are the two power bases from which most SASE growth and success are going to come from,” Chris DePuy said, in an earlier interview with SDxCentral.

I’d argue that for a lot of enterprises — really any company that has to connect more than a dozen branch offices — SD-WAN is a relatively easy sell compared to FWaaS, zero-trust network access (ZTNA), or cloud access security broker (CASB).

That’s not to say cloud-based security isn’t effective or even preferable. The shift to remote work turbocharged the SASE market and its ZTNA, SWG, and CASB — not SD-WAN — that most remote workers using SASE product today interact with on a daily basis.

Cisco is one of many vendors that has used its SD-WAN platform as a Trojan horse for its larger SASE offering. From the start, the company architected its SASE platform around its Viptela SD-WAN and Umbrella security products. Tight integration between the two platforms means enterprises can buy the SD-WAN they need and upgrade to a full-blown SASE architecture if and when they’re ready.

This buy SD-WAN now, get SASE later kind of approach means companies like Cisco can capture share from customers at any one phase of their “digital transformation.”

And since Cisco has a large existing SD-WAN install base — roughly 20,000 customers at last count — the company already has its foot in the door. All they need to do is convince an appreciable number of those customers to tick a box and subscribe.

Of course, this level of integration isn’t at all unique to Cisco, but I do believe that this strategy will ultimately benefit those that can offer a unified platform for networking and security.

That’s not to say Zscaler, Check Point, BitGlass, or Netskope can’t be successful partnering with SD-WAN vendors.

BitGlass recently announced SASE integrations with Cisco, Aryaka, Palo Alto Networks, Versa, Aruba, 128 Technology, Fortinet, and Silver Peak. So in theory, thanks to these integrations, the company should have a much larger potential customer base than any one SD-WAN company trying to convert existing customers to their SASE platform.

But with a solid chunk of these companies already developing SASE platforms of their own, the question has to be asked: why would a Fortinet or Veras SD-WAN customer choose to integrate with a third-party security platform when they can enable the same or similar functionality without having to make an additional investment in hardware or learn a new software platform.

Say what you will about walled gardens, putting all your eggs in one basket, or choice, the value of simplicity and convenience cannot be underestimated.

SD-WAN plays an important, but relatively limited role in a SASE architecture. SD-WAN overlays and appliances allow branch traffic to be routed over private links like MPLS or sent to the nearest SASE point of presence (PoP) for inspection.

This allows branches to connect to the corporate data center over private lines but route all other traffic through the SASE.

While I believe SD-WAN will be a critical driver of SASE adoption in the short term, I expect its importance as a distinct networking function will fade as more and eventually all traffic is routed through the SASE PoP.

SASE architectures will likely still need an appliance at the branch to aggregate traffic and for failover, but beyond this, I predict most of the routing intelligence will eventually migrate to the edge of the network.

SASE vendors VMware and CATO are already doing something along these lines by moving much of the routing functionality to the SASE PoP.

This won’t, however, happen overnight and will require a substantial expansion in the number of SASE PoPs to allow for more intelligent routing and lower latency. But as enterprises shift an increasing number of their workloads outside the corporate data center, and as trust in cloud-delivered security grows, I see the need for SD-WAN as we know it diminishing greatly.

So while SD-WAN will be critical for driving SASE adoption, I expect before long that routing will join the security stack in the cloud and at the edge.