At a chemical facility, defenders should inspect connections first, then control systems, then the software inside them. Know every path that reaches the plant network from outside, know what controls the process and safety functions, and only then dig into the dependencies in each device. That order puts effort where a failure matters.
Why is a chemical plant a special case?
CISA describes the chemical sector as converting raw materials into more than 70,000 products and delivering them to more than 750,000 end users, across basic chemicals, specialty chemicals, agricultural chemicals and consumer products. Other critical sectors depend on it, so uninterrupted production and transport matter well beyond one site.
The software that runs a plant is operational technology (OT). NIST SP 800-82 Rev. 3 says securing OT means handling its unique performance, reliability and safety requirements. Patching a server in an office is routine. Restarting a controller in the middle of a batch is not.
This article does not describe any specific incident. We did not find a primary source we could verify for one, so we stick to method.
What to inspect, in order
1. Every path in from outside. Remote access for vendors, VPNs, cellular modems, shared jump hosts and file transfer routes. Ask who owns each and when it was last used. Remove the ones nobody can explain.
2. The boundary between business IT and the process network. The ISA/IEC 62443 series is built around dividing a system into zones and conduits and assessing risk for each. Part 3-2 covers security risk assessment for system design, and Part 3-3 covers system security requirements. Use them as a vocabulary for drawing the boundary and arguing about it.
3. The safety functions. Know which systems protect people and the process, and confirm they are isolated and change controlled. This is a safety conversation first and a security conversation second, so include operations and safety engineers in it.
4. The asset list. Controllers, engineering workstations, historians, gateways, with firmware versions. If you cannot list them, you cannot assess them.
5. The software inside. Ask suppliers for a software bill of materials and a vulnerability contact for each product. Then match against advisories and decide, device by device, whether to patch, isolate or accept. ISA-TR62443-2-3 covers patch management in this environment.
What would a vulnerable library change?
If an advisory names a component inside a vendor product, the question is not "is it critical?" but "is it reachable on our network, and can we reduce exposure before we can patch?" Often segmentation and removing remote access buy time. Reachability analysis on software you control, and written statements from suppliers for software you do not, help you avoid shutting down for a flaw that cannot be triggered.
What to do
- List every remote and third party access path and name an owner for each.
- Draw the zone boundaries between business IT, the process network and safety systems on one page.
- Build an asset list with firmware versions and the date each was last reviewed.
- Request SBOMs and disclosure contacts from every control system supplier.
- Agree a patch policy with operations: what is patched live, in a planned window, or never.
- Read NIST SP 800-82 Rev. 3, and note that Revision 4 is in draft with public comments due 30 November 2026.
Quick check
Is IEC 62443 a certification I can ask a vendor for?
It is a series of standards. Some products and processes are assessed against it, but ask exactly what was assessed and by whom. Do not accept "62443 compliant" without that detail.
Should IT security lead the work?
Share it. IT brings tooling and incident practice. Operations and safety engineers know what a change can do to the process.
Sources
Last reviewed: 18 October 2026.
