Most cybersecurity vendors approach operational technology the way a restaurant chain approaches a new city: find the right location, run the same playbook, open the doors. The menu works everywhere. The process scales.
It does not work that way in OT security. The environment is different. The buyer is different. The threat model is different. The product requirements are different. And the vendors who learn this only after they have invested eighteen months in a sales cycle tend to learn it expensively.
I spent years at Lumension Security managing endpoint security and data protection products deployed across more than two million endpoints globally. A portion of those deployments were in enterprise IT environments that behaved the way enterprise IT environments are supposed to behave. A different portion were in nuclear power plants, water treatment facilities, factory floors, and government installations where almost nothing about the deployment worked the way we expected.
What follows is what I learned in those environments, written for product and go-to-market leaders at security companies who are considering the OT market and want an honest accounting of what it requires.
The Buyer Is Not Who You Think
In enterprise IT security, the buying decision flows through a recognizable cast: CISO, VP of Security, sometimes a security architect, eventually procurement. You learn to sell to this group. Your marketing speaks to this group. Your product is evaluated by this group.
In OT environments, the organizational structure is different and the authority map does not transfer.
The controls engineer who operates the SCADA system has more practical authority over what software runs in that environment than any CISO. The plant manager cares about uptime and production targets. The site reliability engineer worries about whether your agent will cause any measurable latency in process control timing. None of these people think about security the way a CISO does. Their job is to keep a physical process running continuously and safely. Security is a constraint on that goal, not the goal itself.
In many industrial organizations, IT and OT are organizationally separate with genuinely different reporting lines. The CISO, if one exists, may have formal responsibility for OT security posture but no operational authority over the systems themselves. The OT team reports to operations leadership. When a security vendor sells to the CISO and then tries to deploy in OT, they encounter a second buying process they were not prepared for.
The practical implication for go-to-market: you need OT-specific sales motion with people who can have credible conversations with plant engineers, not just security buyers. References in this market come from operations people talking to operations people. A CISO reference from a bank does not open doors at a water utility.
The Procurement Process Has Different Physics
Enterprise security procurement is not fast, but it follows a recognizable pattern. Proof of concept, security review, legal, procurement, signed order. Thirty to ninety days for a motivated buyer, longer for complex organizations.
OT procurement operates on different timescales and with different requirements, and the differences are not just bureaucratic friction. They are structural.
Change control boards govern what software is permitted to run in OT environments. These boards meet infrequently, sometimes monthly, sometimes quarterly. Every change to a production OT system requires formal approval, documented testing, and sign-off from engineering and operations leadership. The process exists because the consequence of an unvalidated change in a SCADA environment is not a degraded user experience. It is a process upset, a safety event, or a production shutdown worth millions of dollars per hour.
In regulated environments the requirements are more specific. Nuclear facilities operating under NRC jurisdiction must comply with 10 CFR 73.54, which requires documented analysis of any software that touches systems with safety significance. Utilities subject to NERC CIP standards face mandatory vendor risk assessments, documented testing requirements, and compliance reporting obligations. Government facilities may require vendor security clearances before on-site access is permitted.
A thirty-day proof of concept is not a realistic offering in these environments. A six-month pilot, fully documented and run through change control, is closer to what a serious OT customer looks like. Product leaders who size their sales cycle and customer acquisition cost on enterprise IT assumptions will consistently underestimate what OT sales actually costs.
The Technical Environment Is Not Enterprise IT With Pipes
The phrase "OT environment" can suggest something that resembles enterprise IT but with different equipment. The reality is more significant than that.
Air-gapped networks are real and common in high-consequence OT environments. The security architecture that prevents remote access to a nuclear control system is not a configuration choice. It is a regulatory requirement. A security product that phones home to a cloud backend for signature updates, threat intelligence, or policy management does not function in this environment. It requires a fundamentally different architecture: offline update mechanisms, local management infrastructure, sneakernet-compatible update distribution.
The operating systems in active production OT environments include versions that enterprise IT abandoned long ago. Windows XP systems running HMI software are not unusual. Windows Server 2003 instances managing historian databases are not unusual. These systems cannot be patched on a normal cadence. The controls vendor who built the SCADA software certified it against a specific OS version, and upgrading the OS means re-certifying the application. That re-certification is expensive, time-consuming, and creates downtime risk. So the OS stays.
Your endpoint agent must run on these systems without causing any measurable effect on performance or timing. Process control software operates with real-time timing requirements. An agent that consumes unexpected CPU or introduces latency into system calls can cause control system faults. This is not hypothetical. It happened during evaluations we ran, and it ended vendor relationships immediately.
Scanning in OT environments requires specific care. Active network scanning that is routine in enterprise environments can flood OT network segments with traffic that overwhelms process control devices not designed to handle it. Passive monitoring is the required posture for anything touching operational technology networks. Vendors who bring active scanning tools to OT evaluations disqualify themselves.
Auto-remediation cannot be a feature in OT environments. In enterprise security, automatic quarantine of a compromised endpoint is a reasonable response. In OT, quarantining a node in a control network can take down a production line or trigger a safety system. Every remediation action in an OT environment must be a manual human decision made by someone who understands the operational context. Build this into the product design, not as an option but as the default.
The Threat Model Points at Different Outcomes
Enterprise security thinking is largely organized around data: protecting it, detecting when it leaves, recovering it when it is encrypted. The consequences of a breach are financial, regulatory, and reputational.
In OT environments, the consequences of a successful attack are physical. The goal of an adversary targeting an industrial control system is not to steal data. It is to manipulate a physical process, cause equipment damage, trigger a safety event, or disrupt production.
Stuxnet was not a data breach. Colonial Pipeline was not a data breach. The adversary goal in both cases was operational disruption and physical consequence.
This changes what detection and response look like. The indicators of compromise that matter in OT are process deviations, unauthorized configuration changes to PLCs, unexpected communication between control system components, and out-of-range process values. These are not concepts that map neatly onto enterprise endpoint detection.
It also changes the tolerance for false positives. In enterprise security, a false positive generates an alert that an analyst investigates and closes. In OT, a false positive that triggers an automated response or an alert that causes an operator to take the wrong action can shut down a production process. The cost of a false positive is not analyst time. It is potentially hours of production downtime at facilities where production downtime is measured in significant dollar amounts per hour.
Product leaders who define detection quality in terms of false negative rate without equally weighting false positive rate will build products that OT buyers reject, and they will hear "we cannot afford the alert volume" and not understand why.
What This Means for Your Product and Your Go-to-Market
If you are a security vendor evaluating OT as a market expansion, the honest starting question is whether you are prepared to build for it or whether you are prepared to market to it. The two are not the same.
Marketing to OT means updating your website, hiring a sales person with OT experience, and attending the right conferences. You will get into some evaluations. You will likely not close many of them because your product was not built for what evaluators discover during a pilot.
Building for OT means accepting that your cloud management architecture may need a significant offline-capable variant, that your agent must be certified compatible with the SCADA and DCS platforms that dominate industrial environments (Siemens, Rockwell Automation, Honeywell, ABB), that your update distribution model must work without internet connectivity, that your detection logic must be tuned for process-level anomalies rather than endpoint behavioral indicators, and that your professional services capacity must support multi-month change-controlled deployments.
The market rewards vendors who build for it. References in OT security travel through a small, interconnected community of plant engineers and operations leaders who talk to each other before they talk to vendors. A well-executed nuclear power plant deployment generates more qualified pipeline than any marketing program you can run. A failed deployment, or a deployment that disrupts operations, generates the opposite.
OT security is a real and growing market with underserved buyers and meaningful revenue. It is not a market you enter with the enterprise IT playbook and a new brochure. The vendors who succeed in it treat it as a distinct product and go-to-market problem from the start, not as an extension of what they already built.
Zed Foundry works with cybersecurity companies on product strategy, go-to-market planning, competitive intelligence, and product marketing. Engagements are led directly by the principal. Get in touch →