Seraxi
Seraxi Relay

OT security that never touches the process

Seraxi Relay is OT security built on the Trace sensor. It listens passively to industrial networks, identifies PLCs, RTUs, HMIs and SCADA servers from the wire, places them on the Purdue model and watches the control traffic itself — Modbus, DNP3, IEC 104, IEC 61850, OPC UA, PROFINET, EtherNet/IP, S7comm — with a self-hosted AI that learns what normal looks like for your process.

L3 eng-ws-12 · historian L2 scada-a · hmi-02 L1 PLC-07 · rtu-3 L0 pump-4 · valve-9 Purdue L0–L3 · passive COM NC · process NO · alarm trip · Modbus FC16 · outside window → operator · PCAP · ticket

What it answers

Listen, map, protect

Like a protection relay in a substation, Relay sits in the circuit, watches continuously, and trips only when something is wrong — a write outside the change window, a cold restart from an unauthorised source, a firmware download at 03:00, a session from IT reaching a controller. It never sends a packet to the process. Everything it sees is kept as evidence in Trace Analysis, and the same self-hosted AI that explains IT threats explains OT ones in the language of the plant.

A PLC took a write from a workstation. Was that supposed to happen?
Relay knows the Purdue level, the protocol and the maintenance window; the write is flagged in seconds and the packets are kept.
What is actually on the plant network — every PLC, RTU, HMI?
Passive discovery from the wire: vendor, model, firmware and protocol for 50+ device types, placed on the Purdue model automatically.
Can we do this without scanning or touching the process?
Yes. Relay only listens on a SPAN/TAP. Zero packets are sent to the process; there is nothing to install on any controller.
Who crossed the IT/OT boundary last night?
Every L3→L2→L1 crossing is recorded with source, protocol and time — and the raw traffic is one click away in Trace Analysis.

See it in action

The plant, on the Purdue model — live.

Relay's OT stream shows writes, restarts and boundary crossings as they happen, each backed by packets; the Purdue map places every identified controller, HMI and field device on its level with vendor, model and protocol.

relay · purdue map · plant-a Purdue map 47 assets · 9 protocols · passive · last packet 2 s ago PLC / RTU 18 HMI / SCADA 7 Alerts 2 IT / OT boundary · conduit fw-ot-01 L3 Operations / IT eng-ws-12 Windows 11 RDP · S7 historian AVEVA PI OPC UA jump-01 Linux SSH L2 Supervisory · SCADA / HMI scada-a Siemens WinCC S7comm hmi-02 Schneider Vijeo Modbus/TCP eng-srv Rockwell Studio CIP L1 Control · PLC / RTU PLC-07 Siemens S7-1500 S7comm · Modbus rtu-3 ABB RTU560 DNP3 · IEC 104 plc-03 Rockwell CompactLogix EtherNet/IP L0 Field pump-4 VFD · Danfoss PROFINET valve-9 Emerson HART / IP meter-2 Honeywell Modbus RTU/TCP Modbus FC16 write · L3 → L1 protocols: Modbus/TCP · DNP3 · IEC 104 · IEC 61850 · OPC UA · PROFINET · EtherNet/IP · S7comm · BACnet — passive, zero process impact
Purdue map — identified assets per level, IT/OT boundary, flagged L3→L1 write

Illustrative data shown. Your deployment runs entirely on your own appliance.

What it does

01

Passive protocol decoding

Modbus/TCP, DNP3, IEC 60870-5-104, IEC 61850 (GOOSE / MMS), OPC UA, PROFINET, EtherNet/IP (CIP), S7comm and BACnet decoded natively — function codes, points and commands, not just flows.

02

Purdue asset map

Every asset identified from the wire — Siemens, Schneider Electric, Rockwell, ABB, Honeywell, Emerson, Mitsubishi, Omron, GE Vernova, Yokogawa, Phoenix Contact, Beckhoff, Hitachi Energy — and placed on Purdue L0–L3 automatically.

03

Control-traffic baselining

The self-hosted AI learns who writes to which controller, when, and with which function codes; deviations are scored against the process baseline, not a generic IT model.

04

IT / OT boundary monitoring

Every crossing of the conduit between L3 and the control network is recorded: source, protocol, time, session — the audit trail IEC 62443 zones and conduits expect.

05

Lifecycle & exposure of controllers

Firmware versions, end-of-support trains and known advisories per controller, matched from what the device says on the wire — the Keep-style assurance question, answered for OT.

06

Evidence, not just alerts

Every OT event is backed by the packets in Trace Analysis. Hand the PCAP to the integrator, the vendor or the regulator; nothing was inferred from a log.

How it works

Relay is deployed on a SPAN/TAP in the OT segment, builds the Purdue map from what it hears, and then watches the control traffic itself.

  1. 01

    Listen

    Connect the Trace sensor to a SPAN/TAP on the OT segment. Nothing is installed on controllers, nothing is sent to the process.

  2. 02

    Map

    Assets are identified and classified from the wire, placed on Purdue L0–L3, with vendor, model, firmware and protocols per device.

  3. 03

    Protect

    Writes, restarts, firmware loads and boundary crossings are scored against the process baseline by a self-hosted AI, with packets kept as evidence.

Why plants run Relay

  • Full OT asset inventory without a single active scan — safe for controllers that were never designed to be probed.
  • Detect the write, the restart and the firmware load that should not have happened, in the protocol's own terms.
  • See every IT/OT boundary crossing, with the evidence IEC 62443 and internal audit ask for.
  • One sensor for IT and OT: the same appliance, the same AI, the same PCAP evidence.
  • Explain OT events in the plant's language — controller, function code, change window — not in SOC jargon.
relay · plant-a live

OT posture

last 24h
47
OT assets
9
Protocols decoded
2
Boundary crossings
0
Process impact
Exposure by severity
Critical
High
Medium
Low

Part of the Seraxi platform

See Seraxi on your environment.

Book a technical walkthrough. We'll map Trace, Keep, and Lens to your fleet and show you a real backup, capture, and exposure picture — not a slide deck.

Book a demo