Operational technology security is bought under a constraint that does not apply anywhere else in the security estate: you usually cannot patch the thing you are protecting, you often cannot reboot it, and in many cases you cannot scan it without risking the process it controls. Requirements written from an IT security template will fail on contact with a plant network, and vendors who sell primarily to IT teams will answer them anyway.
This page covers what to specify for OT and industrial control system security, what evidence separates vendors with real operational experience, and where the obligations sit for Australian operators of critical infrastructure.
Why IT requirements do not transfer
Three assumptions break. First, availability outranks confidentiality: a control system that stops is a safety and production event, so a security control that can interrupt a process is often unacceptable regardless of what it protects against. Second, asset lifecycles run for decades, so unsupported operating systems are normal rather than negligent. Third, change is governed by engineering process and outage windows, not by a patch cycle.
The practical consequence is that most OT security purchases are about visibility and segmentation rather than prevention. You are buying the ability to see what is on the network and to contain movement across it, because the usual levers of patching and endpoint agents are largely unavailable.
Passive monitoring is the baseline, and its limits matter
The dominant approach is passive network monitoring: a sensor on a mirrored port that identifies assets and protocols without transmitting anything to them. It carries no process risk, which is why it is the usual starting point.
Its limits are worth specifying honestly. Passive monitoring sees what talks. Devices that are quiet, or that sit behind a serial link rather than on Ethernet, may not appear at all. Ask each vendor what proportion of a typical estate like yours is discovered passively, and what the remaining discovery method is.
Where vendors offer active or selective querying to fill those gaps, that is where process risk enters. Require a clear statement of which protocols are queried, at what rate, and what testing has been done against the specific device families in your plant. A generic assurance that active discovery is safe is not an answer.
What to specify separately
Protocol coverage against your actual estate
Coverage claims are the most common source of disappointment. Provide the real list of protocols and device vendors in your environment and require a per-protocol response: fully parsed, identified only, or unsupported. A count of supported protocols is meaningless without that mapping.
Segmentation and the conduit model
Segmentation between zones is the highest-value control in most OT environments. Specify how the product supports defining zones and conduits, whether it can enforce or only observe, and how it behaves during a failure. A device that fails closed in the middle of a plant network is a production risk.
Safe deployment
Establish the physical and network requirements per site: span ports, taps, power, rack space, and whether any device must be installed inside a control cabinet. In a multi-site operation this determines the real rollout cost far more than the licence does.
Alert routing to people who can act
Decide early whether alerts route to a corporate security team, to plant engineers, or both, and specify the product’s ability to reflect that. An OT alert that arrives only in an IT queue at 2am, about a plant nobody in that queue can safely touch, is not a detection capability.
Remote access for vendors
Third-party maintenance access is the most common ingress path into OT environments. Specify how it is brokered, recorded and time-bounded. This overlaps directly with privileged access management, and the two requirements are best written together.
Australian obligations
Operators of critical infrastructure assets carry obligations under the Security of Critical Infrastructure regime, and the enhanced risk management program rules bring supply chain and cyber hazards into a formal, reportable framework. Those obligations shape OT security procurement in a specific way: they create an evidence requirement about how hazards are identified and mitigated, which makes the reporting capability of any platform you buy part of the compliance case rather than a nice-to-have. See the enhanced CIRMP rules for the supply chain dimension.
The ASD Essential Eight was written for corporate IT and does not map cleanly onto plant environments. Use it where it genuinely applies, typically at the enterprise boundary and on engineering workstations, and do not let an assessor apply it wholesale to a control network where several strategies are technically inapplicable.
How OT security is priced
Common bases are per site, per monitored asset, per sensor, and per aggregated data volume. Per-asset pricing is the one to examine, because passive discovery routinely finds several times the asset count an operator expected, and the licence then true-ups against a number nobody forecast. Ask what happens commercially when discovery finds more assets than the contract assumed, and get that answer before signature rather than at renewal.
Hardware, installation and the engineering time to arrange span ports across sites are frequently absent from the first quote. So is the ongoing tuning effort, which in OT is substantial early on because baseline behaviour has to be learned per site.
Evidence to request
- A per-protocol coverage response against your real device list, not a generic count.
- Documented safety testing for any active querying, against your device families.
- Discovery rate achieved passively at a comparable operator, with the residual method named.
- Failure behaviour of any inline component, in writing.
- Australian reference customers in your sector who have completed a multi-site rollout.
- A software bill of materials, since the platform sits inside the control network. See SBOM procurement in Australia.
A defensible evaluation sequence
Write requirements with plant engineering in the room alongside the security team, because the constraints that will veto a product are operational. Weight availability and safety impact explicitly rather than treating them as assumptions.
Trial on one real site, including the awkward one rather than the newest, and measure discovery against a manually verified asset inventory for that site. Discovery claims are checkable, and checking them is the single most useful thing a proof of value can do in this category.
Document the decision, including which Essential Eight strategies were judged inapplicable and why. That reasoning is what protects the decision in a later audit. The guided vendor evaluation process and the Discover, Evaluate, Engage, Assure method produce that record as part of the work.
Sources
- Essential Eight Explained, Australian Signals Directorate.
- Essential Eight Maturity Model, Australian Signals Directorate.
- Cybersecurity Framework, National Institute of Standards and Technology.
- ISO/IEC 27001 Information Security Management, International Organization for Standardization.
Where to read more
See backup and recovery procurement for the recovery side of a control-system incident, incident response and recovery services for responders who understand plant environments, and vendor and supplier risk management for the maintenance partners who hold access.
