SD-WAN vs SASE vs ZTNA for Industrial Sites: OT Connectivity and Remote Access Architecture

A refinery operator renews its MPLS contracts and gets three pitches in one week. One vendor sells SD-WAN to cut circuit costs. A second sells SASE as the platform that replaces the firewall at every site. A third sells ZTNA to fix the contractor VPN that an audit just flagged. All three decks use the same words, and all three claim to be zero trust. The operator’s real question is narrower: which of these belongs between a programmable logic controller and the internet, and which belongs nowhere near it?

The sd-wan vs sase debate is usually framed as a procurement choice. For industrial sites it is an architecture choice, because the three technologies solve different problems at different layers. SD-WAN moves packets between sites. SASE (Secure Access Service Edge) moves security inspection into cloud points of presence. ZTNA (Zero Trust Network Access) decides who may reach which application. Only some of that survives contact with a Purdue-model plant.

What this covers: how each technology works at the mechanism level, how they relate, where they fit IEC 62443 zones and conduits, how to design remote vendor access, the failure modes that bite in OT, a decision matrix by site type, and a phased migration path. It is vendor-neutral and uses no vendor prices.

Context and Background

Industrial wide-area networking has been through three eras. First came private circuits: MPLS or leased lines connecting plants to a data center, with a hub firewall doing all inspection. Second came site-to-site IPsec over the internet, cheaper but brittle, with one tunnel per pair of sites and hand-maintained routing. Third came software-defined WAN, which wraps the transport mix in a managed overlay with central policy.

The security story ran in parallel. Remote access began as modem pools, became client VPN concentrators, and by the 2020s was the weakest point of many OT estates. A VPN grants network-level reach: once the tunnel is up, the contractor’s laptop can usually scan the subnet it lands on. That is the opposite of least privilege.

Gartner coined the term SASE in 2019, describing a convergence of WAN capabilities with network security functions delivered from the cloud. The common component list is secure web gateway (SWG), cloud access security broker (CASB), firewall as a service (FWaaS), ZTNA, and SD-WAN. Analysts later split the security half out as Security Service Edge (SSE), meaning SASE without the SD-WAN. In June 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) published guidance on adopting SASE for federal agencies moving to TIC 3.0, per Infosecurity Magazine’s coverage. It is vendor-agnostic and architecture-focused, and it notes that SASE bundles networking and security into a single, mostly cloud-based service.

OT guidance has moved too. In late April 2026 a CISA-led multi-agency group released “Adapting Zero Trust Principles to Operational Technology,” which, according to Infosecurity Magazine, stresses passive asset inventory, segmentation to limit lateral movement, compensating controls where modern security cannot be deployed, and secured remote access via jump hosts with multifactor authentication. That last point matters for this article: the government’s own OT guidance does not say “put an agent on the PLC.” It says to broker access through hardened intermediaries.

For the underlying segmentation model, see our guides to zero trust architecture for industrial OT and IoT and to IEC 62443 zones and conduits. This article assumes you know why those matter and asks a more specific question: what do you buy to connect and protect the sites?

The thesis is this. SD-WAN, SASE, and ZTNA are not three rival products. They form a stack with a clear division of labor: SD-WAN is a transport optimizer, SSE is a policy enforcement location, and ZTNA is an access-brokering pattern. In OT, the transport and the brokering are valuable; the cloud inspection of control traffic mostly is not. The right answer is rarely “SASE everywhere.” It is usually “SD-WAN for the plant edge, ZTNA for people, and a local zone firewall for machines.”

Reference Architecture: How the Three Layers Fit Together

Direct answer: SD-WAN builds an encrypted overlay across multiple underlay links and steers traffic per application using measured path quality. SASE places security services such as SWG, CASB, FWaaS, and ZTNA in cloud points of presence that sites and users connect to. ZTNA brokers per-application sessions after verifying identity and device posture, instead of granting network access.

Figure 1: The layered view. The SD-WAN edge and remote users both reach a nearby SASE point of presence, where SWG, CASB, FWaaS, and the ZTNA broker apply policy. A site-side connector carries brokered sessions to a jump host rather than to the control network.

Figure 1 is the picture to hold in your head. The plant’s SD-WAN edge and any remote user agent both terminate at a point of presence (PoP). Inside the PoP, traffic is steered through inspection engines. Private application access flows through the ZTNA broker to a connector that sits at the site and dials outward. The key architectural property is that nothing inside the plant accepts inbound connections from the internet.

SD-WAN data plane and control plane

SD-WAN splits into a control plane and a data plane. The control plane is an orchestrator or controller, often cloud-hosted, that holds topology, policy, and keying material. The data plane is the set of edge appliances (physical or virtual) that forward traffic. Edges receive policy from the controller, establish encrypted overlay tunnels to peers or hubs, and keep forwarding on cached state if the controller becomes unreachable.

Figure 2: SD-WAN architecture at one plant. The edge builds one overlay tunnel per underlay, probes each for loss, latency, and jitter, and steers applications to a path that meets policy.

The overlay is typically IPsec or a vendor-specific encrypted tunnel, one per underlay link per peer. Underlay selection is the headline feature. Instead of binding a site to one carrier, the edge watches several links, for example fiber, broadband, and LTE or 5G, and picks per flow. Detection works by sending probes through each tunnel and computing loss, latency, and jitter over a sliding window. Policy defines a service level agreement (SLA) class per application, such as “loss under 1 percent and latency under 150 milliseconds for voice,” and the edge moves flows when a path breaches it.

Two mechanisms are worth understanding because they explain both the benefits and the OT risks. First, path steering is per flow, not per packet, in most implementations, because per-packet spraying reorders traffic and hurts TCP. Second, failover time is bounded by probe interval and detection thresholds. If probes run every second and three consecutive misses declare a path down, failover takes a few seconds. Faster is possible but trades against false positives from transient jitter. Those numbers are illustrative and configurable; check your platform’s documented defaults.

SD-WAN also does zero-touch provisioning, where a new edge phones home with a certificate, receives its configuration, and joins the fabric. For a company with 80 small substations, that turns a truck roll into a shipment. It also means a compromised orchestrator is a fleet-wide risk, which we return to in the failure modes section.

What SD-WAN is not

SD-WAN is not a security architecture. Most products include a stateful firewall and segmentation by virtual routing and forwarding (VRF) instance, and many integrate with SSE vendors, but the product’s core job is transport. It does not authenticate users to applications, does not inspect web or SaaS content in depth unless paired with an SSE service, and does not understand industrial protocols unless the vendor adds deep packet inspection for them. Treat SD-WAN as the road, not the checkpoint.

SASE architecture: the cloud PoP model

SASE architecture rests on one idea: instead of hauling all traffic to a central data center for inspection, enforce policy at the nearest of many distributed PoPs. A site’s edge or a user’s agent connects to the PoP, and the PoP chains services. A secure web gateway filters outbound web traffic and performs TLS inspection. A CASB governs SaaS use and data movement. FWaaS provides layer 3 to layer 7 firewalling for non-web flows. ZTNA provides private application access. Telemetry and policy are unified in one console.

Convergence has real benefits. One policy model replaces separate web proxy, VPN, and firewall estates. Latency to cloud applications improves because traffic exits near the user. Operations teams manage fewer boxes. The CISA guidance mentioned above also records the trade: when traffic no longer funnels through a few government gateways, central sensors lose visibility and telemetry must be re-plumbed to a log aggregation service. The same lesson applies to a plant: when inspection moves to a PoP, your OT security monitoring must follow it.

Single-vendor SASE and multi-vendor SASE are both offered. Single-vendor integrates SD-WAN and SSE under one management plane. Multi-vendor pairs a best-of-breed SD-WAN with a separate SSE service, joined by tunnels. In OT the integration question matters less than a different one: can the same policy model express “this contractor may open one HMI session on one host between 02:00 and 04:00,” and can it do so without anything on the control network accepting an inbound connection?

ZTNA in one paragraph

ZTNA replaces network-level trust with per-application trust. The user authenticates against an identity provider, the broker evaluates identity, device posture, and context, and, if allowed, stitches a session to exactly one application. The application is never exposed on a routable address. Traditional ZTNA is called “agent-based” when a client on the endpoint enforces posture and builds the tunnel, and “agentless” or “clientless” when the broker proxies the session through a browser. The following sections dig into both models and their OT fit.

Deeper Analysis: Fitting the Stack to a Purdue-Model Plant

The Purdue model organizes an industrial site into levels: physical process at Level 0, sensors and actuators and controllers at Levels 0 to 2, site operations at Level 3, a demilitarized zone (often called Level 3.5) between operations and enterprise IT, and enterprise networks at Levels 4 and 5. IEC 62443 turns this into zones, groups of assets with common security requirements, and conduits, the controlled communication paths between zones. A conduit is where you put a firewall, a data diode, a protocol break, or a brokered gateway.

The practical rule: SD-WAN, SASE, and ZTNA all live at or above the Level 3.5 boundary. None of them belongs in the cell and area zones where PLCs, drives, and safety instrumented systems exchange deterministic traffic. That sounds obvious until a salesperson proposes an SD-WAN edge “at every machine line.”

Mapping each technology to zones and conduits

The SD-WAN edge is a conduit device between the site and the outside world. Its natural home is the Level 3.5 DMZ or the enterprise-facing edge, terminating overlay tunnels for historian replication, patch distribution, telemetry to cloud analytics, and corporate IT traffic. It should not carry real-time control traffic between sites unless you have designed for it, because the WAN is a best-effort path whatever the SLA steering promises.

The SASE PoP is not in any plant zone at all; it is an external service. Under a strict reading of 62443, anything it provides for the site is part of a conduit you must risk-assess: the cloud tenant, the PoP operator, and the keys all become part of your trusted computing base for that conduit. This is the core cautionary point. Cloud inspection is acceptable for IT-bound web traffic and for brokered human sessions. For machine-to-machine OT traffic, the inspection benefit is small and the dependency cost is large.

The ZTNA broker is an access conduit for humans (and occasionally for automation). It fits the 62443 notion of a “remote access conduit” with strong authentication, authorization per target, and logging. The connector, installed at Level 3.5 or in a dedicated remote-access zone, dials outbound to the broker. That means the plant firewall can drop all inbound connections and still support access, a property that directly reduces attack surface. For deeper treatment of zone design see our IEC 62443 zones and conduits guide.

Latency-sensitive and legacy protocols

Industrial protocols differ sharply in what they tolerate. Modbus TCP, OPC UA client-server sessions, and DNP3 over IP generally tolerate tens to hundreds of milliseconds, because they are polling or event-driven with application timeouts measured in seconds. PROFINET RT, EtherNet/IP implicit I/O, and EtherCAT cyclic traffic are different: cycle times are in the low milliseconds or below, many run directly on layer 2 or multicast, and they assume a local switched network. Time-sensitive networking and IEEE 1588 precision time depend on tightly controlled hop-by-hop delay.

Three consequences follow. Layer 2 protocols cannot cross an L3 overlay without encapsulation tricks that you should avoid for control traffic. Anything with a cyclic watchdog should stay inside one site’s fabric. And the overlay adds encapsulation overhead, typically tens of bytes per packet for IPsec in tunnel mode (the exact figure depends on cipher and mode), which can push a full-size frame past the path maximum transmission unit (MTU) and trigger fragmentation. Always set the tunnel MSS clamp deliberately.

A useful worked illustration, with explicitly illustrative numbers: suppose an OPC UA subscription publishes every 500 ms with a keep-alive of three missed publishes, so the session tolerates roughly 1.5 seconds of silence. An SD-WAN with one-second probes and three-miss detection fails over in about three seconds. That is longer than the OPC UA tolerance, so the subscription times out and reconnects. Raising the probe rate to 200 ms with three misses detects in about 0.6 seconds, inside the tolerance, but at the cost of five times the probe traffic and more false failovers on noisy LTE links. The point is not the numbers; it is that you must derive the steering policy from the slowest application timeout, not accept defaults.

ZTNA agent versus agentless, brokered versus direct

Figure 3: Brokered vendor access. The engineer authenticates with MFA, the broker checks device and time window, the site connector opens an outbound-initiated session to a jump host, and the engineering workstation exposes only a screen stream.

ZTNA products fall on two axes, and OT forces different answers than IT.

Agent-based versus agentless. Agent-based ZTNA installs software on the user’s device. It can check posture (disk encryption, patch level, endpoint protection), bind sessions to the device, and carry arbitrary TCP and UDP. Agentless ZTNA proxies web, SSH, and RDP through a browser portal with no install. For vendor engineers using their own corporate laptops, an agent is often impossible: you cannot require a third party to install your agent on a managed device, and a contractor working for six customers will not accept six agents. Agentless access therefore dominates for third parties, accepting weaker posture assurance in exchange for deployability. For your own staff, agent-based is stronger.

Neither model fits the OT devices themselves. PLCs, RTUs, and protection relays cannot run an agent. Any ZTNA design for OT must therefore terminate at an intermediary: a jump host, a remote desktop gateway, or an engineering workstation, reached through the connector.

Brokered versus direct. In brokered models, all traffic passes through the vendor’s cloud broker. In direct or peer-to-peer models, the broker only coordinates, and endpoints connect directly after authorization. Brokered is easier to audit and works through any firewall, but it puts the broker in the data path, adding latency and a dependency. Direct reduces latency and the vendor’s visibility into payload, but requires NAT traversal and sometimes opens paths that OT teams dislike. For plants, brokered with an outbound-only connector is the safer default; direct is rarely worth the audit complexity.

A third variant deserves a mention: microsegmentation and overlay-based zero trust where identity-based policy is enforced at connectors near the asset. These tools are closer to ZTNA than to SD-WAN in intent, and some are designed with OT in mind, with passive discovery and protocol awareness. Evaluate them on whether they can enforce at Level 2 and 3 without inline latency.

Remote vendor access: a worked flow

Industrial remote access is the use case where ZTNA earns its place. Consider a drive manufacturer’s engineer who must diagnose a variable-frequency drive at 03:00. The traditional path is a VPN into the plant, then RDP to an engineering workstation, then the vendor’s tool to the drive. Every hop is trusted, nothing is time-limited, and when the engineer leaves the company the account often lives on.

The brokered flow in Figure 3 changes four things. Authorization becomes just-in-time: the plant approves a window and a target host, ideally with a second approver for safety-relevant systems. The engineer reaches one application, not a subnet. The session passes through a recording proxy that captures keystrokes or screen video for the audit trail, which supports IEC 62443-2-1 style evidence and incident forensics. And the connector initiates outbound, so no inbound firewall rule exists to attack.

Compare this with the CISA recommendation for jump hosts and MFA: it is the same pattern, productized. The jump host remains essential, because it is the place where file transfer is controlled, where the vendor tool runs on a hardened and patched machine, and where the last hop to the PLC network is made by a trusted host rather than by the contractor’s laptop.

Where SSE and FWaaS help OT, and where they do not

SSE services give real value to the IT side of an industrial company: secure web access for the 300 engineers in headquarters, SaaS governance, and data loss prevention for cloud storage. They help OT where OT touches the internet: patch downloads, vendor cloud portals, and remote-support callbacks. A site that today lets any workstation browse out can restrict egress to an approved SWG path with category policy and logging.

They help much less for east-west industrial traffic. Cloud FWaaS rarely understands Modbus function codes, OPC UA node-level access, or S7 write operations at the depth of a local industrial firewall, and routing machine traffic through a PoP adds latency and a failure domain for no security gain. Keep industrial deep packet inspection local, at the conduit, and send only logs to the cloud.

Capacity and sizing, illustratively

Sizing is where architectures hit reality. A typical mid-size plant with historian replication, camera feeds from the perimeter, corporate IT, and occasional vendor sessions might produce a few hundred megabits peak. Encrypted overlay throughput on an edge appliance is a vendor-published figure that usually assumes large packets and specific cipher suites; real mixes of small packets reduce it. Always validate by testing with your own traffic mix, and size for the peak with one underlay failed, since the whole point of multiple links is surviving one. If your LTE backup is 20 Mbps, it cannot carry the camera feeds, so policy must shed low-priority traffic during failover rather than let it starve the historian.

The same logic applies to a ZTNA broker: remote desktop to an engineering workstation consumes modest bandwidth, but file transfers of project backups, which can be hundreds of megabytes, deserve a throttle and virus scan at the jump host.

Decision Matrix by Site Type

Figure 4: A first-pass decision tree. Latency-critical control traffic stays local; multi-site, multi-link estates justify SD-WAN with SSE; small sites may need only brokered ZTNA for remote access.

Figure 4 is a first filter, not a verdict. The table below turns it into a decision matrix across common industrial site types. “Core” means the technology is central to the design, “Add” means it supplements, and “Avoid” means it is a poor fit for that traffic.

Site type	SD-WAN	SSE / SASE inspection	ZTNA for people	Local zone firewall	Notes
Large plant with DCS, 24×7	Add (L3.5 edge only)	Add (IT web only)	Core	Core	Keep control traffic off the WAN; jump host mandatory
Mid-size discrete factory, 3 to 10 sites	Core	Add	Core	Core	Good SD-WAN case: ERP, MES, historian replication across links
Remote unmanned site (pump station, wellhead)	Core if multi-link (LTE plus satellite)	Avoid for telemetry	Add	Core (small)	Low bandwidth, intermittent links; local autonomy first
Retail-style small branch with minimal OT	Core	Core	Core	Light	Closest to classic SASE use; OT is a thin slice
Utility substation (protection, SCADA)	Add, carefully	Avoid for protocol traffic	Add via gateway	Core	Regulated; prefer dedicated, deterministic links
Hospital or building with BMS and IoT	Core	Core	Core	Core	Mixed IT/OT; segmentation of IoT is the main win
Contractor-only access to a single machine	Not needed	Not needed	Core	Existing	A ZTNA-only deployment is a legitimate answer

Three patterns emerge. First, ZTNA for people is “Core” in nearly every row, which tells you where to start. Second, SSE inspection is rarely core for the control side; it earns its place where traffic is web or SaaS. Third, the local zone firewall never goes away. The cloud adds services; it does not remove the need for a conduit device at the zone boundary.

Comparing the three on the dimensions that matter

Dimension	SD-WAN	SASE (full)	ZTNA
Primary job	Transport, path steering	Converged networking and security from PoPs	Per-application access brokering
Trust model	Network membership in an overlay	Identity and policy at the PoP	Identity, device, context per session
Handles OT protocols	Transports them, no understanding	Limited deep visibility	Brokers RDP, SSH, web; protocols only via a gateway
Inbound exposure at the site	Edge may accept tunnels	Outbound to PoP	Outbound connector only
Dependency introduced	Controller and carriers	Cloud tenant and PoP	Broker and identity provider
Typical failure effect	Site isolation or flapping	Loss of inspection or access	Loss of remote access only

That last row is the argument for starting with ZTNA. If the broker fails, you lose remote access, and the plant keeps running. If an SD-WAN controller misbehaves or a PoP outage blocks your inspected path, the damage can reach production-adjacent traffic.

Trade-offs, Gotchas, and What Goes Wrong

Cloud dependency in an availability-first environment. OT prioritizes availability and safety over confidentiality, the reverse of IT’s usual ordering. A design that makes the plant’s operating state depend on a SaaS control plane or PoP reachability inverts that priority. Test the “internet is gone” case explicitly: SD-WAN edges should forward on cached state, local DNS and time must not depend on cloud services, and operators must retain local access to every HMI. The CISA OT guidance’s emphasis on resilience rather than perfect risk elimination points the same way.

Orchestrator compromise as a fleet event. Zero-touch provisioning and central policy mean one stolen administrator credential or one vulnerability in the controller can push a bad configuration, or open a path, across every site. Mitigate with strong MFA and role separation on the controller, staged rollouts (canary sites first), configuration change approval, and a break-glass local management path that is not on the overlay. Treat the controller like the safety-critical asset it effectively is.

TLS inspection and certificate pitfalls. SWG-style break-and-inspect breaks certificate pinning in vendor tools, firmware update clients, and many industrial apps. The CISA SASE guidance, per the coverage above, even points away from universal decryption toward pattern analysis of encrypted traffic. For OT egress, use allowlisted destinations and bypass inspection for known vendor endpoints rather than blanket decryption.

Asymmetric routing and failover flaps. With multiple underlays and stateful firewalls in the path, return traffic taking a different link than the request can be dropped. Flapping between paths on marginal LTE links produces session resets that look like application bugs. Use hysteresis (require sustained recovery before moving back), pin latency-intolerant flows, and monitor flap counts as a first-class metric.

Time and identity dependencies. Certificates and tokens rely on accurate time. An OT site whose time source is wrong, or whose identity provider is unreachable, cannot start new ZTNA sessions. Decide beforehand whether emergency access uses a cached credential, a local account in a vault, or a phone-approved break-glass flow, and rehearse it.

Shadow remote access. Even the best ZTNA design fails if vendors keep their own cellular modems or remote-support tools running on machines. Passive discovery and network monitoring, which the CISA guidance recommends for asset inventory, is how you find them. The policy answer is contractual: no vendor access paths outside the brokered one.

Compliance mapping is not automatic. Deploying ZTNA does not make a site conformant with IEC 62443, NIS2, or the EU Cyber Resilience Act. Those frameworks ask for risk assessment, zoning, evidence, and vulnerability handling. Our comparison of the EU CRA, NIS2, and IEC 62443 shows how obligations land on operators versus vendors, and how a brokered remote-access design produces useful evidence for several of them.

Over-trusting vendor claims. “Zero trust” is a marketing label. Ask each vendor concrete questions: Does anything at the site accept inbound connections? What happens to existing sessions when the broker is unreachable? Where are session recordings stored, and who holds the keys? Which OT protocols are parsed, and to what depth? Vendor-supplied throughput and failover numbers should be treated as lab figures until you reproduce them.

Migration Path: A Phased Approach

A migration that starts with SD-WAN everywhere tends to stall, because the benefits are diffuse and the risks are immediate. A better sequence follows the risk.

Phase 0: Inventory and zoning (4 to 8 weeks, illustrative). Passively discover assets, document existing remote access paths, and draft zones and conduits. Without this, every later step is guesswork. Record which vendors have access and by what mechanism.

Phase 1: Replace the contractor VPN with brokered ZTNA. Deploy a connector in the DMZ or remote-access zone, front it with a jump host, enforce MFA, time-boxed approval, and session recording, then close the inbound VPN ports. This delivers the largest risk reduction per dollar and touches no production traffic. Start with one high-risk vendor and one site.

Phase 2: Add SSE for IT-bound and egress traffic. Move web filtering, SaaS controls, and egress allowlisting for Level 3.5 and above to the SSE service. Keep OT-only networks on local controls. Feed logs to your security monitoring.

Phase 3: SD-WAN for inter-site transport. Introduce SD-WAN where there are multiple links per site and meaningful IT, historian, and backup traffic. Roll out one region first, run both transports in parallel, and tune probe thresholds from your slowest application timeout, as in the OPC UA example earlier. Only then retire expensive circuits.

Phase 4: Converge and tune. If you choose a single-vendor SASE, consolidate policy and consoles. Run failure drills: controller offline, PoP unreachable, identity provider down, one underlay failed. Document the results as part of your 62443 evidence.

Each phase has a rollback: the previous mechanism remains until the new one has carried production load through at least one maintenance cycle.

Practical Recommendations

Start from the unit of trust rather than the product category. Machines talk to machines inside zones, and those conversations should be governed by local conduits, never by a cloud service. People reach applications through brokers, and that is where ZTNA belongs. Sites talk to each other and to the internet over a transport, and that is where SD-WAN and SSE help.

Resist single-purchase thinking. A reasonable end state for a multi-site manufacturer is an SD-WAN overlay at the Level 3.5 edge, an SSE service for IT and egress, a ZTNA broker with outbound connectors for people and vendors, and an industrial firewall at each important conduit. Whether those come from one vendor or several is a secondary question about operations and integration.

Use this checklist before you sign anything:

Every site has a zone and conduit diagram, and each overlay or broker endpoint is placed on it.
No PLC, drive, or safety system is reachable through a cloud-inspected path.
Remote access uses outbound-only connectors, MFA, per-target authorization, time limits, and session recording.
Steering thresholds were derived from measured application timeouts, not defaults.
The plant operates safely with the WAN, controller, broker, and identity provider all unreachable, and this was tested.
A break-glass path exists and has been rehearsed.
Orchestrator and broker administration require MFA and are separated by role.
Vendor claims on throughput, failover, and protocol visibility were reproduced in your own pilot.
Logs from the PoP and connectors flow into your OT monitoring.
Contracts prohibit side-channel vendor access.

Frequently Asked Questions

What is the difference between SD-WAN and SASE?

SD-WAN is a networking technology that builds an encrypted overlay across multiple links and steers traffic by measured path quality. SASE is a broader model that adds cloud-delivered security services such as secure web gateway, CASB, firewall as a service, and ZTNA, usually enforced at distributed points of presence. SD-WAN is typically one component of SASE; you can deploy SD-WAN without SASE, and you can buy the security half alone as SSE.

Does SASE replace SD-WAN?

No. SASE includes or integrates with SD-WAN rather than replacing it. SD-WAN decides how packets travel between sites and clouds, while the SASE security layer decides what is inspected and permitted. Some single-vendor platforms bundle both under one console, which can feel like replacement, but the transport function and the policy function remain distinct. In plants, the SD-WAN edge also still needs a local firewall at the zone boundary.

Is ZTNA a replacement for VPN in industrial remote access?

For human access, largely yes, with caveats. ZTNA grants per-application sessions instead of subnet-level reach, supports just-in-time approval, and lets the site connector initiate outbound so you can close inbound ports. But OT devices cannot run agents, so access should terminate at a jump host or engineering workstation. Site-to-site and machine-to-machine links still need transport such as an encrypted overlay or IPsec.

Can I run PLC and control traffic over SD-WAN or SASE?

Supervisory and polling traffic such as OPC UA or Modbus TCP can cross a WAN if you design for latency and timeouts. Cyclic real-time traffic such as PROFINET RT, EtherCAT, or EtherNet/IP implicit I/O should stay within one site’s local network. Cloud PoP inspection of control traffic adds delay and a failure domain with little benefit. Keep industrial inspection local and forward logs, not packets, to the cloud.

How does this relate to the Purdue model and IEC 62443?

All three technologies sit at or above the Level 3.5 boundary. In IEC 62443 terms, the SD-WAN edge, SASE service, and ZTNA broker are parts of conduits that must be risk-assessed, with the cloud providers inside your trust boundary for those conduits. Zones around controllers and safety systems remain protected by local firewalls and, where needed, protocol breaks or data diodes.

What should be the first step in an OT migration?

Replace the contractor VPN with brokered ZTNA in front of a hardened jump host. It reduces the most exposed risk, touches no production traffic, produces audit evidence through session recording, and is easy to roll back. Do passive asset inventory and zoning first so you know which hosts and vendors the broker must cover.

SD-WAN vs SASE vs ZTNA for Industrial Sites: OT Connectivity and Remote Access Architecture (2026)