What Texas Manufacturers Get Wrong About OT/IT Security

Manufacturing has been the world’s most attacked industry for 5 straight years, and Texas plants usually get hurt by ordinary assumptions rather than exotic control system malware. The air gap is gone. The HMI screen can be made to lie. Cyber insurance may not pay for a stopped line. Below are 7 beliefs we run into on real shop floors, what each one costs, and a self-test you can finish in a week.

Texas manufacturers get OT security wrong by defending the plant floor and the business network as 2 separate problems. Those networks already share credentials, vendors, and traffic. An attacker needs 1 way in, and production is what stops.

Ask 10 Texas plant owners who is responsible for security on the control network and you’ll get 4 answers. IT. The controls integrator. Corporate. And the one nobody says out loud, which is that it has never actually been assigned. That last answer is more common than people want to admit, and it is almost never the result of neglect. It is the result of 2 competent teams each assuming the other has it covered.

None of the mistakes below are exotic. There is no zero-day in this post. Each one is a reasonable-sounding belief that used to be true, or that stays true in IT and quietly stops being true the moment you walk through the door onto the floor. We find them in fabrication shops, food processors, and injection moulders across the state, including plants that already spend real money on manufacturing IT and security.

If you want the build order rather than the diagnosis, our guide to manufacturing cybersecurity in Texas covers the controls and a 90 day sequence. This post is the part that comes first, which is finding out which of your assumptions is wrong before you spend anything.

What OT/IT security actually means on a plant floor

OT/IT security is the practice of defending the plant network and the business network as 1 attack surface instead of 2 budgets. Operational technology runs the physical process. Information technology runs the business around it. Once those 2 touch, and in nearly every Texas facility they already do, an intrusion anywhere becomes a production risk everywhere.

There is a second difference that matters more than the acronyms. In IT, the worst outcome is that data gets stolen or destroyed. In OT, the worst outcome is that a machine does something physical it should not, with a person standing next to it. That is why controls engineers are conservative about change, and why an IT team that opens with patch windows gets nowhere. Both sides are being rational. They are optimising against different worst cases, and nobody ever wrote that down.

Mistake 1. Believing the plant network is still air gapped

Network cable running from an office server rack through a doorway into an industrial control cabinet on a factory floor

Nobody bridged the 2 networks on purpose. It accreted. ERP wanted live production counts, so somebody opened a path. The OEM wanted remote diagnostics on a new cell. A vendor dropped a cellular modem on a skid so their engineer would not have to drive to Beaumont every time a sensor drifted. Each of those was a good decision in isolation, approved by someone reasonable, and none of them got added back to the diagram.

Dragos lists the air gap first among its top 5 ICS cybersecurity myths, and it stays on that list year after year for a reason. The belief is not dishonest. It accurately describes the plant as commissioned. It just stopped describing the plant after roughly the 40th change order.

The fastest way to test this one is to ask for the current control network diagram and look at the date in the corner. If it predates your last line expansion, you already have your first finding and it cost you nothing.

Mistake 2. Assuming nobody would bother targeting a shop this size

This one comes up in almost every first conversation, usually phrased as a question. Why would anyone come after us? The honest answer is unsatisfying. Usually nobody did. A crawler found a device, a credential worked, and the payload never asked what you make.

The volume tells the story. The IBM X-Force Threat Intelligence Index 2026 put manufacturing at 27.7% of all incidents in 2025, the highest share of any sector for the fifth consecutive year. Over the same period Dragos tracked 119 ransomware groups hitting roughly 3,300 industrial organisations, up from 80 groups the year before, with attacks rising 64% year over year and manufacturing making up more than two thirds of the victims.

You are not being singled out. You are being enumerated. That distinction matters because it changes what defence looks like. Defending against a determined adversary who wants your specific plant is expensive and rare. Falling off an automated target list is cheap and immediate, and it is most of the benefit.

Mistake 3. Trusting the HMI screen to tell you the truth

Plant operator in safety glasses reading normal-looking gauge values on an industrial HMI touchscreen terminal

This is the assumption I would most like plant leaders to drop this year, because the evidence against it is recent, official, and specific.

In joint advisory AA26-097A, originally published in April 2026 and revised on July 22, 2026, CISA, the FBI, the EPA and several partner agencies described attackers exploiting internet-exposed programmable logic controllers from Rockwell Automation, Schneider Electric and Siemens across US infrastructure. The part worth reading twice is what they did once inside. They downloaded malicious project files that kept the normal downstream logic intact while inserting modified add-on instructions that disabled safety shutdown and alarm functions. Then they manipulated the data shown on HMI and SCADA displays, so equipment could run in unsafe conditions without anything appearing wrong to the operator watching it.

No zero-days were involved. The controllers were reachable from the internet and the actors connected using ordinary engineering software, the same way an authorised technician would.

So here is the uncomfortable reframe. The screen is not a sensor. It is a rendering of what the controller reports, and the controller is the thing that was changed. If your only detection strategy for the plant is an experienced operator who would notice something off, your detection strategy is the exact thing the attack was designed to defeat. Keep offline baselines of controller logic and diff them on a schedule. Leave physical mode switches in RUN outside supervised maintenance. And make sure at least 1 alarm path does not originate from the box you are trying to verify.

Mistake 4. Treating OT security as the controls vendor’s job

Research by Cyolo and the Ponemon Institute, based on a survey of 1,056 security professionals running OT environments, found that 71% say IT or IT and OT together are responsible for securing OT. Then it found that 37% report little or no collaboration between those teams, and 19% say the 2 groups discuss OT security only when an incident is already underway.

The same research found 73% permit third-party access to OT, averaging 77 third parties per organisation. Sit with that number for a second. 77. Ask your integrator what happens to an engineer’s plant credentials the week after they leave the company. Most contracts do not say, and most people have never asked.

I want to push back on one common version of this complaint though. Plenty of integrators are genuinely good at security, and blaming them is lazy. The problem is not competence, it is scope. Their contract covers their equipment and their commissioning, not your network as a whole, and the boundary between those 2 things is precisely where incidents live. Nobody is failing. The gap simply belongs to nobody, which is the same thing as belonging to you.

Mistake 5. Pointing standard IT security tools at the control network

Aging engineering workstation computer on a metal bench next to a wall-mounted PLC control cabinet in a plant

This is where well-meaning IT teams do the most damage. Not through carelessness, through thoroughness. Running a standard authenticated vulnerability scan across a flat VLAN is a routine Tuesday in IT. Run the same scan across a control VLAN and you can create a production incident before lunch.

NIST recommends passive network monitoring for OT specifically because it captures and analyses traffic without injecting packets, and it warns that active scanning can disrupt sensitive devices unless it has been tested in that exact environment. The full guidance is in NIST SP 800-82 Revision 3. Here is how the 5 habits that serve you well in IT translate onto a plant floor.

Standard IT practiceWhy it breaks in OTWhat to do on the plant floor instead
Authenticated vulnerability scanningProbes can overwhelm the limited processing capacity of older PLCs, corrupt memory on legacy RTUs, and trigger unpredictable behaviour on safety-related systems.Passive discovery from a SPAN port or network tap, using a protocol-aware sensor that fingerprints devices from observed traffic.
EDR agents on every endpointMany HMIs and engineering workstations cannot run an agent, and some vendor support agreements void support outright if third-party software is installed.Network-based detection for anything that cannot take an agent, plus application allowlisting on the hosts that will tolerate it.
Patch on a 30 day cycleOT patches need vendor qualification and usually a shutdown. Critical fixes that land within hours in IT can take 12 to 24 months to reach an OT asset.Compensating controls and virtual patching at the network layer, with each exception documented rather than quietly ignored.
Enforced password rotationShift crews share a login by design, and plenty of HMIs auto-login because a locked screen during an alarm is its own hazard.Per-person identity enforced at the jump host and the remote access broker, not at the panel in the middle of a run.
Ship every log to the SIEMModbus, S7comm and EtherNet/IP are not parsed by a general-purpose SIEM, so genuine OT events arrive as unclassified noise or never arrive at all.OT-aware sensors that speak the control protocols, feeding a monitoring service that knows what normal looks like for your process.

The pattern across all 5 rows is the same. The IT control is not wrong, it is just aimed at the wrong failure mode. Swap the mechanism, keep the intent.

Mistake 6. Assuming cyber insurance covers a stopped line

Most manufacturers we meet believe they have this covered because they renewed a cyber policy and answered the MFA questionnaire honestly. Coverage for a halted production line is a different question, and it turns on 2 clauses that sit in 2 different policies.

Cyber policies commonly exclude physical damage. Property policies commonly exclude cyber-triggered perils. When malicious code alters how a physical asset behaves, the resulting loss can land in the gap between them, which the insurance industry calls the silent cyber problem. As one 2025 legal analysis of physical property damage from cyber incidents puts it, many cyber policies explicitly exclude physical property damage on the assumption that property policies will respond, while traditional property policies were drafted without cyber-induced physical damage in mind at all. Affirmative cover for cyber-triggered physical damage and the business interruption that follows does exist, but it is a specialist product you have to ask for, not a default sitting inside a standard renewal.

I am not a broker and this is not advice about your specific policy. It is a prompt to go read 2 paragraphs. The physical damage exclusion in the cyber policy, and the cyber exclusion in the property policy. If both say what they usually say, put the question to your broker in writing. Who pays for 9 days of stopped production?

That number is not hypothetical. Nucor halted production at several sites in May 2025 while it contained a cyber incident. Jaguar Land Rover paused manufacturing into the autumn of 2025 before a phased restart. Fairlife stopped US operations in July 2026. Research puts average lost production for a manufacturer hit by ransomware at close to 12 days, which is worth setting against your own figure for the cost of IT downtime before you decide the premium is not worth it. If the worst does happen, what you do in the first 72 hours shapes most of the outcome.

Mistake 7. Reading a quiet year as proof that OT security is working

Dragos measured the industry-wide average dwell time for ransomware in OT environments at 42 days. Organisations with comprehensive OT visibility detected and contained the same class of incident in an average of 5 days.

42 days is 6 weeks of somebody quietly learning your process before they touch anything. That is not a smash and grab, it is reconnaissance on a schedule. And it explains why a quiet year proves so little. Absence of alerts from a network that has no sensors on it is not evidence of safety. It is an absence of sensors.

Dwell time is the more honest metric because it measures the thing you can actually move. Prevention is binary and mostly outside your control. Detection speed is a dial, and the gap between 42 days and 5 days is the entire difference between an incident and a shutdown.

What all 7 mistakes have in common

Every one of them is a belief that was accurate at some point and never got re-tested. That is the actual problem. Not ignorance, and not budget. A plant runs for 15 years, absorbs 200 small changes, and carries forward a mental model built on day 1. Here is the short version, with the check that disproves each one.

The beliefWhat we usually find insteadHow to check it yourself
The control network is air gappedSeveral undocumented paths added for ERP data, OEM diagnostics, or a vendor’s cellular modem on a skid.Compare the network diagram’s date against your last line change.
We are too small to be a targetAutomated scanning that never evaluated your size, your sector, or your revenue.Scan your own public IP ranges from outside for anything answering on control protocol ports.
An operator would notice something wrongA screen that reports what the controller says, on controllers that can be reprogrammed.Ask when controller logic was last compared against a known-good offline baseline.
The integrator handles plant securityA contract scoped to their equipment, and standing access for dozens of third parties.Ask who revokes an integrator engineer’s access the week they leave that company.
Our IT security stack covers the plantTools that cannot install, cannot parse OT protocols, or would knock a PLC offline if pointed at it.Pick 1 HMI. Check whether an agent is installed and whether the vendor contract permits one.
Cyber insurance covers a stopped lineA physical damage exclusion in one policy and a cyber exclusion in the other.Read both clauses, then ask the broker in writing who pays.
No incidents means we are secureNo OT telemetry, and therefore no capacity to have detected one.Ask your monitoring provider to show you any OT event from the last 90 days.

A 1 week OT/IT self-test any Texas plant can run

Plant manager in a hard hat and a technician with a tablet cataloguing control panels along a production line

This is the exercise we walk through on a first visit, stripped down so you can run it without us. One task a day, none of which requires a maintenance window, a purchase order, or a consultant.

  1. Monday. Ask for the current control network diagram and note the date on it. Compare that date against your most recent line change or cell addition.
  2. Tuesday. List every remote access path into the plant. Vendor VPNs, cellular modems on skids, remote desktop tools, anything a controls engineer uses from home. Count them, then count how many require multi-factor authentication.
  3. Wednesday. Look at yourself from outside. Check your own public IP ranges for anything answering on 502, 102, 44818, 2222 or 22, and do it from a connection that is not on your network.
  4. Thursday. Pick 1 engineering workstation and 1 HMI. Write down the operating system version, the last patch date, whether an endpoint agent is installed, and what the vendor support agreement says about third-party software.
  5. Friday. Find out where controller logic backups live and when one was last restored to prove it works. A project file on the integrator’s laptop is not a backup.
  6. Monday after. Ask whoever monitors your environment to show you one OT event from the last 90 days. If they cannot produce one, establish whether that is because nothing happened or because nothing is watching.
  7. Tuesday after. Read the 2 insurance clauses. Physical damage in the cyber policy, cyber in the property policy.

Seven tasks, and not one of them touches a control system. What it does require is 7 uncomfortable conversations, which is the real reason this exercise usually goes undone. If more than 3 of those questions come back without a clear answer, you have your priority list and you did not need an assessment to find it.

For defence suppliers the same groundwork feeds directly into CMMC and NIST 800-171 compliance, and for smaller Texas manufacturers it maps closely onto what the state’s safe harbour law expects, which we covered in our Texas SB 2610 checklist. Doing the work once and using the evidence twice is how mid-sized plants keep this affordable.

What changes when OT and IT are defended as 1 environment

Security operations centre analyst monitoring network traffic dashboards and an industrial process diagram at night

Uprite has supported Texas businesses since 1999, with field teams in Houston, Dallas, Austin and San Antonio and monitoring that runs through our own operations centre around the clock. For plants that last part matters more than it sounds, because third shift is the shift nobody is watching and 42 days of dwell time has to start somewhere.

What actually changes is narrower than most vendors suggest. You get an accurate list of what is connected. You get one enforced boundary between the business network and the control network instead of an aspiration. You get alerting that recognises a control protocol. Beyond that, most of the work is unglamorous and procedural, which is a big part of why it gets postponed.

A growing Texas manufacturer came to us with failing on-premise servers, end-of-life hardware and a cyber insurance application it could not honestly complete. The write-up is in our manufacturing IT modernisation case study, and the transferable lesson is the order of operations. Insurance was the forcing function, not the goal, and once the underwriter’s controls were real they also answered most of what the company’s largest customer asked for months later.

Coverage runs metro by metro, so start where the facility sits. We run manufacturing IT services in Houston for the Gulf Coast fabrication and petrochemical corridor, manufacturing IT in Dallas for DFW electronics and aerospace suppliers, and manufacturing IT in San Antonio for South Texas plants and defence-adjacent shops. The wider stack sits on our cybersecurity services page, and plants that need continuous detection rather than a project usually want managed security services.

One honest caveat before you call anyone, including us. If you have a capable internal IT lead, you may not need a full managed contract. What most 1 to 3 person plant IT teams genuinely cannot staff is a 24 hour watch, and co-managed arrangements exist for exactly that. Texas manufacturing keeps expanding, according to the Dallas Fed’s Texas Manufacturing Outlook Survey, and growth is what brings the customer security questionnaires that turn this from a technical topic into a commercial one.

Questions Texas plant leaders ask us about OT/IT security

Who should own OT security, IT or the plant floor?

Someone specific, named in writing. Shared ownership without a named owner is the failure pattern. Research from Cyolo and Ponemon found 71% of organisations assign OT security to IT or to IT and OT jointly, yet 37% report little or no collaboration between those teams. In practice the model that works is a single accountable owner on the IT side for the boundary and the monitoring, with the controls engineer holding veto power over anything that touches the process. Write down who can authorise stopping a line, and do it before 2 in the morning.

How do we inventory the control network without knocking a PLC offline?

Passively. Mirror traffic from a SPAN port or a network tap into a protocol-aware sensor and let it identify devices from what they already say to each other. Active scanning is the thing to avoid here, because probes can overwhelm the limited processing capacity of older controllers. NIST SP 800-82 Revision 3 makes the same recommendation, and in most plants a passive pass surfaces equipment nobody knew was connected within the first week.

Can an attacker really change what an operator sees on the HMI?

Yes, and it has been documented in a US federal advisory. In AA26-097A, CISA and partner agencies described actors manipulating data on HMI and SCADA displays so equipment could run in unsafe conditions without alerting operators, alongside modified controller logic that disabled safety shutdown and alarm functions. Treat the screen as a report from a system that may itself have been altered, not as ground truth.

Will cyber insurance pay for production we lose to a cyberattack?

Check, because the honest answer is that it depends on 2 exclusions rather than on your cyber policy alone. Cyber policies frequently exclude physical damage and property policies frequently exclude cyber perils, so a cyber-triggered event that damages equipment or halts a line can fall between them. Affirmative cyber-physical cover is available but it is a specialist product you have to request. Ask your broker in writing rather than assuming.

What does OT/IT convergence actually mean for a mid-sized Texas plant?

It means the 2 networks already exchange data, so they now need 1 security model. Convergence is not a project you approve, it is a condition you inherited from ERP integrations, remote diagnostics and IIoT sensors added over the past decade. The practical consequence is that a phishing email in the front office and a stopped line on the floor are no longer separate risks on separate registers.

We have never had an incident. Does that mean our OT security is working?

Not on its own. Dragos put average ransomware dwell time in OT environments at 42 days industry-wide, against 5 days for organisations with real OT visibility. If nothing is monitoring the control network, a quiet year and an undetected intruder look identical from where you are sitting. Establish whether you have evidence of safety or just an absence of sensors.

If you cannot name every device on your control network this afternoon, you are in ordinary company and it is a solvable problem. Talk to our team about an OT and IT security assessment. We will map what is actually connected, tell you plainly which gaps are urgent and which can wait until your next planned shutdown, and hand you the findings whether or not you hire us.

About Author