Cybersecurity Evaluation Criteria for OT Vendor Bids

Adversaries targeting industrial control systems have moved past reconnaissance. They are now mapping control loops in detail, studying how a specific pump, valve, or safety interlock responds to manipulation. The old assumption that OT threats stay theoretical no longer holds. Dragos tracked 119 ransomware groups hitting 3,300 industrial organizations in 2025, up from 80 groups in 2024, a jump of 49 percent, and manufacturing absorbed the largest share of victims. Ransomware operators have learned what OT operators have always known: a plant that cannot tolerate downtime will pay to get it back. Add in the risk that 35.5 percent of breaches trace back to third-party access and 41.4 percent of ransomware attacks start the same way, and it becomes clear that a supplier relationship is itself a live attack surface, not a line item to file away after the contract is signed.

None of this fits neatly into a procurement checklist built for enterprise software. Evaluating an OT vendor's cybersecurity posture on IT terms, the terms most procurement teams already know, will miss exactly the failures that matter most in a plant, a substation, or a water treatment facility.

Where OT environments differ from IT in ways that break standard vendor evaluation

IT security ranks its priorities confidentiality first, then integrity, then availability. That ordering makes sense when the worst-case outcome is a leaked spreadsheet. OT flips it. Availability and safety come first, because a failure in an industrial control system isn't a data breach, it's a physical event, such as a turbine that doesn't stop, a valve that doesn't close, or a chemical batch that runs past its safe temperature.

This inversion creates a problem that IT-trained evaluators tend to miss entirely: a security tool that interrupts a process is not a minor inconvenience. It is a serious consequence in its own right. An endpoint agent that reboots a Windows server mid-patch is annoying in an office. The same agent rebooting a human-machine interface on a continuous-process line can trigger an unplanned shutdown that costs more than the breach it was meant to prevent.

Equipment age compounds the problem. OT hardware runs on operational lifecycles of 15 to 30 years, against the 3 to 7 year cycle typical of IT gear. A programmable logic controller installed in 2005 can still be running a critical process in 2030. Legacy devices aren't an edge case in industrial environments, they're the baseline population any vendor has to work with. Patching those devices on an IT schedule usually isn't possible either. Continuous-process plants often get one planned maintenance window a year, sometimes less, so vulnerabilities in the field persist because the operational calendar doesn't allow for anything else. Any vendor evaluation that assumes monthly patch cycles or always-on connectivity is evaluating the wrong environment.

The regulatory baseline procurement teams must build from in 2025-2026

IEC 62443 is the standard procurement teams should treat as the floor, not the ceiling, for OT vendor evaluation. It defines four Security Levels, SL1 through SL4, and organizes network defense around a zone-and-conduit model that segments a facility into logical groupings with controlled pathways between them. It also sets requirements for how vendors build products in the first place, extending to how those products perform once installed.

One distinction trips up a lot of procurement teams: Maturity Levels and Security Levels are not the same thing, even though both sit under the same standard. A Maturity Level certifies a vendor's development process, how they build software and manage risk internally. A Security Level certifies the capability of a specific product or system, out in the field. A vendor can hold a strong Maturity Level certification and still ship a product with a low Security Level rating for a given deployment. Bid language needs to ask for both, by name, or evaluators end up comparing apples to receipts.

IEC 62443-4-1, which governs secure product development process, functions as a prerequisite in practice. Certification programs such as ISASecure require vendors to hold, or concurrently pursue, 62443-4-1 certification (formally called SDLA, Security Development Lifecycle Assurance) before they can get their products certified under 62443-4-2. Vendors can apply for both at once, but a vendor with no 62443-4-1 certification and no plan to get one is a vendor asking to be evaluated on faith.

The regulatory ground has kept moving. In January 2025, ISA published the updated ANSI/ISA-62443-2-1-2024, the ISA edition of IEC 62443-2-1, which sets organization-wide cybersecurity management requirements rather than product-level ones. Two more additions are expected in 2026: IEC PAS 62443-1-6, which extends the 62443 series into IIoT territory, smart sensors, actuators, and cloud and edge environments that didn't exist when the original standard was drafted; and IEC 62443-6-2, a security evaluation methodology for supplier conformity. Procurement teams writing RFPs now should assume these are live requirements, not future ones.

CISA's Secure by Demand guidance as a bid evaluation tool

On January 13, 2025, CISA and 11 international partners, including the European Commission, published a joint set of 12 elements under the Secure by Demand banner. It's the most specific, most current checklist built for OT procurement that exists right now, and it should be read closely by anyone drafting a procurement document for vendor security requirements.

The framing behind it matters as much as the content: a product's security posture is a threat vector that follows the product into every environment it's deployed in, at every customer who buys it, not a compliance checkbox to tick off during due diligence.

A handful of the 12 elements carry the most weight in a bid evaluation. Configuration management is one of the elements with the most weight in a bid evaluation. Ask a vendor to demonstrate, not describe, how their product handles configuration controls and how fast a plant can recover from an incident.

Open-standard logging is another. Open-standard logging requires that product logging not be locked to proprietary formats, because a logging format tied to one vendor's tool is a logging format that doesn't talk to a SIEM. Secure communications matter too: products should protect traffic against unauthorized interception and tampering, including firmware or configuration pushes. The right question for a vendor is how they plan to work around implementation barriers in a live environment, not whether they claim compliance.

That's where phased implementation support comes in. A vendor whose product can only be secured in one all-or-nothing rollout, one that demands a production outage to implement, isn't built for how OT operators actually have to work.

The guidance also identifies high-value attack paths that bid evaluators should probe directly. Ask vendors, point blank, how their product defends those paths specifically, not in general terms. And the 12 elements aren't a substitute for IEC 62443, they're a companion to it. RFP language should embed specific Security Level requirements from 62443 alongside conformity requirements for any new OT equipment supplier.

Evaluation criteria for secure-by-design product architecture in OT bids

Guidance from EPA and CISA converges on a simple principle: buy systems that are secure by design and secure by default, not systems that need a security team to bolt protection on after installation. Security gaps in OT products frequently trace back to security never having been a primary design requirement in the first place, not a random failure of quality control.

For OT specifically, secure by design breaks into a few concrete asks. Hardened defaults mean no open ports that don't need to be open, no default credentials still active out of the box, no unnecessary services running before a customer has even configured the thing. Vendors should be able to document their default configuration state line by line. Least-privilege architecture means roles and permissions map to what a job actually requires, not what's administratively convenient, so an engineering workstation used for routine configuration changes has no path to reach a safety instrumented system.

Authentication needs to hold up without slowing down control. NERC CIP-003-9 expands governance requirements for low-impact BES Cyber Systems in the electric sector, but the harder engineering question is whether any authentication layer adds latency that a real-time control loop can't absorb. Firmware integrity matters just as much: ask a vendor to walk through their actual signing and verification process for firmware updates, and confirm that one exists.

Vulnerability disclosure is where a vendor's real posture becomes visible, whether they admit it or not. Dragos found that 25 percent of ICS-CERT and NVD vulnerability entries carried incorrect CVSS scores, and 26 percent of advisories came with no patch or mitigation attached. That's a measurable gap between vendors who take disclosure seriously and vendors who file paperwork to check a box. Ask directly for a vendor's disclosure policy, how often they issue advisories, and their track record across NVD entries tied to their own products. A vendor whose products show up repeatedly in CISA's Known Exploited Vulnerabilities catalog without a timely fix isn't just shipping a risky product, but a risky supplier, full stop.

Self-attestation doesn't settle any of this. IEC 62443-4-1 gives evaluators a verifiable proxy for a vendor's development process; certification programs such as ISASecure require vendors to hold it before their products can be certified under 62443-4-2. A vendor's own claim that they "follow secure development practices" carries no more weight than a vendor's claim that their product has never been hacked.

Asset discovery, OT-native visibility, and what vendors must demonstrate before monitoring claims are accepted

Fewer than 10 percent of OT networks have real, comprehensive visibility and monitoring in place. That single figure explains most of the gap between what vendors claim and what they can actually show. Plenty of vendors will point to an asset inventory spreadsheet and call it visibility. An inventory taken once, sitting untouched for six months, is not the same thing as real-time awareness of what's actually on a network and what it's doing.

Comprehensive visibility has to cover managed and unmanaged assets across IT, IoT, OT, and IoMT categories, including legacy devices running proprietary protocols that standard IT security tools were never built to see. Discovery methods matter as much as coverage: passive techniques, network traffic analysis, protocol-aware passive scanning, are the only safe way to build a picture of a legacy industrial controller or DCS node, because active scanning can crash or destabilize equipment that was never designed to handle unexpected queries. Correct classification also has to go past IP and MAC address enumeration, down to device type, vendor, firmware version, and communication role. And the whole inventory has to stay current: device additions, firmware updates, and configuration drift all need to show up in near-real time, not at the next scheduled audit.

Protocol support is the clearest qualification test available to a procurement team. A vendor should be able to demonstrate parsing for whatever industrial protocols actually run in the environment being evaluated, Modbus, DNP3, EtherNet/IP, PROFINET, IEC 61850, OPC-UA, and the rest. Generic IT packet capture tools, however well they perform on an enterprise network, do not count as OT visibility, because they weren't built to understand what these protocols are actually saying.

Remote access adds another layer of complexity that's easy to underestimate. Research from Claroty, cited in the Elisity vendor comparison, found that 55 percent of OT environments now run four or more remote access tools at once, and each one represents a separate discovery and monitoring problem a vendor's platform has to solve for. Ask any vendor under evaluation how their platform handles overlapping remote access paths specifically, because a platform that only sees one tool clearly while the other three sit in a blind spot isn't giving a plant the visibility it's paying for.