In a steel mill, software controls heat, motion and material, so a flaw in a component can affect a physical process, not just data. The supply chain part is that much of the code in controllers, drives and monitoring systems comes from vendors and libraries the mill does not write. Start by knowing what runs where.
This post is general. It describes no incident and no specific plant. It uses NIST and ISA/IEC 62443 material we fetched, and treats safety decisions as engineering decisions that belong to people who know the process.
Where does software sit in a mill?
Think in layers, the way OT guidance does. NIST's operational technology guide describes OT as programmable systems and devices that interact with the physical environment, with industrial control systems as a named example. In a mill that includes:
- Controllers and drives that run furnaces, casters, cranes and rolling lines.
- Supervisory and data collection software that operators watch.
- Historians and reporting tools that connect to business networks.
- Vendor remote support tools.
- Engineering workstations used to change controller programs.
Every layer contains third party components. The ones nearest the process are the hardest to update and the most consequential if they fail.
Why is it a safety issue and not only a security issue?
OT guidance frames security with performance, reliability and safety in mind. A control system that behaves unexpectedly can put people near hot or moving equipment at risk. That changes the priorities from the usual IT order of confidentiality first. In a mill, availability and safe, predictable behavior come first.
It also changes the response. Rebooting a server that runs a historian is a minor event. Restarting a controller mid-heat is a different decision, made by the operations team.
How do you split responsibility?
ISA/IEC 62443 describes roles: asset owners, automation product suppliers, integrators who build and maintain control system solutions, and service suppliers who support operation. The series includes security program requirements for asset owners (Part 2-1), secure product development lifecycles for suppliers (Part 4-1) and system security requirements and security levels (Part 3-3). Other Part 2 documents address patch management.
For the supply chain, this means the mill asks suppliers how they build and patch products, and keeps its own program for what it operates.
What does an inventory look like?
For each system near the process, record: vendor, model, firmware or software version, network zone, who can change it and how. For software you build or customize, such as dashboards and integration code, add dependency lists. CISA describes a software bill of materials as a list of the ingredients that make up software components. Ask vendors for SBOMs for products you buy.
If you receive one in SPDX or CycloneDX form, Safeguard's CLI can scan it against its advisory database, which gives you a list of flagged components to take back to the vendor. It cannot tell you whether the flaw matters to the process. The vendor and your process engineers decide that.
How do you patch without stopping the line?
- Plan windows around the process. Planned outages for maintenance are the natural time.
- Test first. Use a spare or simulated controller where one exists.
- Reduce exposure meanwhile. Segment networks, remove direct internet paths, restrict remote vendor access and control who can use engineering workstations.
- Keep a rollback. Know how to return to the last known good version.
- Record every exception. If a flagged component stays, write down why, the compensating control and the review date.
What to do
- List the systems that touch the physical process, with versions and network zones.
- Rank them by what a malfunction would affect, with operations leaders.
- Request SBOMs and security update policies from each vendor.
- Scan the SBOMs you get and send the flagged components to vendors.
- Review remote access paths and close unnecessary ones.
- Align patch windows with scheduled maintenance.
- Keep a register of accepted risks with owners and dates.
- Read NIST SP 800-82 and the 62443 parts relevant to your role.
Quick check
Is a steel mill covered by IEC 62443?
The series is for industrial automation and control systems and covers roles such as asset owners and suppliers. Whether it is required for you depends on contracts and regulation, so check with your compliance team.
Should every vulnerable component be patched immediately?
Not by default. In OT the safe change process matters. Assess reachability and process impact, apply compensating controls and patch in a planned window.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
- ISA/IEC 62443 series of standards
- CISA: Software Bill of Materials
- Safeguard CLI documentation
Last reviewed: 18 October 2026.
