What is the difference between a software-defined zero trust overlay and a traditional underlay network for OT connectivity?

A software-defined zero trust overlay applies identity and policy at the connectivity layer, while a traditional underlay network relies more on infrastructure changes such as routing, firewalls, and VLAN segmentation. In OT, the overlay model supports granular conduits across Purdue levels without redesigning the base network, which can lower disruption and simplify governance.

What the overlay changes compared with the underlay

A zero trust overlay changes the trust model without requiring the OT network to be rebuilt. It treats connectivity as policy-driven, so access is granted to specific users, devices, workloads, or services based on identity and rules rather than on where the traffic sits in the network. A traditional underlay still matters for transport, but it does not decide trust as finely.

That distinction is important in OT because the physical network often has long-lived infrastructure, vendor dependencies, and segmented production zones that are expensive to redesign. An overlay can sit above that estate and apply the core zero trust architecture principles from NIST SP 800-207 without forcing every switch, VLAN, or routing decision to become the primary control point.

The underlay is therefore the transport fabric, while the overlay is the access and policy fabric. In practice, the overlay is used to express who may connect, to what, under what conditions, and for how long, while the underlay keeps packets moving through the plant, site, or remote access path.

Why OT connectivity behaves differently in each model

OT connectivity has to respect process continuity, vendor support constraints, and hierarchical zones such as Purdue levels. A traditional underlay usually enforces separation through network design: VLANs, firewall rules, routing boundaries, and sometimes physically distinct segments. That works, but it often couples security change to network change, which can slow approvals and make fine-grained exceptions harder to manage.

A software-defined zero trust overlay separates logical policy from physical topology. That means a maintenance engineer, remote vendor, or control application can be given tightly scoped access to one conduit without reshaping the underlying network architecture. For OT teams, the value is not just stronger control, but also less operational disruption when access relationships change.

In environments with east-west traffic between sites, cells, or vendors, the overlay can also make workload identity and mutual TLS concepts from SPIFFE and SPIRE relevant to machine-to-machine trust. That is useful when the real problem is not simple routing, but proving which workload, service, or controller is allowed to talk to another.

What practitioners should look for when comparing the two

The right comparison is not “overlay versus network,” but “policy at the edge of trust versus policy embedded in infrastructure.” Underlay controls are still essential for segmentation, resilience, and traffic engineering, but they are coarse-grained. Overlay controls are better when the requirement is to grant or revoke a specific communication path without exposing a larger subnet or relaxing the broader network boundary.

For OT, that usually means the overlay is a better fit when access needs to be temporary, role-based, vendor-specific, or tied to a narrow maintenance window. The underlay remains the better fit when the objective is stable plant segmentation, deterministic routing, or hard separation between operational zones.

A practical implementation should also account for governance. Zero Trust Identity Guide is useful here because the policy question is not only network reachability, but also whether identity, posture, and continuous verification are strong enough to justify each conduit. Without that, an overlay can become just another remote access layer.

Risk and Threat Considerations

OT overlays reduce the blast radius of connectivity, but they also concentrate trust decisions in a policy plane. If identity, policy enforcement, or trust binding is weak, an attacker may gain a highly targeted path into systems that look segmented on paper but are still reachable through the overlay. In the underlay model, the main failure mode is usually broader exposure from coarse segmentation or misrouted trust boundaries.

Failure mechanism: Weak policy definition, stale access, or compromised credentials can turn a supposedly narrow overlay into a high-value lateral movement path, especially when vendor access or machine-to-machine conduits are reused across environments.

Impact: The result can be unauthorized access to OT assets, reduced segmentation value, and a much smaller detection window because the access path appears legitimate at the transport layer.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	PR.AA-05 — Network Access is Restricted	Zero trust overlays enforce per-request access decisions at the connectivity layer.
Recommendation — Apply per-request policy enforcement instead of trusting network location.
NIST SP 800-53 Rev 5	AC-4 — Information Flow Enforcement	OT overlays and underlays both govern allowed traffic flows between zones.
	IA-9 — Service Identification and Authentication	Overlay trust in OT often depends on authenticating workloads and services.
Recommendation — Enforce conduits and segment flows with explicit policy. Authenticate machine-to-machine connections before allowing OT access.
CIS Controls v8	CIS-12 — Network Infrastructure Management	The comparison hinges on how segmentation and connectivity controls are implemented.
Recommendation — Document and manage segmentation, routing, and boundary controls.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Overlay policy failures can create excessive machine access in OT paths.
Recommendation — Minimize machine access scopes for every OT conduit.

Practitioner Guidance

What to verify: Confirm whether the access decision is being made on identity and policy, or merely hidden behind network translation. If the overlay still permits broad trust after authentication, it is not delivering the control benefit it claims.

Trade-off: Overlays simplify change management and granular access, but they add dependence on policy correctness and identity assurance. Underlays are simpler to reason about operationally, but they are usually harder to adapt when access needs become more specific.

What good looks like: A practitioner should be able to define, for each OT conduit, who can connect, from where, to what asset, for how long, and under what verification conditions. If that answer requires broad subnet permissions or manual firewall exceptions, the design is still underlay-centric.

Practitioner takeaway: Use the overlay when the security problem is specific trust and access control, and keep the underlay focused on transport, resilience, and coarse segmentation. The strongest designs combine both, but they do not confuse network path with authorization.