OT Analyzer reads a network capture from your plant floor and tells you what's really on it: every asset, every industrial protocol conversation, and every security finding worth a plant manager's attention — with nothing installed on the OT network itself.
Most tools in this space either need agents on hardware you can't touch, or bolt ICS support onto an IT product. OT Analyzer starts from a capture file and a rules engine designed around real plant-floor traffic.
Point it at a packet capture from a SPAN or mirror port you already have — nothing gets installed on a PLC, HMI, or engineering workstation, and nothing touches the OT network live.
Every asset and flow is evaluated against fixed, explainable logic — the same capture always produces the same findings. No black-box scoring, no opaque model deciding what's a risk.
Mirrored traffic misbehaves — RSPAN re-tags frames with its own VLAN ID as they cross the network. OT Analyzer checks each VLAN's device subnets for that pattern automatically, instead of reporting a false segmentation problem.
A client-ready PDF report and a self-contained, interactive topology map — zero external scripts, zero CDN calls. Opens offline, which matters when the environment you're reporting on is air-gapped.
Every stage below runs from the same pipeline — asset discovery, protocol parsing, classification, detection, and reporting stay in sync because they're the same run, not separate tools stitched together.
Automatically identifies PLCs, HMIs, SCADA servers, and engineering workstations from observed traffic — no manual asset inventory to keep up to date.
Purpose-built parsers for Modbus, EtherNet/IP (CIP), and DNP3 — plus the surrounding IT protocols (ARP, DNS, SNMP, TLS, HTTP, FTP, SMB) that show up on the same segments.
Checks for insecure legacy protocols reaching control assets, cleartext credentials, unexpected control masters, weak segmentation, default community strings, and more.
Builds the network diagram from the traffic itself — segments, assets, and the relationships between them — so the map reflects what's actually on the wire.
Every finding ships with the evidence behind it and a concrete remediation step — written for someone running a plant, not sifting through a SOC queue.
A formatted PDF report and an offline interactive topology view are generated on every run — ready to hand to a plant manager or attach to an audit.
308 assets across 9 network segments, mapped automatically from a single packet capture — no manual diagramming, no live access to the network it describes. Pan, zoom, and click into it below.
Every SCADA server and workstation gets fingerprinted from its own service-port behavior — never from a single generic industrial port alone. It currently recognizes:
Identified because the SCADA server exposed 3 or more of the Citect/Plant SCADA runtime-family TCP ports (2080, 2082, 2084, 2085, 5482) — a distinctive multi-port cluster, not a single generic port. A single match would only earn Medium confidence; this one cleared the High bar.
Every asset gets a Primary Role once the evidence is strong enough to justify it. When it isn't, OT Analyzer reports a confidence-based Possible Role instead of guessing — or leaves the asset Unknown rather than forcing an identification it can't back up.
Insufficient evidence was observed to reliably determine a specific asset role. OT Analyzer keeps the asset unclassified rather than forcing an unsupported identification.
An asset observed initiating industrial communications with one or more OT endpoints — may be a SCADA server, HMI, engineering workstation, gateway, or another control system.
An endpoint observed participating as a device in CIP/EtherNet/IP communications. CIP participation alone does not establish that the asset is a PLC.
An industrial controller identified through sufficiently strong evidence, such as explicit device identity information or protocol behavior specifically consistent with a programmable controller.
An industrial device identified as providing remote I/O functionality and exchanging process I/O data with a controller.
A CIP device whose evidence indicates an industrial communications or network-adapter function rather than a PLC/controller function.
An endpoint observed operating as a device/server in Modbus communications. Modbus participation alone does not identify it as a PLC, RTU, or other specific hardware type.
A Modbus device whose observed characteristics are consistent with a UPS, power-management device, or related electrical infrastructure.
An endpoint observed operating as a DNP3 outstation, typically responding to communications initiated by a DNP3 master or control system.
An endpoint observed participating as a field/server-side device in IEC 60870-5-104 communications — may be an RTU, IED, or another IEC-104 endpoint.
An endpoint observed participating as a device in S7 communications. S7 participation alone does not automatically establish the physical device as a PLC.
An industrial asset identified through PROFINET communications or discovery behavior and observed participating as a device on a PROFINET network.
An asset observed providing OPC UA services to other systems — potentially supplying or brokering industrial data for SCADA systems, HMIs, historians, or other clients.
An asset observed performing BACnet Broadcast Management Device functions used to distribute BACnet broadcast communications across IP networks.
An asset with sufficient evidence to infer a SCADA server function based on industrial communication patterns combined with additional platform, service, or architectural evidence.
An asset whose observed behavior is consistent with a SCADA client, operator workstation, or engineering workstation.
An asset observed providing Domain Name System services to other devices on the network.
An asset whose observed network behavior is consistent with network-attached storage or file-serving functionality.
These fill the gap when evidence points toward a function but isn't strong enough to promote the asset to a definitive Primary Role.
Capture your traffic once. Everything downstream — assets, findings, diagrams, and the report — comes from that same run.
Bring a .pcap from an existing SPAN/mirror port. No new hardware, no live traffic injection.
Protocol-aware parsers reconstruct flows, device identities, and industrial-protocol activity.
Assets are assigned roles — PLC, HMI, SCADA server, workstation — from how they actually behave.
The rules engine evaluates every asset and flow against 30+ OT-specific security checks.
A PDF report and an offline interactive topology map are written out automatically.
You don't need new hardware or a live connection to the OT network — just a copy of traffic that's already crossing a switch you control.
Most managed switches near your PLCs, HMIs, or SCADA server support port mirroring. Ask whoever manages that switch to mirror the relevant port(s) to a spare one — production traffic is untouched.
Plug a laptop running Wireshark or tcpdump into the mirror port. Nothing is installed on the PLCs, HMIs, or workstations, and nothing sends traffic back into the OT network.
Capture for at least 30–60 minutes during regular operation — long enough to see typical polling cycles, HMI-to-PLC traffic, and any periodic maintenance or backup jobs.
No special export or conversion step — this is the same file Wireshark or tcpdump already produce.
Every finding is tied to real evidence — a specific flow, protocol, and pair of assets — not a generic vulnerability score.
We'll walk through a live run — asset discovery, the rules engine, and the topology output — and talk through where it fits alongside what you're already running.
Thanks — someone from OT Secure Systems will reach out within one business day to schedule your walkthrough.