Vulnerability Management for OT and IoT Devices

Vulnerability management for operational technology (OT) and IoT devices has the same goal as it does in IT, which is finding weaknesses and reducing them, but the priorities are reversed. Safety and availability come first. In practice that means discovering assets passively before scanning anything, applying only vendor-approved patches inside planned maintenance windows, ranking vulnerabilities by physical and business consequence rather than CVSS alone, and leaning on segmentation and compensating controls for the many devices you can't patch quickly.

This post covers each of those steps, with pointers to ISA/IEC 62443 and CISA's ICS advisories along the way.

How is OT vulnerability management different from IT?

In IT, a failed patch usually means a help desk ticket. In OT, a controller that faults mid-process can stop a production line or create a safety hazard.

That's why an OT program has to be built with the people who run the process, not imposed on them.

Should you scan OT networks or discover assets passively?

Start passively. Many industrial controllers, protection relays and older field devices have limited network stacks. Traffic they don't expect, such as a broad port scan or a burst of malformed packets, can make them hang, reboot or drop into a fault state. On a live process, that's an outage caused by the security team.

Passive discovery

Passive tools listen to a copy of network traffic from a switch mirror port or network tap. They parse industrial protocols to identify devices, vendors, models and often firmware versions, without sending anything onto the network. The limits are straightforward: they only see devices that communicate, and only on segments where you've placed a sensor.

Careful active queries

Some details, such as exact firmware or module versions, may only come from asking the device. If you need active collection:

• Use methods the equipment vendor supports, ideally the device's own protocol rather than generic scanning.
• Test against identical hardware in a lab or on spares first.
• Target specific devices at low rates rather than sweeping whole ranges.
• Schedule it in a maintenance window with operations' sign-off and an engineer available.

Offline sources

Much of the best inventory data never crosses the network. Engineering project files, controller configuration backups, as-built drawings, spare parts lists, maintenance records and physical walkdowns all fill gaps that network tools can't.

CISA and partner agencies published "Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators" in August 2025. It's a useful reference for which attributes to collect and how to organize them into a taxonomy.

For each OT asset, aim to record the vendor, model, firmware version, physical location, network zone, the process function it supports, its criticality, the protocols it uses, any remote access paths and its support status.

How do you build an IoT device inventory?

IoT devices in offices and buildings create a similar problem at a different scale. Cameras, door controllers, building management systems, meeting-room displays, environmental sensors and smart printers are often bought by facilities or individual departments, installed by contractors and never enrolled in IT management.

Find them through:

• DHCP logs and device fingerprinting
• Network access control or switch port data
• Passive network monitoring
• Purchasing records and facilities contracts
• A physical walk around the building

For each device, record the manufacturer, model, firmware version, how it receives updates (automatically, manually or only through the vendor), whether default credentials have been changed, which cloud services it depends on and when the manufacturer's support ends.

Regulation is starting to push manufacturers here. Under the EU Cyber Resilience Act, which entered into force in December 2024, manufacturers will have to report actively exploited vulnerabilities from 11 September 2026, and most other obligations, including vulnerability handling, will apply from 11 December 2027. That's a fair basis for procurement questions about security update support.

Where do OT vulnerability details come from?

CISA publishes ICS advisories covering industrial products from a wide range of vendors. Each advisory lists affected products and versions, severity scores, the vulnerability types and recommended mitigations. CISA also publishes machine-readable versions using the Common Security Advisory Framework (CSAF) in its public CSAF repository, which makes automated matching against an inventory much easier.

Supplement CISA advisories with:

• Equipment vendors' own security advisories, which often appear before or alongside CISA's
• CISA's Known Exploited Vulnerabilities catalog, which includes some industrial and IoT products

All of this depends on knowing firmware versions. An inventory that says "PLC, Line 3" can't be matched against an advisory that affects versions below a specific release.

How should you prioritize OT vulnerabilities?

CVSS measures technical severity. It doesn't know whether the device controls a warehouse light or the pressure in a vessel. In OT, prioritize by consequence first.

Ask four questions for each vulnerability:

1. What's the worst credible outcome if this device is manipulated or made unavailable? Consider safety, environmental impact, production loss and regulatory exposure.
2. Can an attacker reach it? A device reachable from the internet or the business network is very different from one on an isolated cell network with no remote access.
3. Is it being exploited? Anything in the KEV catalog or flagged as exploited in an advisory moves up.
4. What already protects it? Existing segmentation, access controls and monitoring may reduce urgency, as long as they're verified rather than assumed.

Idaho National Laboratory's Consequence-driven Cyber-informed Engineering (CCE) methodology offers a structured way to find the processes whose failure would matter most. Even an informal version, run with process engineers, sharpens priorities.

How do you patch OT systems safely?

Use vendor-approved patches only

Many industrial control system vendors test operating system patches, security updates and antivirus signatures against specific versions of their software, then publish lists of approved updates. Installing something the vendor hasn't qualified can break the application or leave the system outside its support agreement. Check the approved list before scheduling any change.

The ISA/IEC 62443 series includes a technical report on exactly this topic, IEC TR 62443-2-3, which covers patch management in the industrial automation and control system environment for both asset owners and suppliers.

Plan around maintenance windows

Coordinate patching with operations and align it to planned outages. For some processes, that means scheduled shutdowns that happen only occasionally. Use your management of change procedures for every patch, and have a plan for what gets done now versus at the next outage.

Put safety first

Before any change:

• Back up controller logic, configurations and system images.
• Write and rehearse a rollback plan.
• Have an engineer who knows the process on hand.
• For redundant systems, update one side at a time and confirm it's healthy before continuing.
• Treat safety instrumented systems with extra care. Changes may require revalidation under your functional safety procedures.

How do the Purdue model and zones and conduits help?

When patching has to wait, segmentation is what keeps an exposed vulnerability out of reach.

The Purdue model is a common reference architecture for industrial networks. It separates the physical process and sensors (Level 0), basic control such as PLCs (Level 1), supervisory control such as HMIs and SCADA (Level 2) and site operations such as historians (Level 3) from the enterprise network (Levels 4 and 5), usually with an industrial DMZ between Levels 3 and 4.

Zones and conduits, central to ISA/IEC 62443-3-2, take a risk-based approach. You group assets with similar security requirements into zones and define conduits as the only permitted communication paths between them. Each zone gets a target security level, and each conduit gets controls to match.

Practical rules that follow from both:

• No direct connections from the business network to control networks. Broker data through the DMZ.
• Permit only the specific hosts, ports and protocols each conduit needs.
• Route all remote access, including vendor access, through a controlled jump host with multi-factor authentication, time-limited sessions and logging.
• Keep internet access away from control system zones.

What compensating controls work for unpatchable OT and IoT devices?

Plenty of devices will run with known vulnerabilities for years. Compensating controls make that manageable:

• Tighten conduit rules so the vulnerable service is reachable only from the hosts that genuinely need it.
• Disable unused services and features, such as web servers, remote programming or legacy protocols.
• Use physical controls. Many controllers have a key switch or setting that blocks remote program changes. Leave it in run mode.
• Harden engineering workstations. They can reprogram controllers, which makes them a high-value path in.
• Apply application allowlisting on HMIs, historians and engineering stations.
• Control removable media that crosses into control zones.
• Monitor passively for new devices, unusual connections and controller program downloads.
• Keep offline backups of logic and configurations so recovery doesn't depend on the affected system.

For IoT devices, move them onto dedicated segments, block any traffic they don't need, change default credentials and restrict their cloud connections to the vendor services they actually use.

Where does ISA/IEC 62443 fit?

ISA/IEC 62443 is the international standards series for industrial automation and control system security. The parts most relevant to vulnerability management are:

Parts 4-1 and 4-2 are useful in procurement. Asking suppliers how they meet them, including how they handle vulnerabilities, tells you a lot about the patching support you'll get. In the US, NIST SP 800-82 Rev. 3, the Guide to Operational Technology (OT) Security, is a free companion reference.

Frequently asked questions

Can we run our normal vulnerability scanner on the OT network?

Not without careful testing. Standard IT scan policies can disrupt fragile devices. Start with passive discovery, and use active checks only where the equipment vendor supports them, after lab testing and with operations' agreement.

How often should OT devices be patched?

There's no single cadence. Tie it to vendor approvals, the device's consequence rating and your planned outages. Exploited vulnerabilities on reachable, high-consequence systems justify an unplanned window. Most others can wait for the next scheduled one if compensating controls are in place.

Do office IoT devices need the same care as industrial OT?

Usually not the same caution around scanning, but the same discipline around inventory, segmentation and firmware updates. Many IoT devices can be patched like normal IT once someone owns them.

Key takeaways

• Build the inventory passively first, and include firmware versions.
• Patch with vendor-approved updates only, in planned windows, with backups and a rollback plan.
• Rank vulnerabilities by physical and business consequence, then by reachability and exploitation.
• Use the Purdue model or zones and conduits to keep vulnerable devices out of reach.
• Give every IoT device an owner, a segment and a record of how it gets updated.
• Use ISA/IEC 62443 and CISA ICS advisories to give the program structure.