Can OT network monitoring stop production?

Done properly, no. The monitoring system reads from switches and firewalls and listens for their alerts. It writes nothing, installs nothing on controllers, and never sits in the path of control traffic. If it fails, the plant keeps running.

Is this the same as an industrial IDS like Nozomi or Claroty?

No. An intrusion detection system decodes a copy of the traffic to spot unexpected conversations. Network monitoring watches the equipment that carries the traffic: links, rings, configurations and devices on ports. They answer different questions and most plants need the network layer first.

Do we need an asset inventory before monitoring?

Yes, and a good monitoring deployment produces one as its first deliverable. Alerts only mean something when they point at a known device in a known place. Monitoring on an undocumented network produces noise.

What does it need from the plant?

A read-only credential on the switches and firewalls, a place for one appliance inside the plant network, and an outbound path for alarms. No agents, no inline hardware, no changes to equipment in operation.

Who watches the alarms?

That is the part that decides whether monitoring works. Potenza's service routes alarms to an on-call engineer first, with a response target in the contract, and the plant is called when something needs a hand on site.

Insights / OT network monitoring

OT network monitoring, explained.

Plant networks fail quietly. A link drops, a ring loses its redundancy, a switch reboots at two in the morning, and nobody knows until a line stops. OT network monitoring is the practice of watching the network equipment itself, continuously and without touching it, so those events reach an engineer before they reach production.

What it watches, and what it cannot see

The value is in the first list. The honesty is in the second. A monitoring deployment sold without the second list is the kind that becomes expensive wallpaper.

What network monitoring sees

Links going down or flapping, and which two devices lost each other
Switches and firewalls that stop answering, reboot, or run hot
Failing power supplies and fans before the second one fails
Ring redundancy that has silently broken, leaving one path
Configuration changes nobody announced, with before and after
Devices appearing on ports where nothing should be plugged in
An inventory of every network-accessible device, kept current

What it does not see

What a PLC is doing, or whether its logic was changed
The content of control conversations between controllers and HMIs
Malware on a workstation that is behaving normally on the network
Anything on a network segment no monitored switch can reach
Problems on a flat, undocumented network, where alerts have no map to land on

The second list is why monitoring comes after an inventory and a topology, not before. Alerts are only useful when they point at a known device in a known zone.

Six signs a plant needs it

Not every plant needs continuous monitoring on day one. These are the situations where it stops being optional.

01
Outages are discovered by operators
The first sign of a network problem is a frozen HMI or a stopped conveyor, and the fix starts with someone walking the plant looking for a dark switch.
02
Nobody can say what is on the network
The drawing is years old, devices have been added by vendors and contractors, and the only inventory is in someone's head.
03
Redundancy exists on paper
The ring was commissioned with two paths. Nobody has checked since whether both still work, and the plant will find out the day one fails.
04
Remote access nobody governs
Vendors reach equipment through connections nobody can list. A change appears on a switch and nobody knows who made it or when.
05
The switch estate is aging
Hardware past vendor support fails more often and gives less warning. Monitoring buys the lead time a refresh plan needs.
06
An auditor or insurer is asking
ISA/IEC 62443 and NIST SP 800-82r3 both expect continuous monitoring of the control network. A monitoring record is the evidence.

Not the same as IT monitoring, not the same as an IDS

Three tools get called "monitoring" and they answer different questions. Most plants need the first and the third. The second is a later layer.

	IT monitoring	OT intrusion detection	OT network monitoring
The question it answers	Is the server up and the link busy?	Is someone talking on this network who should not be?	Is the plant's network equipment healthy, unchanged and complete?
What it looks at	Servers, bandwidth, uptime	A copy of the traffic, decoded by industrial protocol	Switches, firewalls, links, ports, configurations
How it connects	Agents on hosts, polling over the corporate network	Sensors on mirror ports or taps, passive	Read-only polling and listening for the equipment's own alerts, nothing inline
What it catches first	A saturated link, a full disk	A new talker, an unexpected write command	A dropped link, a broken ring, a changed config, a new device on a port
Where it fails on a plant floor	No industrial context; alerts on volume, not on what the plant cares about	Noise on a flat, undocumented network; needs zones to be useful	Cannot see inside controllers; needs an inventory to start from

The question it answers

IT monitoring: Is the server up and the link busy?
OT intrusion detection: Is someone talking on this network who should not be?
OT network monitoring: Is the plant's network equipment healthy, unchanged and complete?

What it looks at

IT monitoring: Servers, bandwidth, uptime
OT intrusion detection: A copy of the traffic, decoded by industrial protocol
OT network monitoring: Switches, firewalls, links, ports, configurations

How it connects

IT monitoring: Agents on hosts, polling over the corporate network
OT intrusion detection: Sensors on mirror ports or taps, passive
OT network monitoring: Read-only polling and listening for the equipment's own alerts, nothing inline

What it catches first

IT monitoring: A saturated link, a full disk
OT intrusion detection: A new talker, an unexpected write command
OT network monitoring: A dropped link, a broken ring, a changed config, a new device on a port

Where it fails on a plant floor

IT monitoring: No industrial context; alerts on volume, not on what the plant cares about
OT intrusion detection: Noise on a flat, undocumented network; needs zones to be useful
OT network monitoring: Cannot see inside controllers; needs an inventory to start from

A plant with no inventory and no zones gets more from network monitoring than from an IDS. The IDS earns its place once the topology exists and segmentation is under way.

What good looks like

Whoever provides it, these are the properties to insist on. They come from running monitoring on live cement plants, where the cost of a wrong assumption is a stopped kiln.

This is how Potenza runs it: a read-only appliance inside each plant, watched by our engineers. The service is described on the OT network monitoring service page.

Read-only, by design: The monitoring system polls equipment and listens for its alerts. It has no ability to write a configuration, so it cannot be the cause of the outage it is meant to catch.
Never inline, no agents on controllers: Nothing sits in the path of control traffic and nothing is installed on a PLC or HMI. If the monitoring fails, production does not notice.
Works with the switches you have: Plants run a mix of vendors and generations. Monitoring that only understands one brand leaves the rest dark.
Keeps working without the internet: Data is stored inside the plant and alarms go outbound only. A lost internet link pauses the alerting, not the recording.
Alarms a person acts on: Tuned per plant, suppressed during planned work, and routed to an engineer who owns the response. An alarm nobody owns is a log entry.
Feeds a written record: Weekly and monthly reporting, an inventory that stays current, and a change history. The audit answer is the by-product, not a project.

Questions plant teams ask

Can OT network monitoring stop production?: Done properly, no. The monitoring system reads from switches and firewalls and listens for their alerts. It writes nothing, installs nothing on controllers, and never sits in the path of control traffic. If it fails, the plant keeps running.
Is this the same as an industrial IDS like Nozomi or Claroty?: No. An intrusion detection system decodes a copy of the traffic to spot unexpected conversations. Network monitoring watches the equipment that carries the traffic: links, rings, configurations and devices on ports. They answer different questions and most plants need the network layer first.
Do we need an asset inventory before monitoring?: Yes, and a good monitoring deployment produces one as its first deliverable. Alerts only mean something when they point at a known device in a known place. Monitoring on an undocumented network produces noise.
What does it need from the plant?: A read-only credential on the switches and firewalls, a place for one appliance inside the plant network, and an outbound path for alarms. No agents, no inline hardware, no changes to equipment in operation.
Who watches the alarms?: That is the part that decides whether monitoring works. Potenza's service routes alarms to an on-call engineer first, with a response target in the contract, and the plant is called when something needs a hand on site.

See how Potenza delivers it.

A read-only appliance inside the plant, any switch vendor, watched by our engineers, with weekly and monthly reporting.

OT network monitoring service

Not sure where your plant stands?

Twelve questions place a plant on the OT maturity model and show which baseline control to start with, monitoring included.

Take the readiness self-assessment