IT security programs fall short in plants, mines, and pipelines because they were built to protect data, while operational technology exists to keep people safe and production running. Applying office controls to a control system without that distinction either breaks something on the floor or gets quietly ignored. An effective OT security program starts with safety and uptime, then fits security around them.
What OT Is and Why It Is Different
Operational technology, or OT, is the hardware and software that monitors and controls physical processes: programmable logic controllers, distributed control systems, SCADA, safety instrumented systems, and the engineering workstations and networks that connect them. In IT, the priority is usually confidentiality first. In OT, the order flips. Safety comes first, then availability and the integrity of the process, and confidentiality comes last.
That difference changes almost every security decision. A patch that requires a reboot is routine on a laptop and can mean a planned shutdown on a processing line. An aggressive network scan that is harmless in an office has been known to cause older controllers to fault. In our principals' experience running global infrastructure and security across operating sites in several countries, the most damaging OT mistakes were made by well-meaning IT teams who did not know the process.
Where IT Security Programs Fall Short
- No accurate asset inventory. IT tools rarely see controllers, drives, and field devices. Many sites cannot say what is connected to their control network, what firmware it runs, or who supports it.
- Flat networks. Control systems often share a network with business systems, or connect to it through paths nobody documented. One compromised office machine can then reach the plant.
- Remote access sprawl. Vendors, integrators, and engineers each set up their own way in over the years. Some connections are always on and use shared accounts.
- Patch expectations that do not fit. Equipment can run for decades on operating systems the vendor no longer supports, and changes may require vendor approval or a scheduled outage.
- Incident response plans written for IT. A plan that says "isolate and reimage" does not explain how to keep a kiln, a mill, or a compressor station safe while you investigate.
- Unclear ownership. IT owns the network, engineering owns the controllers, operations owns the outcome, and nobody owns the security of the whole.
In a plant, the security team does not get to stop the process. It has to protect it while it runs.
What a Fit-for-Purpose OT Program Looks Like
An OT security program should be designed with operations and engineering, not delivered to them. The practical building blocks are:
- Know what you have. Build an inventory using passive monitoring and site walkdowns, not active scanning of live controllers.
- Separate and control the paths. Segment control networks from business networks, with a controlled boundary zone between them, and limit traffic to what the process needs. The ISA/IEC 62443 series describes this using zones and conduits.
- Take control of remote access. Route all vendor and engineer access through a single, monitored path with individual accounts, multifactor authentication, and sessions that are approved and time-limited.
- Protect what you cannot patch. Use compensating controls: segmentation, application allowlisting, removable media rules, and monitoring for unusual commands.
- Have a recovery plan the site has practiced. Keep known-good copies of controller logic and configurations offline, and rehearse running in manual or degraded mode.
- Write response plans with operations. Decide in advance who can order a shutdown, how to operate safely during an incident, and when to involve the control system vendor.
Regulation and Standards Worth Knowing
ISA/IEC 62443 is the most widely used family of standards for industrial automation and control system security, covering everything from program management to requirements for individual components. NIST also publishes guidance specific to OT security in Special Publication 800-82. Some sectors carry mandatory requirements: bulk electric system owners are subject to NERC CIP standards, and the TSA has issued security directives for certain pipeline owners and operators. Mining and general manufacturing face fewer cyber-specific mandates, but customers, insurers, and boards increasingly ask the same questions.
Where to Start
A company does not need to solve everything at once. A sensible sequence for most industrial organizations:
- Pick one or two critical sites and build an honest inventory and network map.
- Close or consolidate remote access paths, starting with vendors.
- Confirm you can restore controller logic and key servers, and test it.
- Put a single leader in charge of OT security with authority across IT, engineering, and operations.
- Report OT risk to leadership in terms of safety and production impact, not technical findings.
The Bottom Line
OT security is not IT security moved to a plant. It is a discipline that puts safety and production continuity first, works with the people who run the process, and accepts that some equipment will be old and unpatched for years. Companies that build their program on that foundation reduce real risk without disrupting the operation. Those that do not tend to find out during an incident.
If your plants, mines, or pipeline assets are running on an IT security program, talk with us about where the gaps are.
Want to Talk It Through?
Every conversation is with a principal, not a sales team.
