A ransomware incident at a manufacturer doesn’t stop at an inbox. It can stop a line, delay shipments, compromise product quality, and leave leaders explaining lost margin to customers and the board.
OT security in a plant protects production systems without treating a facility like an office network. It must account for uptime, safety, legacy equipment, vendor access, maintenance windows, and the cost of a bad change.
The first step is translating operational technology risk into decisions your leadership team can see, fund, and own.
Key takeaways for manufacturing OT security
- OT risk is a business continuity concern, not just a technical security problem.
- IT and plant teams need shared decision rights, but they don’t need identical controls.
- Passive asset discovery, network segmentation, and controlled remote access reduce exposure without unnecessary downtime.
- Legacy PLCs need layered protection, tested backups, and a safe recovery process.
- Boards need reporting on production impact, recovery capability, ownership, and decisions, not vulnerability counts.
Why OT risk reaches the P&L
Operational technology includes industrial control systems such as programmable logic controllers and SCADA systems. It also includes human-machine interfaces, industrial networks, sensors, historians, manufacturing execution systems, and industrial internet of things devices that keep production moving.
Digital transformation has connected more plant assets, increasing the attack surface and attracting cyber threat actors. Ransomware attacks can stop one plant, one line, or a shared system serving many customers. An attacker doesn’t need to steal every file to create damage, since interrupting production for several hours may be enough.
The most common path is often a connection between corporate IT and the plant. An attacker may compromise an employee account, exploit remote access, or use a vendor credential. If networks are flat or poorly controlled, an attacker can begin lateral movement toward systems that weren’t designed for enterprise-level threats.
Manufacturers also carry legacy systems that can’t be patched like a laptop. Some run for years. A patch may require a shutdown, vendor approval, testing, and a controlled restart. A security tool that scans aggressively or reboots a device can create its own operational risk.
That’s why a standard IT security checklist isn’t enough. Your plant team may reject a control that could interrupt a batch or create an unsafe state. Your security team may reject an exception that has no expiration date. Both concerns are valid.
You need a shared view of the consequence. What happens if this line stops? How long can orders wait? Which systems affect safety, quality, environmental obligations, or customer commitments? Those answers, together with relevant threat intelligence, set the priority for your cybersecurity risk assessment.
Bridging the gap between IT and plant floor operations
The benefits of IT and OT convergence weaken when IT owns policy, plant operations owns equipment, vendors control passwords, and executives don’t share decision rights.
You don’t fix that gap with another meeting. You fix it with clear ownership and a regular operating rhythm.
A technology steering committee can review major software purchases, significant vendor commitments, serious security risks, data decisions, technology investments, and roadmap tradeoffs. It should not manage routine IT work. Its purpose is to improve decision quality before a plant, finance, security, or customer issue forces the decision.
For each material OT risk, name:
- The business owner who accepts the operational consequence.
- The plant or engineering owner who understands the process.
- The technology or security owner who manages the control.
- The executive who resolves conflicts about cost, timing, and risk.
This is a decision rights map. It turns “someone should fix this” into an accountable plan.
Start with asset management, the ongoing discipline of maintaining device ownership, production role, communications, vendor dependencies, and business-impact data. Don’t begin by running intrusive scans across sensitive equipment; use passive network monitoring for continuous monitoring without aggressive probes. It can identify devices, communication patterns, protocols, and vendor connections, while threat intelligence adds relevant external context. Validate the results with plant engineers, document vendor connections and ownership, and apply least privilege, limiting access to required people and systems during maintenance windows. A device that appears inactive may still matter during a specific production cycle.
Classify assets by business impact, not age alone. An old PLC controlling a low-risk auxiliary process may need less attention than a newer system that can stop your main line.
Your technology leadership decisions should connect these findings to business priorities, budget, ownership, and timing. A monitoring alert without an accountable owner is only more noise and does not improve the organization’s security posture.
Secure legacy PLCs with layers, not wishful patching
You may not be able to patch every PLC. These programmable logic controllers may be part of legacy systems, but that doesn’t give them a free pass.
The first layer is network segmentation. Separate enterprise systems from plant systems. Use an industrial demilitarized zone for services that must communicate between them. Place higher-risk equipment inside defined zones, then restrict the conduits between those zones. This limits how far an intrusion can move without disrupting necessary plant operations.
The Purdue model helps structure these boundaries. It separates enterprise applications, site operations, supervisory systems, and cell or area controls. It is not a finished security design. It is a useful way to identify where trust changes and which connections should be allowed.
ISA/IEC 62443 adds industrial-specific guidance around zones, conduits, components, systems, and suppliers. You can review a practical NIST CSF 2.0 and IEC 62443 mapping when you need to connect an executive risk program to plant-level controls. Additional ISA/IEC 62443 guidance for older equipment can clarify why industrial environments need different protection decisions.
For equipment that cannot be patched, use compensating controls across defense, access, backup, and recovery layers. Identity and access management should govern named accounts, administrative paths, vendor permissions, and session records.
- Block unnecessary connections and outbound traffic.
- Put administrative access behind a controlled jump host.
- Apply zero trust to administrative and remote access paths, but don’t blindly impose office-network controls on safety-critical process traffic.
- Require multi-factor authentication for remote access where the technology supports it.
- Use named accounts, least privilege, time-limited sessions, and session logging.
- Require vendor access to be approved for a defined maintenance window.
- Use monitoring and threat intelligence to tune alerts for threats relevant to your sector and equipment.
- Keep current copies of PLC logic, configurations, firmware details, and network diagrams.
- Test whether those backups can be used safely before an incident.
Recovery needs its own workflow. If PLC logic changes unexpectedly, don’t immediately download an old backup and restart production. First confirm the affected asset, put the process in a safe state, preserve evidence, compare the logic against an approved baseline, and involve the controls engineer and equipment vendor. Validate the restored logic in a controlled setting before returning the system to production.
Your incident response plan should define who can isolate a zone, authorize a shutdown, speak with the vendor, and communicate with customers. Those roles help contain ransomware attacks and preserve operational resilience. That is business continuity planning, disaster recovery planning, and ransomware readiness in practical terms.
Turn OT controls into board-ready decisions
Frameworks give you structure. They don’t create accountability.
The NIST CSF 2.0 framework can help organize work around governance, identification, protection, detection, response, and recovery. IEC 62443 and the Purdue model apply that thinking to industrial systems. Applicable compliance standards and regulations create obligations, but ownership and evidence still matter.
Your board report should stay short and decision-focused. It should show:
- The production systems that matter most, with asset management coverage, clear ownership, business impact, and governance for high-impact assets.
- The top cyber scenarios, informed by threat intelligence, and their production impact and recovery consequences.
- Current exposure, including remote access, vendor dependencies, and supply chain security risks.
- Recovery capability, incident response readiness, and the date of the last meaningful test.
- Named owners, open gaps, risk-based vulnerability management for high-impact assets, deadlines, and funding decisions.
- Any risk accepted by management and its expiration date.
This is board cybersecurity reporting, not a technical activity report. A board doesn’t need to know how many alerts a tool generated. It needs to know whether a compromise could stop production, how quickly the company could contain it, and whether management is funding the right work.
Public manufacturers also need to understand their disclosure obligations. SEC rules can require public companies to disclose material cybersecurity incidents and describe their cybersecurity risk management and governance. CIRCIA may apply if your organization falls within the definition of a covered entity. Counsel should determine what applies to your company and how evidence is maintained.
Your cyber risk appetite should set the boundaries. For example, leadership may accept a temporary patching exception for a validated legacy system, but require segmentation, monitoring, compensating controls, and a replacement date. That is different from accepting an unknown risk with no owner.
If your IT team, plant engineers, security vendors, and MSP are all working hard but no executive owns the full picture, you may have a technology leadership gap. A fractional CTO can provide technology governance and business-aligned technology strategy while a fractional CISO, virtual CISO, or interim CISO focuses on cybersecurity oversight. An interim CTO is usually a better fit when the leadership seat is open or the business needs rapid stabilization.
A focused one-page technology strategy can give leaders a concise view of priorities, risk, vendors, decision rights, and the next 12 months. If the situation feels scattered, Get an Executive Technology Clarity Check can help you identify what needs ownership first.
Frequently asked questions about securing plant OT
Why are manufacturers commonly targeted?
Manufacturers rely on connected systems, operate valuable production assets, and face high costs when operations stop. Attackers often target weak remote access, reused credentials, flat networks, and legacy equipment that is difficult to patch.
How can you discover OT assets safely?
Start with passive monitoring and existing documentation. Compare network observations with plant knowledge. Avoid intrusive scanning until equipment owners, vendors, and maintenance teams agree on the method and timing.
What should you do when a PLC cannot be patched?
Segment it, restrict communications, control administrative access, monitor changes, document its baseline, and maintain tested backups. These steps limit how attackers can reach or manipulate it while you plan a safer replacement or upgrade.
How should IT and OT teams work together?
Give both teams shared objectives and clear decision rights. Plant operations should explain safety and uptime constraints. IT and security should explain exposure and control requirements. An executive owner should resolve conflicts involving cost, timing, and accepted risk.
Conclusion
Manufacturing OT security is not about making the plant behave like an office network. It is about protecting production with controls that respect how the plant actually operates.
Start with the systems that could stop production. Map the connections, secure remote access, segment the environment, protect legacy assets with layers, and test recovery before a crisis. Then give leadership and the board reporting they can use to make confident decisions.
The strongest OT program is not the one with the most tools. It is the one that improves operational resilience by making risk visible, keeping ownership clear, and ensuring everyone knows what happens next.