OT security monitoring platform (asset visibility and threat detection) rollout playbook: phased implementation with security built in

An OT security monitoring platform is given a copy of the most sensitive traffic in an industrial site and, often, credentials and routes into controllers, so a careless rollout can add risk to the process it was bought to protect. This playbook covers rolling out an OT asset visibility and threat detection platform as a product class: scoping against an inventory model, deciding where sensors sit, choosing passive and active discovery safely, building the management plane so it does not become a new path into Level 1 and 2, tuning detection against a baseline, and handing over to operations with metrics. It is vendor-neutral and based on NIST SP 800-82 Rev. 3, the 2025 joint asset inventory guidance led by CISA, ISA/IEC 62443, CISA's primary OT mitigations and MITRE ATT&CK for ICS. It is written for OT security leads, control system engineers and the SOC teams who will consume the alerts. Principles of OT security are in the OT Security Guide, sensor and protocol detail in the OT Network Security Monitoring Guide, and product selection in the OT Security Platform Buyer's Guide.

Key takeaways

• Start from an inventory model, not a sensor box. Agree scope, criticality tiers and the attributes you need before deployment, so the platform fills a defined inventory rather than generating an unowned asset list.
• Passive first, active only with the process owner. Listen on SPAN or taps everywhere first; enable any active or protocol-native queries per zone, per device family, after testing on spare or lab equipment.
• The management plane is a new conduit. Sensor-to-console traffic, console administration, remote vendor support and any controller credentials stored in the platform must be designed as zones and conduits in their own right.
• Baseline before you alert. Industrial networks are deterministic, so a learned baseline makes detection sharp, but only if the learning window is reviewed by engineers who know what normal looks like.
• Operations must own the outputs. Alerts that only the security team can read, and an inventory that engineering never reconciles, are the most common reason these programmes stall after the first year.

Phase 0: scope, governance and the inventory model

The joint guide Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators, published in August 2025 by CISA with the EPA, NSA, FBI and partner agencies in Australia, Canada, Germany, the Netherlands and New Zealand, sets out a process that suits a platform rollout well: define scope and objectives, identify assets and collect attributes, create a taxonomy, manage and collect data, and implement life cycle management. Use it as the backbone of the project plan.

• Governance: name the authority that requires the inventory, who collects and who validates data, and the boundaries in scope (sites, zones, timelines). A platform deployed without this produces data that nobody is accountable for.
• Attributes: the guidance lists high-priority attributes including communication protocols, asset criticality, asset number, role or type, hostname, IP and MAC address, logging, manufacturer, model, operating system, physical location, ports and services, and user accounts. Check which of these the platform can populate passively and which need engineering records or physical inspection.
• Taxonomy: classify by criticality or function and organise by zones and conduits. The guidance references ISA/IEC 62443 for this model but allows others.
• Where to start: the guidance notes that ports and services data is time-consuming to maintain and suggests starting with assets that communicate outside the OT perimeter or with SCADA devices over a wide area network.

Also agree the safety rules at this stage: who can approve a change on a control network, what counts as a change (connecting a tap does; mirroring a switch port usually does under site change control), and which plants or units are excluded until an outage window. See the OT Asset Visibility Guide for the visibility programme this platform serves.

Phase 1: architecture and sensor placement

Sensors are placed to see the conversations that matter: supervisory to controller traffic, engineering workstation sessions, cross-zone flows and remote access paths. NIST SP 800-82 Rev. 3 describes OT topologies and the layered defence model that should guide placement.

• Mirror ports and taps: SPAN can drop packets when a switch is busy; use passive taps on high-value links. Taps are physical work and usually need an outage window, so schedule them with the process owner.
• Sensors are one-way listeners: the capture interface should have no IP address and no route back to the monitored network. Management traffic leaves on a separate interface into a dedicated management zone.
• Central or local analysis: decide whether sensors forward full packets, metadata or alerts. Metadata-only forwarding reduces bandwidth across sites and limits how much sensitive process data leaves the plant.
• Time: sensors need a trusted time source so events correlate with historian, controller and SIEM records.

Phase 2: discovery modes and process safety

Platforms in this class typically offer passive discovery (parsing captured industrial protocols), and some add active or protocol-native queries that ask devices for model, firmware and configuration. Active queries give richer inventory and vulnerability context but send traffic to devices that may be fragile or running a process.

Our recommendation: never enable generic IT network scanning against Level 0 to 2. Treat any active capability as a change under site management of change, enabled per zone with a named approver, and record which devices have been queried and how. MITRE ATT&CK for ICS lists T0846 Remote System Discovery and T0888 Remote System Information Discovery as adversary techniques; your own platform's active discovery looks identical on the wire, so tell the SOC when and from where it runs.

Phase 3: securing the platform as it is built

Hardening of a running platform is covered in Securing the OT security monitoring platform itself. During rollout the decisions that are hard to change later are these:

• Place the console deliberately: on-premises in the industrial DMZ or a dedicated OT security zone, or hosted by the provider. A hosted console means plant metadata leaves the site; agree what data is sent, where it is stored and for how long (NIST SP 800-53 SA-9 External System Services).
• Treat sensor-to-console links as conduits: outbound-only from sensor where possible, mutually authenticated and encrypted, through the site firewall with explicit rules (SC-7 Boundary Protection).
• Administrators: named accounts through the workforce identity provider, MFA, and separate roles for platform administration, analysts, and engineers who acknowledge baseline changes. No shared vendor support account left enabled after commissioning.
• Stored device credentials: if active queries need controller or switch credentials, use read-only accounts, store them in the platform's protected store or a secrets manager, assign an owner and rotate them. These are non-human identities with reach into Level 1. See the OT and ICS Identity and Access Guide.
• Vendor remote support: route it through the site's approved OT remote access path with session recording, not through a separate tunnel the platform opens on its own. CISA's primary mitigations call for secure remote access with strong credentials, MFA, least privilege and disabled dormant accounts.
• Updates: detection content and software updates should be staged, verified and applied on a schedule the site agrees, with a rollback image for sensors.

Phase 4: baseline, tuning and integration

1. Learning window: run in learning or monitor-only mode long enough to cover normal operating cycles, shift changes, batch runs and at least one maintenance activity. The length depends on the process; agree it with operations (our recommendation: two to six weeks for most continuous processes).
2. Engineer review of the baseline: walk the learned communication map with control engineers. Anything unexplained is either an inventory gap, a misconfiguration or a finding; do not simply accept it into the baseline.
3. Label authorised change: link the platform to work orders or change records so program downloads and parameter writes during approved work are labelled rather than raised as incidents.
4. Prioritise detections: start with high-signal events such as program download (T0843), parameter modification (T0836), new remote services sessions (T0886), new devices, and traffic crossing zones that should not talk.
5. Integrate: forward alerts to the SIEM or OT SOC with asset criticality attached, push inventory to the CMDB or asset register, and feed vulnerability context into OT patch planning. Integration accounts are covered in the OT security monitoring platform integration security guide.
6. Write response playbooks before go-live: who an analyst calls at the plant, what they may never do (for example isolate a controller without operations), and how to escalate. See the OT Security Operations Centre Guide.

Phase 5: pilot, site rollout and rollback

1. Lab or pilot site: prove capture, protocol decoding and any active queries against representative equipment, ideally a test bench or a non-critical unit.
2. One site end to end: deploy sensors, baseline, tune and integrate at one site; measure inventory coverage and alert quality before copying the design.
3. Site template: standardise sensor builds, firewall rules, role design and runbooks, then roll out by site criticality.
4. Rollback: passive sensors can be disconnected without process impact, but tap removal is physical work: keep an outage plan. Active discovery must have a documented off switch per zone, tested during the pilot.
5. Handover: agree day-2 ownership for sensor health, baseline changes and inventory reconciliation. See the OT security monitoring platform day-2 operations runbook.

Decision guidance

• Passive only or passive plus active: choose passive only where devices are fragile, undocumented or safety-critical and you lack a test bench. Add selective active queries where vulnerability context is worth the change effort and the vendor of the control system supports it.
• On-premises or hosted console: hosted reduces infrastructure work and suits organisations with many small sites; on-premises suits regulated operators who cannot send process metadata off site or have no reliable outbound path.
• Commercial platform or open toolchain: the OT Network Security Monitoring Guide covers the open route; it needs more in-house skill and protocol knowledge.
• Small versus large operators: a single-site operator may start with one sensor at the Level 2 to Level 1 boundary and a managed service watching it; a multi-site operator needs a site template, central console, OT SOC process and inventory reconciliation with engineering.

Where identity fits

The platform is one of the best sources of evidence about identities in OT: shared engineering accounts, vendor sessions, default credentials seen in cleartext protocols and service accounts used by historians. CISA lists replacing default passwords and securing remote access among its primary OT mitigations. Feed these observations into identity work rather than leaving them as alerts. Dormant remote access accounts are a recurring entry point: the Colonial Pipeline ransomware attack began with an unused VPN account. See the OT Remote Access Guide.

Detection and measurement

Monitor the platform itself as well as what it sees: sensor health and packet loss, gaps in capture, administrator logins, baseline acceptance, changes to detection rules and any active query runs.

Framework mapping

Common failure patterns

• IT scanning habits in OT: active discovery enabled site-wide at go-live, without per-device testing or process owner approval.
• Baseline accepted blindly: the learning window absorbs existing bad traffic, such as an unexpected internet path, into "normal".
• A new unmanaged conduit: sensors with routable capture interfaces, or a vendor support tunnel outside the approved remote access path.
• Stored controller credentials with write rights: discovery accounts that could change configuration, held without an owner or rotation.
• No link to change control: every authorised download raises an alert, analysts learn to ignore the category, and the real one is missed.
• Inventory never reconciled: the platform's asset list diverges from engineering drawings and nobody owns the difference.

Practitioner checklist

• Adopt the joint inventory process and attribute list as the project's definition of done.
• Map capture points to zones and conduits; prefer taps on Level 2 to Level 1 links.
• Build sensors with non-routable capture interfaces and a separate management path.
• Gate every active query behind lab testing, a named approver and a per-zone off switch.
• Use read-only, owned and rotated credentials for any device queries.
• Route vendor support through the approved OT remote access path with recording.
• Review the learned baseline with control engineers before enabling alerts.
• Link alerts to change records and agree plant escalation before go-live.
• Track capture coverage, inventory reconciliation and sensor health monthly.

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: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• ISA: ISA/IEC 62443 Series of Standards
• MITRE ATT&CK for ICS: Program Download
• MITRE D3FEND: Network Traffic Analysis
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: OT security monitoring platform health check · OT security monitoring platform RFP template · OT Security Assessment Guide · OT Network Segmentation Zones and Conduits Guide