Why the factory floor needs a different security rulebook
Cybersecurity best practice is built around actions that can become operational risks inside a factory. Patching a vulnerable system, scanning an endpoint or isolating a compromised device may be routine in enterprise IT, yet the same response can interrupt production or break software that has been validated around a particular machine. The challenge for manufacturers is not whether OT should be secured, but how to protect equipment without treating uptime as collateral damage.
Terence Liu, CEO of TXOne Networks, argues that manufacturers need an OT version of cybersecurity rather than a direct copy of enterprise practice. Security tools designed for office and cloud environments often assume that devices can be updated, restarted or replaced without threatening the operation they support. Production assets challenge those assumptions because the machine, its software and the process around it can remain tightly coupled for years.
“In an office, a laptop might be one, two or perhaps five years old before it is replaced,” Liu says. “In an OT environment, an asset can be 10, 20 or 30 years old. The computing power and operating system can be completely different, so it is not that IT cybersecurity does not apply to OT. The technology that works in an IT environment may simply not be suitable for the OT environment.”
Legacy changes the security equation
That mismatch is visible at Valmet, a Finnish process automation company whose distributed control systems can remain in service for around 15 years while the Windows platforms beneath them may have a lifecycle of only five to seven years. The company spent almost two years testing endpoint protection before moving it into production, reflecting the validation burden created when security changes touch long-lived control systems. Valmet also combines endpoint protection with its own remote-service connections and monitoring, illustrating why legacy OT security must be designed around the operational lifecycle of the asset rather than a conventional IT refresh cycle.
Even when patches exist, the maintenance burden can quickly exceed the time available to apply them. Liu says some large environments contain one or two million vulnerabilities, while production teams still have limited windows for testing or intervention. Treating every missing update as equally urgent therefore leaves security teams with a queue they cannot realistically clear.
“We just have to accept that we cannot patch them all,” Liu says. “You need to know which vulnerabilities and which assets are more important. Once you know an asset or vulnerability is more critical, then you find a way to mitigate the risk. That might be virtual patching, shutting down an unnecessary service or making sure an endpoint cannot be reached from outside.”
The same operational logic applies to endpoint protection itself. A security update that causes an office PC to fail is disruptive, but the same failure on a control workstation can stop the process it supports. In highly sensitive areas, update policy therefore must reflect the consequences of getting the security change wrong as well as the risk of delaying it.
“In OT, aggressive is not always the best choice,” he says. “You may have one area that is less sensitive where you test the latest version, and once it is fully validated, the sensitive area can apply it. It is not just about the technology. It is also about how you run it.”
Protect the asset the way it can tolerate
A modern factory rarely contains one type of endpoint. It may include legacy Windows machines, embedded devices, engineering workstations, PLCs and equipment that cannot support any security agent at all. A uniform control therefore creates a false sense of consistency, because the same measure may be effective on one asset and impractical on the next.
The practical question becomes where a security control can safely sit. On some assets, direct endpoint protection is possible, while on others the machine itself must be left untouched and protection placed around it. That changes the mechanism without changing the objective: reduce the attack surface without introducing a new source of operational failure.
“For legacy and fixed-function devices, application whitelisting is a very cost-effective way to lock down the function of the device because it does not consume a lot of CPU,” Liu says. “For a more modern engineering workstation, endpoint protection can be very helpful. If that is not doable, then take a step back and use network protection, segmentation and virtual patching.”
The attack surface also extends beyond permanently installed machines. Engineering laptops, USB drives and maintenance tools can cross boundaries that are otherwise relatively isolated, while suppliers may need temporary physical or remote access to production assets. Terna, for example, introduced portable inspection for about 400 field operators, while specialty paper manufacturer Pixelle scans removable media before and after it is used.
Remote maintenance creates a similar governance problem because manufacturers need outside expertise without leaving permanent openings into production networks. Liu favors temporary, least-privilege access that is enabled for a defined maintenance task and then closed again, rather than reusable administrator credentials or continuously available connections. The principle is to make access possible without allowing convenience to become persistent exposure.
Security decisions must be operational decisions
Signature-based detection also has limits in an environment where industrial devices often perform narrow, predictable functions. An attacker does not necessarily need recognizable malware if a legitimate command can be abused to produce an unsafe or disruptive outcome. That makes expected operational behavior another source of security context rather than relying only on whether a file or process is already known to be malicious.
“If a hacker gets into OT and sends a command to shut down a PLC, is that malware? It is not malware. It is a legitimate PLC command,” Liu says. “The security solution must identify whether that is part of normal operation or abnormal behavior. You can only do that by learning what is normal.”
That makes cooperation between security and operations more important because neither side has enough context on its own. The security team may identify a vulnerable or compromised asset, but the production team understands what happens if it is isolated during a running process. Conversely, an operations team focused only on availability may leave known weaknesses untreated because the immediate production risk feels more tangible than the cyber threat.
“If the IT security guideline says you have to patch every system within 60 days, in OT that can be mission impossible,” Liu says. “You must refine the IT security guideline for OT, and that takes communication. The security team needs to know which machines are more critical, and when there is an incident, it needs to understand whether isolating a machine could interrupt a multimillion-dollar operation.”
AI raises the stakes on both sides of that equation. Attackers can use it to accelerate vulnerability discovery and automate parts of an intrusion, while defenders can use models to learn normal behavior and surface anomalies that signature-based tools may miss. Those defensive gains, however, depend on manufacturers having enough security practice and operational knowledge for AI to learn from in the first place.
“The number one enemy for a security vendor like us is not another security vendor. It is not even the hacker. It is inertia,” Liu says. “If an organization has not started the OT cybersecurity journey, there is no silver bullet that can keep it safe. You must build the practices and the experience first, and then AI can help you.”
For manufacturers, the implication is that OT security should not be judged by how closely it reproduces enterprise IT practice. A mature approach accepts that some machines cannot be patched quickly, some devices cannot carry an agent, and some incidents cannot be contained by simply disconnecting the affected asset. The stronger model is layered around operational reality, with controls selected according to what each asset can tolerate, and security decisions made with production consequences in view.

