Operational technology
Most plant security programmes begin with the same discovery: nobody has a current list of what is on the control network. This is how to build one safely, what it needs to record, and why everything else waits until it exists.
Someone hands you responsibility for securing a plant. You ask for the asset inventory. What comes back is a spreadsheet last updated during a commissioning project four years ago, a network diagram that predates two line expansions, and an assurance from the maintenance team that it is roughly accurate.
This is the normal starting position, not a sign of negligence. Plant estates accumulate over decades through capital projects, vendor upgrades, and emergency replacements, each documented by whoever was on site that week. Meanwhile the systems that would keep an IT inventory current, such as domain joins, endpoint agents, and software deployment tools, mostly do not reach into the control network.
The work of building visibility is unglamorous and it is the prerequisite for everything else. In the four-phase sequence described in our guide to IT and OT convergence, it is phase one for a structural reason: you cannot define zones for assets you cannot name, and you cannot baseline behaviour you have never observed.
Sequencing
Segmentation depends on knowing which systems serve which process, and what they legitimately communicate with. Draw zone boundaries without that and you will either break production by blocking traffic that mattered, or leave the boundary so permissive that it achieves nothing.
Monitoring has the same dependency. Detection in OT works by recognising deviation from normal, and normal has to be established from an estate you can describe. Organisations that buy a monitoring platform before doing discovery routinely find it sees a fraction of the environment, because nobody knew which network segments needed a collector.
Risk assessment inherits the problem too. A risk register that treats a plant as a single line item is not usable for decisions. Ranking by process criticality requires knowing what supports which process.
The constraint
The instinct of anyone trained in IT security is to point a discovery tool at the subnet. In a control network this can stop production, and the reasons are mechanical rather than theoretical.
Many industrial controllers were designed for deterministic, predictable traffic on a closed network. Their network stacks were built to handle the volume and pattern of a control loop, not the malformed packets, rapid port sweeps, and connection floods a scanner produces. Older devices in particular can respond by faulting, dropping into a stopped state, or becoming unresponsive until power-cycled, which on a running line means an unplanned outage, and on a process plant can mean a safety response.
Timing is the second problem. Control traffic is often latency-sensitive in ways enterprise traffic is not. Scan traffic sharing the same segment can introduce enough delay or jitter to disturb a process that depends on consistent cycle times.
The rule that follows is simple. On a live control network, discovery is passive by default. Anything active happens only with engineering agreement, in a planned window, on equipment whose behaviour under test is understood.
Method
No single method produces a complete picture. Used together, they converge on one.
A span or mirror port feeds a copy of network traffic to a collector that identifies devices from what they say rather than by interrogating them. Because it transmits nothing onto the control network, it carries no risk to the process.
Placement determines what you see. A collector on the plant core will observe traffic crossing between segments but may miss device-to-device conversation inside a cell. Expect to need several collection points, and expect the exercise to reveal that some segments have no practical span point at all, itself a finding worth recording.
Passive monitoring also needs time. A device that reports once per shift, or a maintenance laptop that appears monthly, will not show up in an afternoon. Run collection across a period that includes at least one full production cycle and, where possible, a maintenance window.
PLC project files, HMI tag databases, DCS configuration, and historian point lists describe the estate from the engineering side. They frequently name devices that passive monitoring never sees, either because the device is currently offline or because it communicates on a segment you could not observe.
These files also carry the process context that network traffic lacks. A tag database tells you which controller drives which piece of equipment, which is exactly the mapping needed later for zone design.
This is consistently the highest-yield source and the one most often skipped, because it is slower than running a tool. The people who maintain the plant hold knowledge that exists in no document.
Useful questions include: which systems must never be interrupted, and what happens if they are; which vendors connect remotely, how, and who authorises it; what was installed in the last two years; which equipment is out of vendor support; which panel or skid is not on any drawing; and what nobody is willing to touch because the person who configured it has left.
Walk the plant with someone who knows it. Open the panels. You will find equipment that no diagram records, network cabling that terminates somewhere unexpected, unmanaged switches added during a project, and wireless bridges installed to avoid pulling cable.
Photograph asset labels and record serial and firmware detail where visible. For devices with no network presence and no documentation, this is the only discovery method that works.
Maintenance agreements and support contracts describe remote access paths that may not appear anywhere technical. A contract committing a vendor to a four-hour response almost always implies connectivity, and that connectivity is an asset and a conduit whether or not anyone documented it.
Procurement records also help establish equipment age and support status, which drives risk ranking later.
Output
A list of devices and IP addresses is not an inventory in any sense that helps you make decisions. The fields that matter are the ones that let you rank risk and design zones.
| Field | Why it matters |
|---|---|
| Identity and version | Make, model, firmware and operating system version determine known weaknesses and support status |
| Process served | Which line, cell or unit operation depends on this device, the basis for criticality |
| Communication partners | What it legitimately talks to, and over which protocols; the input to conduit design |
| Ownership | Named owner in engineering or operations, not a department |
| Failure impact | What happens to the process if this device stops, degrades, or reports wrong values |
| Enterprise reachability | Whether anything on the business network can reach it, directly or through a jump host |
| Vendor access | Whether a third party has remote access, by what route, and under whose authorisation |
The last two fields are the ones that most often change a plan. Enterprise reachability and vendor access are how an attacker gets from an ordinary phishing email to a controller, and they are rarely captured in an inventory built by an asset-management tool.
Expect these
The specifics vary. The categories are remarkably consistent.
None of these findings implies anyone did anything wrong. Each was a reasonable decision at the time, made to keep production running. The value of discovery is putting them in one place so they can be prioritised rather than encountered one at a time during an incident.
Sustaining it
An inventory built as a one-off project starts decaying immediately. Within a couple of quarters it is another out-of-date spreadsheet, and the next person to inherit the estate repeats the exercise.
What keeps it accurate is process rather than tooling. Adding a device to a control network needs a step that records it, in the same way a change request records a firewall rule. Commissioning and handover from system integrators should require inventory data as a deliverable. Where passive monitoring is in place, new devices appearing on a segment should generate a notification that someone owns.
Assign the inventory to a named owner with a review cycle. Unowned documentation is documentation that goes stale.
Next step
Discovery is not the deliverable. What follows is.
Grouping assets by process function and criticality produces the draft zone model for segmentation, because zones follow process rather than geography. The communication-partner data becomes the conduit design, defining what must be permitted across each boundary. Enterprise reachability and vendor access become the first remediation priorities, since they are usually the shortest paths in.
The same data feeds risk work. Assets ranked by failure impact give plant and business leadership a shared basis for deciding what to spend on, and that ranking belongs in the organisation main risk register rather than a separate engineering document. Where a GRC programme already exists, OT findings should flow into it directly.
Where monitoring is planned, the inventory tells you where collectors need to sit and what normal looks like. A managed SOC can only interpret OT telemetry usefully when it knows which devices matter and what they ordinarily do.
Caveo approach
Our OT security services begin with visibility, using passive collection, configuration review, engineering interviews, and walkdown rather than active scanning of live control networks. The output is an inventory structured for the decisions that follow, covering zone design, conduit definition, and risk ranking, rather than a device list.
Because we also deliver managed SOC and GRC consulting, discovery findings feed the same monitoring and risk process as the rest of the security programme. For organisations that want a broader baseline first, a security assessment can scope the plant alongside the enterprise estate.
A scoped conversation about which plants matter most, what connectivity already exists, and what your regulatory position requires is usually the right starting point. Sector context matters here, so see cybersecurity for manufacturing for how this applies in a production environment.
Many industrial controllers were designed for predictable traffic on a closed network. Scanner behaviour such as port sweeps, malformed packets and connection floods can cause older devices to fault, stop, or become unresponsive until power-cycled, which on a running line means unplanned downtime. Scan traffic can also introduce latency on segments where control timing is sensitive. Active testing should only happen with engineering agreement, in a planned window.
Passive discovery identifies devices by observing a copy of network traffic through a span or mirror port, rather than sending anything to the devices themselves. Because nothing is transmitted onto the control network, it carries no risk to the process. It needs to run long enough to capture infrequent communication, and usually needs several collection points to see inside individual cells.
Beyond make, model and firmware version: the process each device serves, what it legitimately communicates with and over which protocols, a named owner, the impact on the process if it fails, whether anything on the enterprise network can reach it, and whether a third party holds remote access. The last two fields usually drive the first remediation priorities.
It depends on the number of sites, the complexity and age of the estate, how many network segments need collection points, and how much engineering documentation already exists. Passive collection in particular needs to span at least one full production cycle to capture infrequent traffic. Scope it against your own estate rather than a general timeframe.
Through process rather than tooling. Adding a device to a control network should include a step that records it. Commissioning and handover from integrators should require inventory data as a deliverable. Where passive monitoring is in place, new devices should raise a notification someone owns. Assign the inventory a named owner and a review cycle.
Yes, in practice. Monitoring detects deviation from normal, and normal has to be established from an estate you can describe. Without an inventory it is also difficult to know where collectors need to sit, which is why platforms deployed before discovery often end up seeing only part of the environment.
Talk to Caveo about passive OT discovery and building an inventory structured for segmentation, monitoring and risk decisions.