Understanding the Vendor Partnership Model - IT Org Now OT Curious Part 2

[This is the second blog in our series focused on IT orgs that are now OT curious, where we examine the differences between IT and OT cybersecurity. The first blog in this series discussed  how IT gives defenders a solid practical foundation on which to enter OT environments, but key perspective and mindset shifts are required.]

This is where OT diverges significantly from IT in ways that directly impact how you approach security.

In IT environments, you typically have significant autonomy. You work with vendors for products and services, but you maintain control over your environment. You can evaluate and deploy security tools, push patches, test new solutions, and make changes as needed to protect your systems.

In OT environments, the vendor relationship is fundamentally different, and understanding why is crucial to being effective in this space.

Maintenance and support contracts in OT don’t just cover hardware or software licenses. They cover the integrated package: devices, configurations, and operational functionality as a unified system. This is because these aren’t generic deployments. They’re custom-engineered solutions where every component works together to control physical processes safely and reliably.

This creates an important dynamic: if you install unauthorized patches, deploy security tools that haven’t been validated for your environment, or make changes outside the approved process, you can void your support/maintenance contract.

And the consequences extend beyond just losing vendor support: 

• Financial liability (full responsibility if something fails) 
• Insurance considerations (operating outside vendor support may affect risk assessments and premiums) 
• Regulatory compliance (frameworks like NERC CIP require documented change management processes that often involve vendor coordination)

Now, we know what some of you are thinking. “Why can’t vendors just approve patches and updates quickly? We’re all trying to improve security here.”

It’s a fair question, and the answer teaches us something important about OT environments.

Why Vendor Testing and Certification Takes Time

Remember when we said each OT site is genuinely unique? This isn’t just an interesting fact… it has profound implications for patch management, software deployment, and security updates.

To properly test and certify a patch or update for your environment, vendors need to validate it against your specific configuration. This means:

• Creating a digital twin or test environment that mirrors your setup
• Sometimes, building physical lab environments with actual equipment
• In some cases, working with you to develop co-owned testing environments
• Examining all the edge cases specific to your operational parameters
• Validating that updates won’t interfere with your custom control logic
• Ensuring changes won’t create cascade effects in your integrated systems

This process genuinely can take months, maybe years. Not because vendors don’t prioritize security, but because they’re validating against your unique configuration to prevent introducing operational risk.

Even if a patch works perfectly in a lab environment, the vendor needs to verify it will work reliably in your environment, with your specific configuration, running your particular processes. Until they can do that validation, they can’t certify it for your deployment.

It’s worth noting that, generally, many vendors do maintain lists of pre-approved software and patches that have been validated across common configurations. But the fundamental principle remains: changes need validation because the stakes of getting it wrong are so high.

This represents a significant shift from IT’s “move fast and iterate” culture. In OT, moving fast without proper validation can mean breaking physical systems, disrupting critical operations, or creating safety issues. The caution isn’t about resistance to change. It’s about respecting the reality that these systems control physical processes where failures have real-world consequences.

Why “Simple is Robust” Is Actually Brilliant Engineering

Let’s talk about why PLCs and other OT devices might seem “insecure” from an IT perspective and why that perception misses something crucial about their design.

When IT security professionals first encounter PLCs, they often notice what appears to be missing: limited logging capabilities, minimal IP stack functionality, no ability to install agents. The initial reaction is sometimes, “This device seems incredibly basic for something so critical.”

Here’s what’s important to understand: Every one of those characteristics is an intentional design choice.

PLCs are purpose-built to be resilient and reliable over decades of continuous operation. They’re underclocked or engineered to reduce heat and extend component life. They use minimal system resources to ensure deterministic behavior. They run real-time operating systems specifically designed to execute control logic with microsecond precision, consistently, for years without requiring reboots.

Why this matters: These devices often operate in harsh environments where a traditional server or workstation simply couldn’t survive. Extreme temperatures, high humidity, vibration, electromagnetic interference, etc. They need to make the same control decisions, with the same timing, whether it’s day one or year twenty of operation.

This is actually remarkable engineering. The simplicity isn’t a limitation. It’s what enables reliability and resilience at a scale IT systems rarely need to achieve.

But this intentional simplicity does create unique security challenges that require different approaches than modern IT security.

Understanding the “Active” (Scanning, Blocking, etc.) Challenge

Here’s a concrete example that illustrates why OT security requires such a different mindset.

In IT environments, active scanning is routine and essential. You use tools like Nessus to discover assets, identify vulnerabilities, and maintain security visibility. It’s part of the fundamental security hygiene.

In OT environments, active scanning can cause operational issues, and understanding why teaches us something important about these systems.

Here’s what can happen: Imagine you have a PLC configured to communicate using Modbus protocol. However, the PLC hardware also has the capability to speak other protocols like DNP3, CIP, and perhaps DHCP, even though they’re not being used in this deployment.

When a scanner probes the PLC on one of these unused protocols, the PLC opens a network connection to respond, even though it’s not configured to actually communicate via that protocol. On a modern IT system with a full operating system, unused connections would be efficiently managed and closed. But these real-time systems are designed differently that open connection consumes memory resources, and it doesn’t automatically close the way it would on a more complex system. Causing possible resource contention.

Now that PLC, which was running optimally for its control functions, is diverting resources to handle network connections it was never meant to maintain. If enough probes hit the device multiple protocol checks, SYN floods from aggressive scanning, it can consume enough resources to impact performance or even cause the PLC to fail or rollover.

And here’s where cyber meets physical: that PLC might be controlling generation equipment, managing a critical manufacturing process, or handling safety systems. A reboot doesn’t just mean “system temporarily unavailable”. It can mean production stops, safety systems momentarily disengage, or equipment doesn’t receive the control signals it needs.

This isn’t a theoretical concern. This scenario has happened in real environments, with real consequences.

The lesson here isn’t “OT security is impossible.” It’s “OT security requires different methods.” Passive monitoring, careful architecture reviews, strategic placement of security tools, testing during planned maintenance windows, these approaches provide visibility and security without risking operational impact.

And before you think we’re swearing off active scanning… we’re not. The same methodologies can be applied there. Carefully review the architecture. Work with engineers and operators to identify timing, expected protocols, etc. In some cases, it may not be possible. However, in many cases, it can be done carefully, although not necessarily continuously. 

It’s about adapting our security practices to respect the operational reality of these environments.

Operators Are Engineers. And Their Expertise Is Invaluable

Let’s address something that’s absolutely critical to success in OT security: understanding and respecting the expertise of the operators you’ll work with. They know their environments better than anyone else.

There’s sometimes a perception that operators are “less technical” because they don’t discuss systems in terms of IP addresses, protocols, and firmware/software versions.

This perception is completely off base, and it’s important to understand why.

Operators are operational engineers. They’re deeply technical. They just speak a different technical language, one that’s focused on physical processes, system interactions, and real-world outcomes.

When an IT security professional looks at a control system, they might see: – 10.10.8.50 – Modbus TCP on port 502 – Firmware version 3.2.1 – Last patch applied six months ago

When an operator looks at the same system, they see: – “This is the safety interlock controller for Reactor 2” – “It monitors the relationship between the cooling system and the pressure relief valve” – “If this fails, we have a specific sequence of manual interventions that need to happen within 45 seconds” – “Last time this faulted was three years ago during that lightning storm, and here’s exactly what happened”

Operators understand how systems interact in ways that documentation often doesn’t capture. They know the tribal knowledge. The quirks, the workarounds, the things that happen in practice versus what the manual says should happen. They’ve been there for the 2 AM emergency situations. They understand the real-world consequences of changes in a way that’s hard to learn from any textbook or certification.

This knowledge is absolutely invaluable to security work.

When an operator tells you that a particular change needs to wait for the planned maintenance window in six months, they’re not being resistant to security. They’re sharing hard-won knowledge about operational risk, often learned through direct experience and following vendor policy. When they express concern about a proposed security control, they’re typically thinking through operational scenarios and edge cases that might not be obvious from a pure security perspective.

The most effective OT security professionals we’ve worked with, the ones who really make an impact, are the ones who build genuine partnerships with operations teams. They take time to learn the operational language. They ask questions. They listen. They respect that operators bring a form of expertise that’s different from but equally valuable to their own technical and security background.

It’s like working with specialists from different but complementary disciplines. A network engineer and a database administrator are both deeply technical, but they think about systems from different perspectives, use different terminology, and bring different insights. Neither is “more technical”, they’re technical in different ways that both matter.

The same is true for IT security professionals and OT operators. Both bring essential expertise. The magic happens when that expertise comes together in partnership.

Stay tuned for Blog 3 in this series, where we’ll talk about real-world consequences.