What should organisations do when OT assets cannot run host-based agents?

Use external enforcement methods that control traffic around the asset instead of inside it. That approach is better suited to fragile controllers, legacy systems, and unpatchable equipment where endpoint tooling could disrupt operations.

Use external controls when the asset cannot host an agent

When an OT device is too fragile, too old, or too operationally sensitive for endpoint tooling, the control point should move outward. The practical goal is not to “instrument everything,” but to keep enforcement effective without changing the controller, PLC, or embedded system in ways that could affect availability or deterministic behavior.

That usually means network-based enforcement, protocol-aware filtering, segmentation, and tightly governed jump paths instead of host-installed software. In OT, the safest control is often the one that can observe and constrain traffic without depending on the asset’s operating system, patch level, or spare CPU cycles.

If you can only choose one principle, choose the one that preserves process continuity first, then narrows exposure with the least intrusive control that still blocks unauthorized paths.

What “outside the asset” should look like in practice

External enforcement works best when the surrounding architecture is designed for it. That includes zoning and conduit design, allowlisting of approved communications, protocol gateways where needed, and dedicated monitoring that can distinguish normal operations from abnormal commands or destinations. NIST’s OT guidance is a useful reference point for this architecture-first approach, and CISA’s ICS resources remain a practical baseline for segmenting industrial environments and understanding common control-system exposure patterns: NIST SP 800-82 Rev 3 and CISA Industrial Control Systems.

The important judgment is that the enforcement layer must understand the operational protocol and the process boundary. A generic firewall rule set is usually not enough if it cannot distinguish a legitimate read from a write, or a maintenance action from a production command. In fragile OT estates, precision matters more than breadth.

Where the environment already uses zero trust concepts, this pattern also fits the broader rule of verifying traffic and constraining movement at the boundary instead of assuming the endpoint can enforce policy itself. NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture both support that outer-control mindset.

How to judge whether the workaround is actually safe

External enforcement is not automatically safe just because it avoids the endpoint. It is only safe when the control can still enforce the relevant decision with enough fidelity to prevent unauthorized traffic, unsafe commands, or lateral movement. If the replacement control cannot see the needed protocol detail, it may reduce operational risk while leaving security risk intact.

The common failure mode is overgeneralisation: teams swap out a host agent for a perimeter control but fail to validate that the control covers all management paths, vendor tunnels, and exception channels. In OT, the hidden path is often the one that bypasses the intended enforcement point.

That is why the right test is not “can we block traffic?” but “can we block the specific traffic and actions that matter, without disturbing normal control flows?” If the answer is no, the design is not finished.

Standards & Framework Alignment

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

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-05 — Network Integrity is Protected (Protection Processes)	External boundary enforcement is central when OT assets cannot host agents.
Recommendation — Enforce network segmentation and traffic controls around fragile OT assets.
NIST SP 800-53 Rev 5	SC-7 — Boundary Protection	Network-based control is the main substitute for host agents on OT equipment.
Recommendation — Implement boundary protection to control OT traffic without endpoint agents.
ISO/IEC 27001:2022	A.8.20 — Network security	OT security here depends on controlling communications around unsupported endpoints.
Recommendation — Apply network security controls to constrain communications around OT assets.
CIS Controls v8	CIS-13 — Network Monitoring and Defense	Monitoring and restricting OT traffic externally is the key compensating control.
Recommendation — Monitor and defend OT network traffic where host agents are not possible.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	Boundary verification and least privilege fit the compensating-control model.
Recommendation — Verify every access path and enforce least privilege at the control boundary.

Practitioner Guidance

What to verify: Confirm that the external control can enforce policy on every real access path, including maintenance, vendor, and emergency routes. If a path is excluded from inspection or control, treat it as a separate risk domain rather than a minor exception.

Decision rule: If adding an agent could threaten uptime, determinism, or vendor support, prefer network-level enforcement and process-aware segmentation. If the asset is capable of safe endpoint tooling, the decision can move back toward host-based controls, but only after change and rollback risk are understood.

What good looks like: The asset continues to operate normally, while all non-approved traffic is constrained at the boundary and every approved exception has an owner, reason, and expiry.

Practitioner takeaway: In OT, the right control is usually the one that reduces exposure without becoming part of the machine you are trying to protect.