# OT and IoT (FAQ)

> 50 questions on OT and IoT, in plain language: what to check, what NetSenX shows and what a sensor cannot see.

Source page: https://netsenx.com/en/faq/ot

## Can NetSenX monitor OT and industrial networks?

Yes, from the Pro plan. NetSenX reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm from passive capture on a SPAN or TAP port. Devices classified as OT are never actively probed, so there is no risk to PLCs or SCADA systems.

https://netsenx.com/en/faq/can-netsenx-monitor-ot-and-industrial-networks

## Can you monitor an OT network without affecting PLCs?

Yes, with passive monitoring: the sensor reads a copy of the traffic from a SPAN port or TAP and never sends anything to the controllers. NetSenX works this way from the Pro plan, and never actively probes devices classified as OT.

https://netsenx.com/en/faq/can-you-monitor-an-ot-network-without-affecting-plcs

## Which industrial protocols does NetSenX read?

Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm, from passive capture, on the Pro plan and above.

https://netsenx.com/en/faq/which-industrial-protocols-does-netsenx-read

## Do I need a hardware appliance on every site?

No NetSenX appliance is needed: the agent is software that runs on a host you choose. One agent connected to a SPAN or TAP port watches the whole segment and counts as one device.

https://netsenx.com/en/faq/do-i-need-a-hardware-appliance-on-every-site

## Does NIS2 cover OT networks?

NIS2 applies to entities in sectors such as energy, transport, drinking water, health and the manufacture of certain products (Annexes I and II of Directive (EU) 2022/2555). Its Article 21 measures concern the network and information systems an entity uses for its operations, which can include OT. Check the scope with your national authority.

https://netsenx.com/en/faq/does-nis2-cover-ot-networks

## Can network monitoring break our PLCs?

Passive monitoring cannot, because it only listens to a copy of the traffic and never sends anything to the controllers. Active scanning is a different matter: some older PLCs and remote terminal units crash, reboot or drop into a fault state when a discovery tool or vulnerability scanner probes them, which is why many plants keep scanners off the control network. Take the copy from a SPAN port on an industrial switch or from a passive network TAP, and check with the switch vendor that mirroring will not overload an old switch. NetSenX reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm from passive capture, from the Pro plan, and never actively probes devices classified as OT. Nothing is installed on the controllers and none of their settings change.

https://netsenx.com/en/faq/can-network-monitoring-break-plcs

## Do IoT devices such as cameras and printers need monitoring?

Yes. Cameras, printers, door controllers, screens and sensors are often old, rarely updated and impossible to fit with an endpoint agent, which makes them a common way in and a good hiding place for an attacker who is already inside. Start with the free steps: list them, change default passwords, update the firmware, switch off cloud features you do not use, and put them on their own network segment with rules that allow only what they need. Monitoring then tells you whether those rules hold. A sensor on that segment sees their traffic without touching the devices; NetSenX flags scanning, beaconing and unusual outbound volume from them, on every plan, and the network map lists the devices it sees talking. A device that stays silent, or sits on a segment you do not mirror, stays out of view.

https://netsenx.com/en/faq/do-iot-devices-need-monitoring

## Are cameras on their own VLAN still a risk?

Less of one, but yes. A separate virtual LAN (VLAN) only helps if the rules between it and the rest of the network are strict, and cameras and recorders often get broad exceptions so that staff can watch video from any PC or phone. They also tend to need internet access for apps and updates, which is also a way out for an attacker. Allow only the viewing station or video server to reach the cameras, stop the camera VLAN from reaching everything else, block internet access the devices do not need, change default passwords and update the firmware. A sensor on that VLAN sees their traffic; NetSenX flags scanning, beaconing and unusual outbound volume from them, on every plan, so a camera that starts talking to new places stands out.

https://netsenx.com/en/faq/are-cameras-on-their-own-vlan-still-a-risk

## How do I detect attacks on PLCs in a small factory?

Watch the traffic to and from the controllers, because a programmable logic controller (PLC) keeps almost no security log of its own. The useful signals are simple: a write or a program download from a computer that is not your engineering station, a stop or start command nobody planned, office machines talking directly to controllers, and activity at night or at weekends when nobody works on the line. Begin with the free steps: list which stations may program each PLC, check that the office network cannot reach the control network, and leave the controllers' key switches in run mode where your hardware has them. From the Pro plan, NetSenX reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm from a SPAN or TAP port and raises four kinds of OT alert: unauthorised writes, traffic crossing plant network levels, off-hours OT activity and S7comm commands. It never probes the controllers, and it does not see serial links or segments you do not mirror.

https://netsenx.com/en/faq/how-to-detect-attacks-on-plcs-in-a-small-factory

## Why is Modbus considered insecure?

Because it has no authentication and no encryption: any device that can reach a Modbus/TCP controller can read its values and, unless the controller itself restricts it, write to its coils and registers. Modbus was designed in 1979 for serial links between trusted devices, long before control networks were joined to office networks and the internet. A secured variant with TLS exists, but few installed devices support it. In practice you protect Modbus from the outside: keep port 502 off the internet, let only named engineering and SCADA hosts reach the controllers, and use any write protection the PLC offers. Because the traffic is not encrypted, a passive sensor can read which station reads from or writes to which controller. NetSenX does that from the Pro plan and raises an alert when a host that is not allowed to write sends a write; it does not change the protocol or block the command.

https://netsenx.com/en/faq/why-is-modbus-insecure

## How do I know if an unauthorised computer writes to our PLC?

You need something that reads the industrial protocol on the wire and knows which hosts may write, because the PLC will normally accept the write without complaint and log nothing. First write down which stations should ever change a setting: usually one or two engineering workstations and the SCADA or HMI servers. Then make the network enforce it where you can, with firewall rules that let only those hosts reach the controllers. Monitoring covers what the rules miss: a laptop plugged into the line, an office PC with a forgotten route, malware on an allowed station. From the Pro plan, NetSenX reads write requests from passive capture on a SPAN or TAP port and raises an alert when a write comes from a host that is not allowed to write, naming the source, the controller, the function and the time. It does not record the value written or which person was at the keyboard.

https://netsenx.com/en/faq/how-to-know-if-an-unauthorised-computer-writes-to-a-plc

## Which OT alerts matter most for a small factory?

The ones that mean something changed in the process: a write or program download from an unexpected computer, a controller being stopped, started or switched to another mode, office traffic reaching the control level, and any of this outside working hours. These are rare in normal operation, so each one deserves a call to the person responsible for the line. Alerts about volume or new destinations matter too, but on the IT side, where most attacks on factories start. Agree in advance who receives OT alerts, how quickly someone looks, and that nobody disconnects a production host without asking the shift lead, because an abrupt disconnection can cost more than the alert. From the Pro plan, NetSenX raises exactly these OT alerts: unauthorised writes, traffic crossing plant network levels, off-hours OT activity and S7comm commands, next to the beaconing, scanning, lateral movement and unusual outbound volume alerts it raises on every plan.

https://netsenx.com/en/faq/which-ot-alerts-matter-most-for-a-small-factory

## How do I detect a PLC program change outside working hours?

Combine a record of when your engineers really work on the controllers with a sensor that sees program downloads and writes on the network. A program change at 02:00 on a Sunday is not proof of an attack, since maintenance often happens while the line is stopped, but someone should be able to explain it the next morning. Keep a simple change log with the planned maintenance windows, compare it with what the network shows, and keep a known-good copy of each PLC program offline so you can compare and restore it. Some controllers can also report a changed program to the SCADA system. From the Pro plan, NetSenX flags OT activity outside working hours and decodes S7comm requests such as a program block download, with the block name, from a SPAN or TAP port. It does not read the program's content or compare versions; your engineering software does that.

https://netsenx.com/en/faq/how-to-detect-a-plc-program-change-outside-working-hours

## Can network monitoring see an S7 PLC being stopped?

Yes, when the stop command travels over the network in S7comm, the protocol Siemens S7 controllers use for programming and diagnostics. S7comm is not encrypted, so a passive sensor that receives a copy of the traffic can decode the request as a stop, together with the computer that sent it and the time. A stop made with the controller's own switch or front panel never crosses the network, so no sensor sees it. Newer controllers can use a protected successor protocol, S7comm-plus; ask us before relying on NetSenX for that traffic. From the Pro plan, NetSenX decodes S7comm requests into command names such as a PLC stop, a variable write or a program block download and raises an S7comm command alert, from a SPAN or TAP port, without sending anything to the PLC. It informs your engineers; it does not block the command.

https://netsenx.com/en/faq/can-network-monitoring-see-an-s7-plc-being-stopped

## Can network monitoring show who changed a PLC setpoint?

It can show which computer sent the write and when, which is usually enough to find the person. Most industrial protocols carry no user name, so the network only knows the source address. Linking that address to a person is done with the HMI or SCADA audit trail, the engineering software's log and the shift roster. To make this possible later, give every engineering station its own fixed address, require named logins on HMIs and SCADA, and keep their logs as long as your quality records. From the Pro plan, NetSenX reads writes from passive capture on a SPAN or TAP port and, when the writer is not allowed to write, raises an alert with the source host, the controller, the function code and the time. It does not record the value written and it never identifies a person: it watches devices and connections, not people.

https://netsenx.com/en/faq/can-network-monitoring-show-who-changed-a-plc-setpoint

## Does NetSenX record the values written to our controllers?

No. NetSenX records that a write happened, from which host, to which controller, with the function code and the time, but not the value written or the contents of a program block. That is a deliberate limit: process values and programs are your know-how, and an alert needs the who and when, not the recipe. If you need the values, for example to reconstruct a bad batch, they come from the historian, the SCADA or HMI audit trail or the controller's own diagnostics. Plan for this before you need it: check how long your historian keeps data and whether HMI changes are logged with a user name. NetSenX reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm from passive capture, from the Pro plan, and never sends anything to the devices.

https://netsenx.com/en/faq/does-netsenx-record-the-values-written-to-controllers

## Can OT alerts help a quality or safety investigation?

Yes, as one source of evidence among several. An OT alert tells you that a controller received a write from a host that is not allowed to write, or an S7comm command, or traffic outside working hours, with the source host, the controller and the time. Put it on a timeline next to the historian data, the HMI audit trail, the shift log and the maintenance records, and you can usually narrow down when and from where a change came. Make sure the clocks agree, because a few minutes of drift between systems makes timelines misleading. Note what alerts do not cover: an authorised write during the shift raises no alert, so the HMI trail stays your record of everyday changes. NetSenX keeps alerts for your plan's alert history; you read them in the dashboard, through the API from the Pro plan, or in your SIEM from the Business plan. They contain no written values and name no person.

https://netsenx.com/en/faq/can-ot-write-events-support-a-quality-or-safety-investigation

## Does NetSenX raise a separate anomaly alert for each industrial protocol?

No. NetSenX reads five industrial protocols, Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm, but there is no separate anomaly alert per protocol, such as one for unusual Modbus polling or odd BACnet traffic. Its OT alerts are four kinds that work across what it reads: a write to a controller from a host that is not allowed to write, traffic that crosses levels of the plant network, OT activity outside working hours, and S7comm commands such as a stop or a program download. The general detections watch the same hosts as well: beaconing, scanning, lateral movement and unusual outbound volume. If your risk assessment needs deep, protocol-specific anomaly detection, for example for a utility's telecontrol traffic, ask us what is covered before you rely on it, or run a specialist OT tool beside NetSenX. The OT features are available from the Pro plan.

https://netsenx.com/en/faq/does-netsenx-raise-a-separate-alert-for-each-industrial-protocol

## Can NetSenX block a dangerous command to a PLC?

No. NetSenX listens to a copy of the traffic and informs your engineers; it does not sit in the path, so it cannot drop a packet, and it never acts on the process. That is intentional: an inline device that blocks industrial commands can stop a line by mistake, and NetSenX is not a safety system. Protection against dangerous commands comes from other layers: a firewall between zones that allows only named hosts, write protection and key switches on the controllers, and a safety instrumented system that does not depend on the control network. What NetSenX adds, from the Pro plan, is the alert when a host that should not write does, when a controller receives an S7comm command such as a stop, or when OT traffic appears at night, so that someone can check before the next shift starts.

https://netsenx.com/en/faq/can-netsenx-block-a-dangerous-command-to-a-plc

## Does NetSenX read PROFINET, OPC UA or IEC 60870-5-104?

Not today. NetSenX reads five industrial protocols, Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm, from passive capture, from the Pro plan. Other industrial traffic on a monitored segment is still seen as connections between hosts: beaconing, scanning, lateral movement and unusual outbound volume still apply, and the network map still lists the devices. What is missing is the decoding of that protocol's commands, so the OT alerts for writes and commands do not cover it. If your plant runs mainly on PROFINET, OPC UA or the IEC 60870-5-104 telecontrol protocol, tell us before you buy and ask what would be covered on your network, or pair NetSenX with a tool that decodes those protocols. It is better to know this now than to find the gap during an audit.

https://netsenx.com/en/faq/does-netsenx-read-profinet-or-opc-ua

## Can a network sensor see serial fieldbus links such as Modbus RTU?

No. A network sensor sees the Ethernet and IP traffic that is copied to it. Serial links such as Modbus RTU over RS-485, Profibus DP and other fieldbuses never reach Ethernet, so the commands on them are out of its view. What it can see is the gateway that translates between Ethernet and the serial bus: who talks to the gateway, when and how often. In many plants that is a useful signal, because anyone who wants to reach a serial device from the network has to go through that gateway. List your gateways, protect them like controllers, and mirror the segment they sit on. NetSenX reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm from passive capture, from the Pro plan. For the serial side, rely on the controllers' own diagnostics and on locked cabinets.

https://netsenx.com/en/faq/can-a-network-sensor-see-serial-fieldbus-links

## What does "never actively probed" mean for our controllers?

It means the sensor never sends a packet to a device classified as OT: no discovery scan, no port scan, no protocol query, no login attempt. It only reads a copy of the traffic your own systems already exchange, taken at a SPAN port or a network TAP. Active tools work differently: they ask each device questions, and some older PLCs, RTUs and HMIs react badly to unexpected requests, from slow responses to crashes. For a plant manager, the practical meaning is that switching on NetSenX adds no traffic to the control network and cannot change a controller's state, so nothing on the controllers needs a maintenance window. The trade-off is that a passive sensor only knows what devices say: a controller that never communicates on a mirrored segment is not seen. OT monitoring is available from the Pro plan.

https://netsenx.com/en/faq/what-does-never-actively-probed-mean-for-our-controllers

## Do we need to change anything on our PLCs to monitor them?

No. Passive monitoring needs no software, configuration or firmware change on the PLCs, HMIs or drives. The change happens on the network: a SPAN (mirror) port on a managed switch, or a passive TAP on a cable, sends a copy of the traffic to a small computer that runs the sensor. Plan that change like any other on the production network: agree it with the OT engineer, check that the switch can mirror the ports you need without overload, and make it in a maintenance window if your rules require one. Then decide where the sensor host sits and how it sends alerts out, ideally through a firewall rule that allows only that. With NetSenX, the agent runs on a Linux host you choose and reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm from the Pro plan; one agent on a mirror port counts as one device.

https://netsenx.com/en/faq/do-we-need-to-change-anything-on-our-plcs-to-monitor-them

## What if our production switch has no SPAN port?

Then use a network TAP, or add a managed switch where you need visibility. Unmanaged switches, common in machine cabinets, cannot mirror traffic. A TAP is a small box placed in one cable, for example the link between the line switch and the plant core, that copies the traffic in both directions to a monitoring port without appearing on the network. Many are built to keep the link up if they lose power; check that for the model you buy. Choose the link that carries the traffic you care about most: between office and production, or between the SCADA servers and the controllers. Traffic between two devices on the same unmanaged switch never crosses that link and stays out of view. NetSenX works from either a SPAN port or a TAP; one agent on it counts as one device, and the OT protocols are read from the Pro plan.

https://netsenx.com/en/faq/what-if-the-production-switch-has-no-span-port

## Can we monitor a machine without installing any software on it?

Yes. Anything the machine does on the network can be watched from outside, from a copy of its traffic taken at a SPAN port or a TAP. That is the usual approach for controllers, HMIs, test benches, medical devices and any system whose supplier forbids changes or ties the warranty to them. What you see is its behaviour: which hosts it talks to, at what times, how much data and, in the decoded industrial protocols, what it asks the controllers to do. What you do not see is what happens inside it: files, processes and local logins stay hidden, and so does traffic on links that are not mirrored. NetSenX works this way: one agent on a mirror port watches the whole segment and counts as one device. Beaconing, scanning, lateral movement and unusual outbound volume are flagged on every plan; the OT protocols and OT alerts come with the Pro plan.

https://netsenx.com/en/faq/can-we-monitor-a-machine-without-installing-software-on-it

## Should the OT network be separated from the office network?

Yes. Most attacks that stop production start in the office network, through e-mail, a stolen password or a supplier's access, and a flat network lets them reach the controllers directly. Separation does not have to mean an air gap. The usual design puts a firewall between office and production, with a small demilitarised zone (DMZ) in between for the systems both sides need, such as a historian copy, a patch server or the remote-access gateway, and with no direct connection from an office PC to a controller. Start by listing the connections production really needs, allow only those and log what is refused. Afterwards, check that the separation holds in practice, because exceptions pile up. From the Pro plan, NetSenX raises an alert when traffic crosses levels of the plant network, for example from an office host straight to a controller, from a SPAN or TAP port.

https://netsenx.com/en/faq/should-ot-be-separated-from-the-it-network

## What is the Purdue model, and why does cross-level traffic matter?

The Purdue model is a reference layout that sorts a plant's systems into levels: the physical process and its sensors at the bottom, controllers above them, then supervisory systems such as HMIs and SCADA, then site operations such as the historian and production planning, and the business network at the top. The rule that matters is that each level talks mainly to its neighbours, and that traffic between business and production passes through a controlled boundary, usually a DMZ. Traffic that jumps levels, such as an office PC talking straight to a PLC, is either a design mistake or something an attacker is using, and it is one of the clearest warning signs in OT. Many real plants do not fit the model neatly, which is fine; what matters is that you know which crossings are intended. From the Pro plan, NetSenX flags traffic that crosses Purdue levels, from passive capture.

https://netsenx.com/en/faq/what-is-the-purdue-model

## How do I check that our office network cannot reach production controllers?

Test it, then watch it. For the test, take an ordinary office laptop and, with the OT engineer's agreement, try to open a connection to a controller's address and port and to the HMI and SCADA servers; use a simple connection test, never a scanner, against production devices. Review the firewall rules between office and production for broad rules and for old exceptions nobody can explain. Then watch real traffic for a few weeks, because the routes that matter are often the forgotten ones: a PC with one network card in each network, a supplier's VPN that ends inside production, a wireless bridge. From the Pro plan, NetSenX flags traffic that crosses levels of the plant network, such as an office host reaching a controller, so a path that should not exist shows up the first time it is used. A path that exists but is never used stays invisible to any passive sensor.

https://netsenx.com/en/faq/how-to-check-the-office-network-cannot-reach-production-controllers

## Can a ransomware attack on office IT stop a production line?

Yes, and it is the most common way production stops in a cyber incident, even when the machines themselves are untouched. Lines depend on IT systems for orders, recipes, labels, shipping and quality records; when the ERP, the label server or the file shares are encrypted, many plants stop rather than produce without traceability. Others shut production down as a precaution while they find out how far the attacker got. So protecting production starts on the IT side: list the IT systems each line needs, plan how to run without them for a day, keep offline backups of those systems and test restoring them. NetSenX watches the IT-side steps that come before encryption, on every plan: beaconing, scanning, lateral movement and unusual outbound volume. From the Pro plan it shows OT traffic in the same dashboard. It does not stop ransomware; it gives you time to act.

https://netsenx.com/en/faq/can-ransomware-on-office-it-stop-a-production-line

## How do we control maintenance laptops that connect to our production network?

Treat them as visitors with a key: allowed in for a job, on a known port, and watched while they are there. Agree with each machine builder and integrator which laptop may connect, where and for what. Give them a dedicated maintenance port or VLAN that reaches only their machine, instead of any free socket on the line switch, and switch that port off when the job is done. Ask for the laptop to be checked for malware before it connects, or lend them a company laptop with the engineering software, which many plants prefer. Keep a short visit log: who, when, which machine. On the network side, the laptop appears as a new device on the NetSenX network map, on every plan, and if it scans or starts talking to many hosts, the scanning and lateral movement alerts fire. From the Pro plan, a write to a controller from a host that is not allowed to write raises an OT alert.

https://netsenx.com/en/faq/how-to-control-maintenance-laptops-on-the-production-network

## Can we see which controllers a visiting technician's laptop talked to?

Yes, if the segment the laptop used is mirrored to a sensor: every connection it made crossed the network and can be listed afterwards by its address. That answers the question plant managers and auditors ask after a visit: did the laptop touch only the machine it came for? Make this easier by giving visitors addresses from a known range or a dedicated maintenance VLAN, so their traffic is easy to tell apart from your own. On the NetSenX network map, on every plan, the laptop shows as a device with the hosts it talked to and when it was first and last seen. From the Pro plan, NetSenX also decodes Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm, so writes from a host that is not allowed to write and S7comm commands raise OT alerts. A connection made through the machine builder's own 4G router, or on an unmirrored switch inside the machine, never crosses your monitored network and is not seen.

https://netsenx.com/en/faq/can-we-see-which-controllers-a-technicians-laptop-talked-to

## How should remote access to OT by vendors and integrators be secured?

Through one controlled entry point that you own, switched on only when needed. In practice: a remote-access gateway or jump server in the DMZ between office and production, multi-factor authentication for every vendor account, a named account per technician instead of a shared one, access limited to the machines that vendor supports, sessions enabled on request and switched off afterwards, and logs or recordings of what was done. Once that path exists, remove the vendors' own permanent tools, such as remote-desktop apps on HMIs and 4G routers in cabinets. NIS2 also expects supply-chain security measures, so write these rules into the contracts. On the network, a vendor session shows as connections from the gateway into production; NetSenX flags scanning and lateral movement from it on every plan and, from the Pro plan, writes from hosts that are not allowed to write. NetSenX does not decide who gets access; your gateway does.

https://netsenx.com/en/faq/how-should-vendor-remote-access-to-ot-be-secured

## Are vendor 4G routers in machine cabinets a security risk?

Yes. A cellular router installed for remote support connects the machine to the internet over the mobile network, completely around your firewall, so none of your rules, logs or VPN controls apply to it. If the vendor's portal or the router itself is compromised, or its default password was never changed, an attacker lands on your production network. Many of these routers appear on no drawing because they arrived with the machine. Ask every machine supplier in writing whether their equipment contains a modem or cellular router, inspect the cabinets, and then remove it, keep it powered off until a support session is booked, or replace it with your own controlled remote-access path. A network sensor cannot see the 4G link itself, because that traffic never crosses your network; it can only see the router's LAN side, if that segment is mirrored to it.

https://netsenx.com/en/faq/are-vendor-4g-routers-in-machine-cabinets-a-risk

## How do I find hidden remote-access routers in our production network?

Look at the cabinets and the network together. Physically: open machine cabinets during the next planned stop and look for small routers, modems and antennas, and ask each supplier for a list of the communication devices in their equipment. On the network: look for devices that behave like gateways, for example a machine whose traffic goes to an address that is not your router, a device that hands out its own addresses, or a host that receives connections from outside at times when nobody on your side started them. A device that appears on your network map but on no drawing deserves a question. The NetSenX network map, on every plan, lists the devices it sees talking on monitored segments with first and last seen, and beaconing is flagged for devices that call out at regular intervals. A router that talks only over its cellular link and stays quiet on your LAN cannot be found from the network; the cabinet inspection finds it.

https://netsenx.com/en/faq/how-to-find-hidden-remote-access-routers-in-production

## How do I protect an old production PC that cannot be patched?

Surround it, because you cannot fix it. Operator panels, HMIs and test-bench computers often run an operating system the vendor no longer supports, and the machine supplier forbids changes. Take it off every network it does not need, block its internet access, allow only the connections it needs to the controllers and servers it works with, disable USB ports and unused services where the supplier allows it, use application allow-listing if the vendor supports it, and keep a tested image so you can rebuild it. Ask the supplier for an upgrade path and record the remaining risk. Then watch it from the network, since nothing can be installed on it: NetSenX sees its connections from a SPAN or TAP port and flags beaconing, scanning, lateral movement and unusual outbound volume on every plan and, from the Pro plan, writes to controllers from hosts that are not allowed to write. It does not see what runs inside the PC.

https://netsenx.com/en/faq/how-to-protect-an-unpatchable-pc-in-production

## What is a compensating control for legacy OT systems?

It is a measure that reduces a risk you cannot remove at its source. When a controller cannot be patched, has no password or runs an unsupported system, you protect it from outside instead: segmentation and firewall rules so that only named hosts can reach it, no internet access, a controlled remote-access path, locked cabinets, offline backups of programs and configurations, and monitoring that tells you when the protection is bypassed. Auditors working with IEC 62443 or NIS2 risk management generally expect such controls to be documented: which risk, which measure, who owns it and how you check that it still works. Monitoring is the part that produces that checking evidence. NetSenX can provide it: from a SPAN or TAP port it shows who talks to the legacy system and, from the Pro plan, raises OT alerts for unauthorised writes, traffic crossing plant network levels, off-hours activity and S7comm commands.

https://netsenx.com/en/faq/what-is-a-compensating-control-for-legacy-ot-systems

## How do I build an OT asset inventory without active scanning?

Combine three passive sources: what your documents say, what your engineering tools know and what the network shows. Start with the drawings, the engineering project files, which list every controller, drive and remote I/O they configure, and the supplier documentation of each machine. Then walk the plant: cabinets, panels, remote sites. Finally, add what the traffic shows: a passive sensor on a mirror port sees every device that communicates on that segment, including the ones nobody wrote down. Record for each asset its address, function, owner, firmware version and whether it can be patched. The NetSenX network map, on every plan, lists devices seen on monitored segments with the names they announce and first and last seen, and from the Pro plan NetSenX reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm. It never probes OT devices, so it does not query firmware versions; those come from your engineering tools.

https://netsenx.com/en/faq/how-to-build-an-ot-asset-inventory-without-active-scanning

## Which OT devices does passive monitoring miss?

Devices that do not talk on a segment you mirror. That includes devices that are silent most of the time, such as a spare controller or a unit that only answers a master you do not see; devices on serial fieldbuses such as Modbus RTU or Profibus; devices behind an unmanaged switch whose traffic never reaches the mirrored link; equipment that talks only over its own cellular router; and remote sites without a sensor. Passive monitoring also sees less inside encrypted protocols, and it cannot read a firmware version that the device does not announce. Close those gaps with a walk-down, the engineering project files and, where the plant accepts it, a carefully planned query with the vendor's own tools during a maintenance window. NetSenX is passive only, so its network map shows what communicates on monitored segments, and nothing more.

https://netsenx.com/en/faq/which-ot-devices-does-passive-monitoring-miss

## How many sensors do we need to monitor three factories?

Usually one for each network segment you want to watch at each site, which typically means one to three per plant. The number depends on where traffic can be copied: a SPAN port on a plant's core switch often sees the traffic between office and production and between the SCADA servers and the line switches, while traffic inside a machine's own switch needs a sensor or TAP closer to it. Start with the boundary between office and production at each plant, then add the segments where controllers are programmed. Every plant needs a small host to run the sensor and a way to send alerts out. With NetSenX, each agent on a SPAN or TAP port counts as one device for the whole segment it watches, all plants appear in one dashboard, and the OT protocols are read from the Pro plan. The pricing page shows how many devices each plan includes.

https://netsenx.com/en/faq/how-many-sensors-do-we-need-for-several-plants

## Can we monitor OT with open-source tools on a small budget?

Yes, if someone has the time to run them. Mature open-source network monitors exist that can read several industrial protocols from a SPAN port. The cost is not the licence but the work: installing and updating the sensors, writing or tuning rules for your plant, storing the logs, building dashboards and, above all, having someone look at the alerts. For a plant with an OT engineer who enjoys this work, it can be a good start. If nobody has that time, the logs pile up unread, which gives you the feeling of monitoring without the result. NetSenX is the managed alternative: an agent on a SPAN or TAP port, alerts with a plain-language explanation, and the OT protocols from the Pro plan, with no rules for you to maintain. Whichever you choose, start with the boundary between office and production.

https://netsenx.com/en/faq/can-i-monitor-ot-with-open-source-tools-on-a-budget

## What is IEC 62443, and do we need it?

IEC 62443 is a series of international standards for the security of industrial automation and control systems. It covers the asset owner's security programme, the duties of integrators and service providers, the requirements for a whole system divided into zones and conduits, and the requirements for the products themselves, with security levels that describe how capable an attacker a zone should withstand. It is voluntary: no law requires a typical manufacturer to obtain certification against it, but customers, insurers and auditors increasingly use it as the yardstick, and its zones-and-conduits approach is a practical way to organise NIS2 risk measures in a plant. You do not need certification to benefit: divide the plant into zones, list the conduits between them and decide what each may carry. Monitoring then checks the conduits in practice. NetSenX can contribute that evidence: from the Pro plan it reads industrial protocols passively and flags traffic that crosses plant network levels.

https://netsenx.com/en/faq/what-is-iec-62443-and-do-we-need-it

## What evidence of attack detection in OT do auditors ask for?

Usually proof that detection exists, covers the right places and leads to action: which OT segments are monitored and how, which kinds of events are detected, who reviews alerts and how quickly, examples of alerts that were handled and what was decided, and how long the records are kept. In Germany, the Federal Office for Information Security (BSI) has published guidance on attack-detection systems for critical-infrastructure operators that auditors often use as a reference; other countries set their own expectations, so check with your national authority. A list of tools is not enough on its own: auditors look for a working process. A network map with first and last seen, alerts with timestamps and your notes on each decision make that process visible. NetSenX keeps alerts for your plan's alert history and, from the Pro plan, adds OT alerts for unauthorised writes, cross-level traffic, off-hours activity and S7comm commands. It does not certify you or replace the auditor's judgement.

https://netsenx.com/en/faq/what-evidence-of-attack-detection-in-ot-do-auditors-ask-for

## Are building management systems such as HVAC and BACnet a cyber risk?

Yes, and an underestimated one. Heating, ventilation, lighting, lifts and access control now run on networked controllers, often speaking BACnet/IP, with remote access for the service company and a cloud app for the facility manager. They are rarely patched, often keep default passwords, and are usually managed by a different team or an outside contractor rather than by IT. An attacker can use them to disrupt the building, or as a quiet foothold to reach the office network if the two are not separated. Ask your facility contractor where the system connects to, who has remote access and how, and put the building controllers on their own network segment with internet access limited to what the vendor really needs. NetSenX reads BACnet/IP from passive capture from the Pro plan and, on every plan, flags beaconing, scanning and unusual outbound volume from those controllers. There is no separate BACnet anomaly alert.

https://netsenx.com/en/faq/are-building-management-systems-a-cyber-risk

## Can a hacked heating or access-control system be used to reach our office network?

Yes, if the two share a network or the rules between them are loose. Building systems are often installed by a contractor on the same switches and address range as the office, or with a convenient route so that the facility manager can open the control software on an office PC. An attacker who gets in through the building system's remote access or a weak controller can then reach office computers as if from inside. Check where the building controllers and their server sit, whether they can reach office hosts and whether office hosts can reach them; usually only one management station needs to. Separate them with a firewall or a VLAN with strict rules, and route the contractor's remote access through your own gateway. On a monitored segment, NetSenX flags scanning and lateral movement from a building controller towards office hosts on every plan, so a controller that starts exploring the network stands out.

https://netsenx.com/en/faq/can-a-hacked-heating-or-access-control-system-reach-the-office

## Is it normal for a CCTV recorder to connect to servers abroad?

It can be, but you should know why it does. Many camera recorders keep a permanent connection to the manufacturer's cloud so that the phone app can show video without opening a port on your router, and those servers may be in another country or continent. That connection is also a remote-access channel you never configured, run by a third party, and older recorders have a long history of security flaws. Find out from the installer or the manufacturer's documentation which service it is, decide whether you need remote viewing at all and, if not, switch off the cloud feature and block the recorder's internet access. If you do need it, keep the firmware current and change the default passwords. NetSenX shows the recorder's destinations from a SPAN or TAP port and flags beaconing and unusual outbound volume on every plan, so a recorder that suddenly uploads far more than usual stands out. Whether the vendor's cloud is acceptable stays your decision.

https://netsenx.com/en/faq/is-it-normal-for-a-cctv-recorder-to-connect-to-servers-abroad

## Is a meeting-room TV that talks to unknown servers a risk?

It can be. Smart TVs, conference screens and room-booking panels run their own operating systems, call home for updates, apps and advertising, and are rarely updated once installed. On the office network they sit next to the laptops that are presented on them, and some have microphones and cameras. Most of that traffic goes to the manufacturer's services, but you cannot tell from outside without looking. Switch off the features you do not use, such as voice control, app stores and viewing statistics, update the firmware, and move screens to a separate network for devices, with internet access limited to what they need and no access to office hosts. Laptops can then share their screen over a cable or a casting device on that network. NetSenX watches such devices without any software on them, from a SPAN or TAP port, and flags beaconing, scanning and unusual outbound volume on every plan.

https://netsenx.com/en/faq/is-a-meeting-room-tv-that-talks-to-unknown-servers-a-risk

## Why would our office printer connect to servers on the internet?

Usually for ordinary reasons: firmware updates, toner and usage reporting to the supplier, cloud printing and scan-to-cloud features. Managed-print contracts often include the reporting, so ask your supplier what the printer sends and where. The risk is that printers are full computers with old software, admin pages with default passwords and stored copies of scanned documents, and nobody watches them. Check the printer's settings for cloud and remote features you do not use and switch them off, update the firmware, set an admin password, and limit its internet access to the supplier's services. A printer that starts connecting to many internal addresses, or to new places outside, is worth a look the same day. NetSenX sees printers from a SPAN or TAP port without software on them, lists them on the network map and flags scanning, beaconing and unusual outbound volume on every plan.

https://netsenx.com/en/faq/why-would-an-office-printer-connect-to-servers-on-the-internet

## How do we secure warehouse handhelds and label printers?

Mostly with network design, because these devices cannot run security software. Put handheld scanners, label printers, conveyor controllers and the warehouse Wi-Fi on their own network segment that reaches only the warehouse management server and the printers it needs, not office PCs or the internet at large. Use a separate Wi-Fi network with per-device or certificate authentication instead of one shared password that every former temporary worker knows, keep the handhelds' operating system and apps updated through their management tool, and lock them to the warehouse app. Retire devices the vendor no longer updates. Then watch the segment, because one compromised handheld on a flat warehouse network can reach everything else. NetSenX watches the segment from one agent on a SPAN or TAP port: the network map lists the devices, and scanning, beaconing and unusual outbound volume are flagged on every plan.

https://netsenx.com/en/faq/how-to-secure-warehouse-handhelds-and-label-printers

## Does every warehouse scanner count as a device in NetSenX pricing?

No. NetSenX counts the agents you run, not the devices they watch. One agent on a SPAN or TAP port counts as one device for the whole segment it monitors, so forty handheld scanners, the label printers and the conveyor controller on one mirrored segment are covered by that one agent. An agent installed directly on a server or laptop also counts as one device, and watches that host. The planning question is therefore how many segments you need to watch and where you can copy their traffic, not how many devices you own. A warehouse with its own switch usually needs one agent there. Handhelds on Wi-Fi access points connected to that switch are seen when their traffic crosses the mirrored port. The pricing page shows the device limit of each plan, from Free upwards.

https://netsenx.com/en/faq/does-every-warehouse-scanner-count-as-a-netsenx-device

## How do we monitor medical or lab devices that cannot run security software?

From the network, the same way as industrial equipment. Analysers, imaging devices, infusion pumps and lab instruments often run old operating systems that the manufacturer certifies and forbids you to change, so an endpoint agent is not an option. Put them on their own network segment that reaches only the systems they report to, such as the lab information system or the image archive, block internet access they do not need, and route each manufacturer's remote service access through your own gateway. A sensor on a SPAN or TAP port of that segment then sees their connections without touching them. NetSenX lists the devices on the network map and flags beaconing, scanning, lateral movement and unusual outbound volume on every plan. It does not decode medical protocols such as HL7 or DICOM, and it never decrypts traffic. Ask your data protection officer how the monitoring fits your records of processing before you switch it on.

https://netsenx.com/en/faq/how-to-monitor-medical-devices-that-cannot-run-security-software

FAQ: https://netsenx.com/en/faq