Blog
OT visibility without agents on controllers
You cannot install agents on PLCs, and auditors still ask about zones, remote access and controller changes. Start from the network data you already collect.
Plant networks are full of devices that cannot run security software. A PLC has no room for an agent, and no plant manager will accept one on a controller that runs a production line. Yet the questions keep coming. What is on the network? Which zones talk to which? Who connected remotely last month? Did anyone change a controller's program?
The good news is that much of the answer is already in data you collect. Firewalls between IT and OT, network sensors and remote-access gateways see plant traffic. Their logs often carry the protocol, the port and, for some protocols, the function code. That is enough to start.
Our view: begin OT visibility from the network, on the same platform as IT, and be honest about what the network can and cannot show.
Start from the questions auditors ask
Frameworks such as IEC 62443 and NERC CIP ask for evidence, not intentions. The recurring questions are practical:
- Inventory. Which OT assets exist, and which of them are actually sending telemetry?
- Segmentation. Is traffic between zones going only through the conduits you defined?
- Remote access. Who reached the plant from outside, when, and through what?
- Controller integrity. Were there writes, program downloads, mode changes or stop commands, and were they expected?
- Legacy exposure. Which assets are unpatchable, and how exposed are they?
- Safety systems. Is anything touching safety-instrumented systems that should not be?
Each of these can be answered, at least in part, from network data.
Five steps to OT visibility
1. List the sources that see plant traffic
Walk the network from the IT boundary inwards. Note every firewall, sensor and gateway that sees OT traffic, and check what its logs contain. A log that records only addresses and ports gives you less than one that also names the protocol.
2. Define zones and conduits as network ranges
Write down your IEC 62443 zones and the conduits between them, as address ranges. This turns a drawing into something a platform can check traffic against.
3. Agree a protocol allow-list per zone
Which protocols are expected where? Modbus inside a cell, perhaps, but not across the boundary. An allow-list makes unexpected traffic stand out, and gives the plant team a concrete thing to review.
4. Watch the operations that change the plant
Reads and polls are routine. Writes, mode changes and stop commands are not. Where the network data carries function codes, separate the risky operations from the rest, and review them.
5. Be explicit about the limits
Network data shows what crossed the wire and was recorded. It does not show what a controller did internally, and it cannot show traffic your sensors never saw. Write those limits into the scope of your OT monitoring, so nobody mistakes coverage for completeness.
Bring IT and OT together
An attack that reaches a plant usually starts in IT: a phished account, a compromised remote-access path, a jump host. If IT and OT evidence sit in different tools, the investigation breaks at the boundary. Keep them on one platform and one audit trail, so the path from the first IT signal to the plant is one story.
How kymeer approaches this
kymeer recognises 11 industrial protocol families in the events your sources already send: Modbus, DNP3, S7comm, OPC UA, IEC 60870-5-104, IEC 61850 (including GOOSE and MMS), EtherNet/IP (CIP), PROFINET, BACnet, FINS and SLMP (MELSEC). It reads the protocol label in an event and, if there is none, falls back to the protocol's well-known port where one exists. Where an event carries a function code or operation, it is classed as a stop, a mode change, a write or other, so writes, mode changes and stop commands stand out.
Eight OT dashboards turn that into evidence:
- OT asset inventory and coverage
- IT/OT segmentation, across IEC 62443 zones and conduits you define as network ranges
- OT remote access, referencing NERC CIP-005 R2 and IEC 62443 SR 1.13 and 2.6
- controller integrity, referencing NERC CIP-010 R1 and IEC 62443 SR 3.4 and 7.6
- protocol allow-list
- NERC CIP evidence
- legacy exposure
- safety-instrumented systems
Nothing is installed on controllers. The kymeer agent runs on Windows, macOS and Linux endpoints; the OT views work from network data, on the same platform and audit trail as IT. The dashboards show what your network sources record: protocol labels, ports and, where present, function codes.
Read the OT visibility guide, or see OT visibility.