Securing Operational Technology and Embedded Systems

Operational technology (OT) controls physical processes: power generation and distribution, water treatment, manufacturing lines, building systems and transportation. Embedded systems are computers built into devices: vehicle controllers, medical devices, communications equipment, sensors and weapons platforms. Both increasingly connect to networks, and both have become targets.

Securing them draws on the same principles as IT security, but the priorities and constraints are different enough that applying IT practices directly can cause harm.

What makes OT and embedded systems different

Safety and availability come first

In an office network, the priority is usually confidentiality. In a control system, a process that stops unexpectedly or behaves incorrectly can damage equipment, harm people or halt a mission. Security measures must not introduce those risks.

Long lifespans

OT equipment and embedded devices commonly operate for decades. Many run operating systems and software long past vendor support, and replacing them requires capital projects and operational downtime.

Patching is hard

Updates may require vendor certification, testing and scheduled outages. Some devices cannot be updated at all without replacing hardware.

Fragile protocols and devices

Industrial protocols were often designed without authentication or encryption. Some devices respond poorly to unexpected network traffic, and aggressive scanning has been known to disrupt them.

Physical access and interfaces

Embedded devices may be physically accessible to adversaries, especially when fielded. Debug ports, exposed storage and radio interfaces can provide paths that network defenses never see.

Where attacks come from

Public reporting on OT incidents frequently describes attackers entering through connected IT networks, such as corporate systems, remote access paths or vendor connections, and moving toward control systems. Government advisories have also described state-sponsored actors pre-positioning in critical infrastructure networks. For embedded systems, supply chain compromise and physical tampering are additional concerns.

Core defensive measures

Know what you have

Maintain an accurate inventory of devices, firmware versions, protocols and communication paths. Passive monitoring tools designed for OT can build an inventory without disrupting devices.

Segment aggressively

Separate OT networks from IT networks, with tightly controlled, monitored connections. Limit which systems can communicate with controllers, and on which protocols. Segmentation is often the single most effective control available.

Control remote access

Remote access for vendors and engineers should go through a managed, monitored gateway, with multifactor authentication, time limits and session recording where possible.

Monitor for abnormal behavior

OT networks tend to be predictable. Monitoring can detect new devices, unusual commands and unexpected communication paths, which are often early signs of intrusion.

Manage vulnerabilities pragmatically

When patching is not possible, reduce exposure: restrict network access to vulnerable devices, disable unused services, and monitor for exploitation attempts. Prioritize vulnerabilities that are known to be exploited and reachable.

Protect firmware and hardware

For embedded systems: sign and verify firmware, disable debug interfaces in production units, protect stored secrets, and consider anti-tamper measures for devices that may be captured or exported.

Plan for incidents

Response plans for OT must account for safety, manual operations and coordination with operations staff. Practice them.

Testing without breaking things

Security testing of OT and embedded systems is valuable, but it must be planned carefully:

• Test in representative environments where possible: laboratories, test benches, spare equipment or digital twins.
• Use passive techniques on live systems wherever possible.
• Coordinate with operations and schedule active testing during maintenance windows, with engineers present.
• Define stop conditions so testing halts immediately if anything behaves unexpectedly.
• Include hardware and firmware analysis for embedded devices, examining interfaces, storage and update mechanisms.

A note for defense programs

Weapons systems and mission platforms combine embedded computing, specialized buses and communications, and long sustainment periods. Security requirements, including program protection, anti-tamper and cyber survivability, must be designed in early, because they are very difficult to add later.

Questions to ask about your environment

• Do we have a current inventory of OT devices and embedded systems, including firmware versions?
• Which IT systems, users and vendors can reach OT networks, and how is that access controlled and monitored?
• Which devices are running unsupported software, and what compensating measures protect them?
• Would we detect a new device or an unusual command on an OT network?
• Do our incident response plans account for safety and manual operations?
• For fielded embedded systems, what protects firmware and debug interfaces from an adversary with physical access?

Frequently asked questions

Can we run vulnerability scans on OT networks? Carefully. Active scanning can disrupt some devices. Passive monitoring is safer for live networks; active techniques should be tested first and scheduled with operations staff.

Is air-gapping enough? True air gaps are rarer than organizations believe. Removable media, vendor laptops, maintenance connections and data transfers frequently bridge them. Treat "air-gapped" systems as needing controls of their own.

Where should we start? Inventory and segmentation. Knowing what you have and controlling what can talk to it addresses a large share of the risk.

How CDT can help

CDT's embedded and critical system protection services assess and harden embedded devices, control systems and platforms, with testing planned around safety and availability. Our vulnerability research and reverse engineering team analyzes firmware and hardware, and critical program information and program protection support helps defense programs build security in.

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA Industrial Control Systems