Article·2,284 words · ~10 min read
Segment PLCs, sensors, and legacy OT behind unmanaged switches without installing agents or redesigning the plant network. This practical guide shows where to enforce identity-based, least-privilege access.
Operational technology is hardest to segment when the device cannot run an agent and the switch cannot enforce policy. The workable pattern is to place a policy enforcement point in front of the device or device group, give that enforcement point a cryptographic identity, and permit only named services and identities. You can contain PLCs, sensors, HMIs, and serial equipment without installing software on the controller or redesigning the plant network.
NIST describes zero trust as protecting resources rather than trusting their physical or network location in SP 800-207. For OT, that means the segmentation boundary has to sit where the plant can support it. You don’t need to make an old PLC understand modern identity. You need to stop unauthorized paths from reaching it.
What makes OT device segmentation different
OT device segmentation must protect equipment that can’t tolerate ordinary endpoint controls. PLCs, remote terminal units, sensors, HMIs, and serial gateways often have fixed firmware, vendor-specific protocols, narrow maintenance windows, or no supported way to install a security client.
The usual network controls create a second problem. VLANs, access-control lists, and firewall rules depend on switch features, IP ranges, and a stable topology. An unmanaged switch offers none of the policy hooks that a managed switch does. Moving a cable can change the effective boundary without changing the written policy.
The existing risks are real, but a risk summary is not a deployment plan. The risks of flat OT and IT networks explains why one compromised path can expose controllers, HMIs, and other plant assets. The steps below focus on what to do when the assets themselves can’t carry an agent.
Choose the right enforcement point
The enforcement point belongs beside the asset, not inside it. Start by choosing the smallest boundary that protects a meaningful production function.
| OT situation | Practical enforcement point | What it protects |
|---|---|---|
| One PLC or HMI needs remote service access | Connector in front of the asset | A named machine and service |
| Several devices share an unmanaged switch | Gateway on the protected side of the switch | A cell, line, or device group |
| Serial devices sit behind an industrial gateway | Gateway or protocol-facing connector | The serial segment and its reachable services |
| Sensors connect through an edge computer | Connector at the edge or gateway | The sensor group and its upstream service |
| A plant cannot connect to an external control plane | Local enforcement point | On-site policy and local traffic |
This is a different design decision from choosing a new VLAN. Network vs. Identity-Based Segmentation compares the policy models. For agentless OT, the important question is more specific: where can you place an identity-aware gateway without touching the controller or interrupting the process?
How to segment PLCs and sensors without agents
The procedure is straightforward: front the devices, create identities for the connectors and clients, publish only the required services, and test the deny path before expanding access.
1. Map services, not just devices
Begin with the production task that needs connectivity. Record the destination device, protocol, port, initiating identity, and reason for access. A list such as “engineering workstation to PLC” is too broad. Record the exact service and the people or systems that need it.
Separate these flows:
- Control traffic between the PLC and its local process equipment
- HMI traffic to the PLC
- Historian or data-collection traffic
- Engineering and maintenance access
- OEM or integrator access
- Monitoring and backup traffic
Do not assume that every device on the same switch needs to communicate. A sensor may need to send readings to an edge collector but have no reason to reach a PLC. A vendor may need a programming service for one controller but no access to the rest of the cell.
2. Put a gateway in front of the protected group
Install a lightweight connector or gateway on the network side that can reach the devices. The controller stays unchanged. The gateway becomes the point where identity and policy can be applied.
For one critical asset, a dedicated connector gives you the narrowest boundary. For a group behind an unmanaged switch, a gateway is usually more practical. It lets you preserve the existing switch and address plan while placing a controlled boundary around the group.
This pattern also works for serial equipment. The enforcement point fronts the serial gateway or protocol translator, so the legacy devices don’t need an IP stack, a VPN client, or a software agent.
3. Use outbound-only connectivity where possible
Have the connector establish an outbound connection rather than exposing a listening service into the plant. This removes the need to publish an inbound firewall port for remote access and keeps the protected asset unreachable until an authorized identity requests a permitted service.
Outbound-only does not mean “allow everything out.” Apply egress rules to the connector and restrict its destinations. The connector should reach the control plane or approved peers, not become a new route from the plant to the internet.
4. Authenticate before creating a path
Require mutual authentication for the connecting identity and the enforcement point. NIST’s zero trust model separates authentication and authorization from the network location of the asset. The session should not become routable simply because a user reached the plant network or a device received an address.
Use separate identities for:
- Plant operators
- Engineering staff
- Internal support teams
- OEMs and integrators
- Data collectors and historians
- Site connectors and gateways
An identity is useful only if policy uses it. Do not replace an IP allowlist with a username allowlist and call the problem solved. Tie the identity to a specific service, time window, device posture requirement, or approval workflow where the use case needs one.
5. Write default-deny service policies
Permit the smallest useful connection and deny the rest. A policy should answer four questions: who can connect, to which service, through which enforcement point, and under what conditions.
Example policy intent:
| Source identity | Destination | Permission | Condition |
|---|---|---|---|
| Operator group | HMI service for Cell 3 | Read and operate | Plant network identity and approved shift |
| Engineering group | PLC programming service for PLC-3A | Maintenance access | Ticket or time-bound approval |
| Historian identity | PLC data service | Read only | Collector identity only |
| OEM identity | PLC-3A maintenance service | Temporary maintenance | Explicit grant, full session logging |
| Any other identity | Cell 3 devices | Deny | Default |
The point is not to recreate every firewall rule in a new console. The point is to make the allowed business paths explicit and make an unlisted path impossible.
6. Test the deny path before production rollout
Test from the same networks and identities that operators and vendors will use. Confirm that an approved user can reach the intended service, an approved user cannot reach a second service, and an unapproved identity cannot discover or connect to the device.
Run the test during a controlled window if the gateway is being placed inline. If the architecture uses an overlay or a connector that does not interrupt local traffic, validate local process operation first, then enable remote policy in stages.
Keep the old operational path available during the initial test, but don’t leave it as a permanent bypass. A segmentation design that works only when an unrestricted VPN remains active has not reduced the attack surface.
7. Log access by identity and service
An OT firewall log that says “10.20.4.18 connected to 10.20.4.31” leaves the operator to reconstruct who acted and why. Record the connecting identity, destination service, policy decision, start and end time, and approval or ticket reference where available.
Send these events to the SOC’s existing logging system. Pair the access record with asset inventory and change-management data. That gives incident responders a way to answer a practical question: which identity reached this controller, through which path, during which maintenance window?
How to handle unmanaged switches
An unmanaged switch does not prevent segmentation. It prevents switch-based segmentation. Put the boundary above the switch and treat the devices behind it as a protected group until you have a reason to split them further.
The gateway approach has three useful properties:
- It does not depend on VLAN support or 802.1X on the switch.
- It preserves the existing IP ranges and cabling.
- It lets you apply policy to the identities that connect to the group.
The tradeoff is granularity. If all devices share one gateway identity and one policy, the gateway may protect the group without distinguishing every physical device. Use separate connectors, protocol-aware controls, or smaller gateway boundaries when the process requires per-device isolation.
Don’t claim device-level isolation when the enforcement point can only distinguish the shared segment. Document the actual boundary. Honest scope is more useful than a diagram that implies controls the deployment does not provide.
How to segment air-gapped or intermittently connected OT
An air-gapped plant changes the control-plane design, not the need for least privilege. Use a local enforcement model when policy and identity services cannot depend on a continuous cloud connection. Define how identities are issued, how access is approved, how revocation reaches the site, and how logs leave the site when a link becomes available.
For intermittently connected sites, test the failure mode. Local production traffic should continue when an upstream management connection drops. Remote access should fail closed unless the site has a documented, time-bounded exception.
The CISA microsegmentation guidance describes microsegmentation as a way to reduce attack surface, limit lateral movement, and improve visibility across smaller isolated groups of resources. In OT, those groups can be a cell, line, cabinet, or device class, as long as the boundary reflects the actual process.
How to handle vendor access to PLCs
Vendor access should be a separate identity and a separate policy from operator access. Give an OEM access to the one machine and service required for the work, for the shortest practical period. Revoke the grant when the job ends.
Avoid a shared vendor VPN account. It hides individual actions and often grants a route to the plant rather than access to one service. Require the vendor to authenticate as an identifiable user or workload, record the session, and use an approval reference that the plant can review later.
The same model applies to a system integrator commissioning a line. Commissioning may need broader access than routine maintenance, but that is a different use case and should have a different identity, policy, and expiration path.
What to measure after deployment
Measure whether the boundary works, not just whether the connector is online. Track:
- Number of OT services reachable before and after policy enforcement
- Number of identities with access to each PLC, HMI, and gateway
- Denied connection attempts by identity and destination
- Vendor sessions with an approval and an end time
- Devices still reachable through legacy VPN or firewall exceptions
- Local production behavior during a control-plane or WAN outage
- Time required to grant and revoke a maintenance path
The strongest result is a smaller set of explicit paths. If the new design adds a gateway but keeps the old flat route, the plant has gained another control point without removing the original exposure.
FAQ
Can PLCs be segmented without installing software on them?
Yes. Place a connector or gateway in front of the PLC and enforce identity-based policy there. The PLC can keep its existing firmware, protocol, IP address, and switch connection while unauthorized paths are denied outside the device.
How do you segment OT devices behind an unmanaged switch?
Place the enforcement point on the protected side of the unmanaged switch and treat the connected devices as a controlled group. This avoids depending on VLANs or switch ACLs, but you should document whether policy distinguishes individual devices or only the group.
What is network segmentation without agents?
It is segmentation enforced by a gateway, connector, firewall, or other policy point outside the protected endpoint. The endpoint does not run a client, but access still depends on an authenticated identity and an explicit service policy.
Does OT segmentation require a network redesign?
No. A gateway-based design can preserve existing cabling, IP ranges, and switches. A redesign may still be appropriate for a high-risk plant, but it isn’t a prerequisite for containing the first device group.
How should remote vendors access industrial controllers?
Give each vendor an individual, time-bound identity that reaches only the required controller service. Avoid shared VPN accounts, record the session, and revoke the grant when the maintenance task ends.
Is an air-gapped OT network automatically segmented?
No. An air gap limits a connection path, but it does not define least-privilege access between assets that share the plant network. A compromised device or authorized user can still move laterally unless the internal paths are controlled.
Related articles
- The Risks of Flat OT and IT Networks
- Network vs Identity-Based Segmentation
- Zero Trust Tools for Cloud Workloads: A How-To Guide
Sources & References
- NIST SP 800-207: Zero Trust Architecture – zero trust principles and resource-focused access control
- CISA: Microsegmentation in Zero Trust – attack-surface reduction, lateral-movement limits, and planning guidance
- NetFoundry OT & IoT Connectivity – agentless OT deployment and gateway patterns
- NetFoundry Universal Microsegmentation – identity-to-service policy and unmanaged-device coverage