An OT security monitoring platform holds a complete map of your industrial estate, sensors inside every control zone and sometimes the credentials to query controllers, so an attacker who controls it gains the reconnaissance, access and blind spots needed to disrupt physical processes. These platforms passively decode industrial protocols from switch mirror ports and taps, build an asset inventory with firmware versions and vulnerabilities, raise alerts on unusual commands, and in many deployments run selective active queries against controllers. That makes the platform itself one of the most sensitive systems in the plant. This guide is for OT security engineers, control system owners and SOC leads who run asset visibility and threat detection platforms on premises, in a site data centre or with a cloud console. It covers admin roles, sensor placement and management, active query credentials, the inventory as sensitive data, integrations, the platform's own logs and the lifecycle. It is vendor-neutral: confirm exact settings in your product's documentation. For what to monitor and how to build the inventory, see the OT Asset Visibility Guide.
Key takeaways
- The inventory is an attacker's reconnaissance in one export. Device models, firmware, IP addresses, open services and known vulnerabilities across every zone are exactly what ATT&CK for ICS discovery techniques try to collect; restrict and log access to it.
- Sensors must not become conduits. A sensor sits on a level 1 or 2 network and talks to a central console; its management path must be a defined, filtered conduit, never a bridge between zones.
- Active query credentials are OT privileged accounts. Accounts and protocol access used to query controllers can often also change them; scope them, vault them and use them only in approved windows.
- Passive by default, active by approval. Active queries can disrupt fragile devices; engineering must approve each device class and the platform must enforce it.
- Silence is the attack. Disabled sensors, suppressed alerts and dropped mirror sessions hide an intrusion; monitor the monitor from outside it.
Why the OT monitoring platform is a high-value target
NIST SP 800-82 Rev. 3 (final, September 2023; a Revision 4 draft is open for comment), the US guide to OT security, recommends monitoring OT networks and maintaining asset inventories, and both functions concentrate sensitive information in the monitoring platform. The CISA-led Foundations for OT Cybersecurity guidance, written with agencies including NSA, FBI, EPA and partners in Australia, Canada, Germany, the Netherlands and New Zealand, treats the asset inventory and its supplemental taxonomy as the foundation for identifying and securing critical assets; the same data, if stolen, gives an adversary the system knowledge that ATT&CK for ICS techniques such as T0846 Remote System Discovery and T0888 Remote System Information Discovery otherwise take time and risk to collect.
The component table reflects a common architecture and is NHI Mgmt Group's view, not a description of any one product.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Central console (site or cloud) | Inventory, network map, vulnerabilities, alerts, baselines, users | Exports the plant map, suppresses alerts, learns the attack path | SSO with phishing-resistant MFA, least-privilege roles, export logging |
| Passive sensors | Copies of industrial traffic, local packet buffers, management link to console | Reads process traffic (T0842), bridges zones, stops monitoring | Receive-only capture ports, filtered management conduit, hardened OS |
| Active query engine | Credentials and protocol access to controllers, switches and workstations | Reads or changes controllers, causes device restarts (T0816) | Vaulted, scoped credentials, approval per device class, query windows |
| Baselines and alert rules | What counts as normal programming or communication | Learns malicious activity into the baseline, suppresses alarms | Change approval, review of baseline updates |
| Integrations | Keys into SIEM, CMDB, firewalls, vulnerability and ticketing tools | Pivots to IT systems or pushes blocks into OT firewalls | One scoped key per integration, outbound-only from OT where possible |
| Vendor cloud and update channel | Threat content, software and firmware updates, possibly telemetry | Supply chain route into every sensor | Verified updates, controlled egress through the DMZ |
Admin roles and console access
- Role design: separate platform administrator (sensors, integrations, users), OT security engineer (rules, baselines, active query policy), analyst (alerts and asset views), operations viewer (site-scoped read) and integration owner. Scope users by site or zone where the platform allows it.
- Inventory export is a privilege: bulk export of the asset list, network map or vulnerability report should be limited to named roles, logged and alerted above a set volume.
- Authentication: SSO with phishing-resistant MFA for the console. The CISA-led Secure by Demand priority considerations for OT owners and operators encourage buyers to ask manufacturers about secure by design elements before purchase; strong authentication and logging belong on that list (our reading). Keep one break-glass account that works when the site is isolated from corporate identity, and test it. See the Break-Glass Account Guide.
- Where the console lives: place an on-premises console in the OT DMZ or site operations zone, not on the corporate network, and reach it from IT only through a brokered conduit. See the OT Network Segmentation, Purdue Model and IEC 62443 guide.
- Admin devices: follow the NCSC secure system administration principles and administer from OT engineering or privileged access workstations, not general IT laptops. See the Privileged Access Workstations Guide.
Sensors and the management conduit
| Design point | Setting | Why |
|---|---|---|
| Capture interfaces | Receive-only from SPAN ports or passive taps; no IP address on capture ports | The sensor cannot transmit into the monitored zone |
| Management interface | Separate interface to a management network or the OT DMZ; firewall rules allow only the console and update source | Sensor management is a defined conduit, not a route between levels |
| Direction of connections | Prefer sensor-initiated, encrypted connections to the console | No inbound management services exposed in control zones |
| Sensor OS and local access | Default credentials changed, unused services off, local console and USB restricted, disk encryption where offered | Sensors sit in plant cabinets with limited physical security |
| Mirror source | SPAN and tap changes under OT change control; alerts on lost traffic | A dropped mirror session looks like a quiet network |
- Map each sensor as a conduit: record in your zones and conduits model which zone it monitors, where its management traffic goes, and the firewall rules that allow it.
- Test that capture is passive: before go-live, confirm with a packet capture that the sensor transmits nothing on capture interfaces.
- Verify and stage updates: obtain sensor software and threat content through the DMZ, verify vendor signatures or checksums, install on one sensor first and keep the previous version for rollback.
- Patch on an OT-appropriate cadence: the platform is a security tool, so apply its security updates faster than general OT patching where the vendor confirms no process impact (our recommendation). See the ICS Advisory Triage and OT Vulnerability Management Guide.
Active query credentials and device access
Many platforms supplement passive discovery with active queries: reading controller details over native industrial protocols, polling switches with SNMP, or querying Windows engineering workstations. Each method uses identities and protocol access that an attacker would value.
| Query method | Credential or access | Risk | Control |
|---|---|---|---|
| Native controller protocol read | Protocol access, sometimes a controller project password | Same channel can often write or change mode | Read-only where the device supports it, approved device classes, query windows |
| SNMP to switches and devices | SNMP community or SNMPv3 user | Write communities allow configuration changes | SNMPv3 with authentication and privacy, read-only views |
| Windows workstation and server queries | Domain or local account with remote access | Reusable for lateral movement (T0859, T0886) | Dedicated account, logon limited to query sources, no interactive logon |
| Historian or engineering software APIs | API key or service account | Process data access | Read-only role, separate key per platform |
- Vault and attribute: store query credentials in a vault or the platform's encrypted credential store, one per method and site, with an owner and rotation plan. See the Identity for OT Environments Guide.
- Engineering approval: require control engineering sign-off for each device class and query type, tested on a bench first, and enforce the allowed list in the platform rather than in a document.
- Rollback: keep a one-step way to disable all active queries for a site, and use it if any unexplained device fault follows a query.
The inventory, packets and data handling
- Classify the data: treat inventories, network maps and vulnerability lists as sensitive security information, with the same handling rules as network diagrams.
- Packet captures: industrial captures can contain setpoints, recipes and cleartext credentials of legacy protocols; restrict download and set retention.
- Cloud consoles: know which data leaves the site, where it is stored, who at the vendor can see it and how deletion is confirmed. Some sites, such as those under national security rules, may require on-premises only.
- Sharing: share inventory extracts with integrators and vendors only on a need-to-know basis, with expiry.
Integrations
| Integration | Needs | Avoid |
|---|---|---|
| SIEM or SOC | Send alerts and selected events outbound | Inbound connections from IT into OT zones |
| CMDB or IT asset tool | Receive asset records | Write access back into the OT platform |
| OT firewall or network access control | Optional block or quarantine actions | Automated blocking in control zones without engineering approval |
| Ticketing and vulnerability management | Create tickets and read status | Shared keys with other tools |
Give each integration its own scoped key, prefer outbound connections from OT to IT through the DMZ, and record each key in your NHI inventory with an owner. Automated response in OT is a safety decision, not just a security one: default to alert-only and require engineering approval for any blocking. See the Service Account Security Guide.
The platform's own logs
| Event | Why it matters | Alert? |
|---|---|---|
| User or role change, SSO or MFA setting change | Persistence in the console | Always |
| Alert rule disabled, suppression added, baseline relearned | Blind spot for malicious commands (T0878 Alarm Suppression is the process equivalent) | Always, with approver |
| Inventory, map or vulnerability export | Reconnaissance data leaving the platform | Above a set volume |
| Active query policy or credential changed | Risk to controllers | Always |
| Sensor offline, capture traffic dropped, mirror lost | Loss of visibility (T1685) | Always |
| Software or content update applied | Supply chain and change tracking | Unplanned updates |
Forward audit logs to a SIEM or archive that platform administrators cannot alter (NIST SP 800-53 AU-9(2)), synchronise time from an OT time source, and alert on sensor heartbeats from that system rather than from the platform alone.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Use the Secure by Demand priority considerations for OT owners and operators as the base question set; cover strong authentication, logging, vulnerability handling and secure update. Ask what data leaves the site and how active queries are controlled. See the OT Security Platform Buyer's Guide and RFP template. |
| Deploy | Design management conduits first; passive only for the first weeks; change default credentials; enable SSO and log export before connecting more sites. See the implementation playbook. |
| Run | Quarterly review of users, exports, query credentials, integrations and suppressions; staged updates; test break-glass access. |
| Retire | Remove SPAN and tap configuration under change control; revoke query credentials and integration keys; wipe sensors and console storage and record it; obtain vendor deletion confirmation for cloud data. |
Decision guidance
- Cloud or on-premises console: cloud consoles reduce site infrastructure but move the plant map off site; on-premises consoles keep data local but need the site to patch and back them up. Regulated or high-consequence sites usually choose on-premises or a site-hosted console with selective cloud alerts.
- Passive only or with active queries: passive is safer and enough for most detection; add active queries where firmware accuracy matters for vulnerability management and the device class is tested.
- Small sites: a single sensor and a central console reached over the DMZ, with SSO, export logging and no active queries, gives most of the value with little added risk.
Detection and measurement
- Percentage of sensors whose management traffic follows a documented, filtered conduit.
- Number of users with export rights, and exports per month with a reason.
- Active query credentials vaulted, scoped and rotated, as a percentage of all.
- Suppressions and baseline changes past review date (target: zero).
- Sensor health: monitored zones with a healthy sensor and no traffic loss.
- Time to detect a stopped sensor or disabled rule, measured in a test.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK for ICS or Enterprise |
|---|---|---|---|
| Console roles and exports | AC-2, AC-6, AC-6(5), IA-2(1) | PR.AA-05 | T0859 Valid Accounts |
| Sensor isolation and conduits | SC-7, SC-7(13) | PR.IR-01 | T0842 Network Sniffing |
| Active query credentials | IA-5, AC-6 | PR.AA-01 | T0886 Remote Services, T0816 Device Restart/Shutdown |
| Inventory as sensitive data | SC-28 | ID.AM-01, PR.DS-01 | T0846 Remote System Discovery, T0888 Remote System Information Discovery |
| Audit log and sensor health | AU-6, AU-9(2), SI-4 | DE.CM-01 | T1685 Disable or Modify Tools |
| Vendor updates | SA-9, SR-3, SI-7 | GV.SC-07 | T1195 Supply Chain Compromise |
Common failure patterns
- Sensor as a bridge: a sensor with management on the corporate network and capture in level 2 becomes the path between them.
- Domain admin for active queries: one powerful account queries every workstation and is cached across the plant.
- Everyone can export the map: integrators and contractors download full inventories with no record.
- Baselines relearned after an incident: malicious activity becomes "normal".
- Automated blocking in a control zone: a false positive stops a process.
- Nobody watches the sensors: a switch change drops the SPAN session for months.
Practitioner checklist
- Place the console in the OT DMZ or site operations zone and reach it from IT only through a brokered conduit.
- Use receive-only capture ports and a filtered management conduit for every sensor.
- Enforce SSO with phishing-resistant MFA, site-scoped roles and a tested break-glass account.
- Restrict and log inventory, map and vulnerability exports.
- Vault active query credentials, use read-only access and require engineering approval per device class.
- Keep automated response alert-only in control zones unless engineering approves.
- Verify and stage updates through the DMZ, one sensor first.
- Export audit logs and alert on sensor silence from outside the platform.
- Review users, credentials, suppressions and integrations quarterly.
Standards and references
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- CISA and partners: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
- CISA and partners: Secure by Demand Priority Considerations for OT Owners and Operators
- NCSC: Secure system administration
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK for ICS: T0846 Remote System Discovery
- MITRE ATT&CK for ICS: T0878 Alarm Suppression
Related NHI Mgmt Group resources: OT Security Guide · OT Asset Visibility Guide · Securing the OT remote access platform itself · If your OT security monitoring platform is compromised · Securing the network detection and response (NDR) itself