What should procurement teams ask before selecting an OT segmentation vendor?

Why This Matters for Security Teams

ot segmentation is often bought as a security product, but procurement is really selecting an operating model. The wrong vendor can leave critical assets exposed, create blind spots between IT and OT, or add tooling that cannot be maintained in plant conditions. Procurement teams need to test whether a platform actually reduces lateral movement risk, supports recovery, and produces evidence that auditors and engineers can use. The most useful questions focus on enforcement points, coverage, dependencies, and the quality of proof the system generates.

This aligns with the control intent behind the NIST Cybersecurity Framework 2.0, especially where identify, protect, detect, and recover capabilities depend on knowing where trust boundaries exist and how they are enforced. In OT, segmentation failures are rarely abstract. They usually emerge after a plant expansion, a remote support change, or an incident that forces teams to discover which assets were never actually segmented. In practice, many security teams encounter this only after an outage, a safety event, or a failed recovery exercise has already exposed the gap rather than through intentional design.

How It Works in Practice

A good procurement review should translate vendor claims into operational questions. First, determine what the product enforces on: switch ports, firewalls, agents, gateways, virtual policy layers, or passive monitoring with manual change workflows. Second, confirm how much of the estate it can cover, including legacy controllers, unmanaged assets, remote sites, and vendor-maintained equipment. Third, examine what infrastructure is required to run it, because some products depend on heavyweight collectors, always-on central services, or network redesigns that change deployment risk.

OT environments also need evidence, not just policy statements. Ask what logs, maps, exceptions, and change records the platform produces, how those artifacts support incident response, and whether they are exportable into SIEM or GRC workflows. If the environment has safety constraints, procurement should ask how the vendor handles fail-safe behavior, maintenance windows, and rollback when a rule set blocks legitimate control traffic. Guidance from CISA Zero Trust Maturity Model is helpful here because it reinforces that segmentation is about policy enforcement and visibility, not just perimeter placement.

• Map every enforcement point to a real OT asset class, not just to a network diagram.
• Verify whether coverage includes unmanaged, legacy, and intermittently connected systems.
• Test what happens when policy is wrong, incomplete, or delayed.
• Confirm whether evidence supports audits, incident review, and recovery planning.
• Check who owns day-two operations, rule tuning, and exception handling.

For environments with remote service access, procurement should also ask how identity, session control, and privileged pathways are handled, because segmentation that ignores access paths can leave the real attack surface untouched. Current guidance suggests that network controls and identity controls should be reviewed together rather than treated as separate projects. These controls tend to break down when segmented zones span mixed-vendor legacy equipment and production uptime rules prevent timely rule validation, because change control becomes slower than the environment’s actual risk.

Common Variations and Edge Cases

Tighter segmentation often increases deployment complexity, operational overhead, and change-management burden, requiring organisations to balance isolation against maintainability. That tradeoff is especially sharp in brownfield OT, where long-lived devices, fragile protocols, and narrow maintenance windows make aggressive policy enforcement hard to sustain. Best practice is evolving, and there is no universal standard for how much segmentation should be automated versus manually governed in every plant.

Procurement teams should treat full automation claims with caution. Some vendors excel at visibility and recommendation but rely on human approval for enforcement, while others promise closed-loop policy changes that may be too risky for safety-critical operations. The key question is whether the vendor can show controlled rollout, rollback, and exception handling across the entire lifecycle. Where third-party maintenance is common, ask how temporary access is scoped, monitored, and removed, because segmentation that cannot govern vendor support sessions will not stop the most practical intrusion paths.

Industry guidance from the NIST Cybersecurity Framework 2.0 remains useful for framing these decisions, but current guidance should be adapted to the plant’s tolerance for downtime and the safety implications of false positives. Procurement should also be wary of vendors that measure success only by number of policies created. Real value is seen when the product reduces reachable paths, shortens recovery decisions, and creates evidence that operations can trust.

Related resources from NHI Mgmt Group

• What should procurement teams ask before accepting deepfake resistance claims?
• What should teams ask before adopting a new security feature from a vendor webinar?
• What should procurement teams ask before renewing an identity platform?
• What should procurement teams ask after a vendor security assessment?