Operational Technology Discovery deployment scenarios

  • Release version: Australia
  • Updated March 24, 2026
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Operational Technology Discovery deployment scenarios

    Operational Technology (OT) Discovery deployment scenarios vary depending on the network architecture of your OT environment. This guide helps ServiceNow customers determine how to deploy OT Discovery components—including Discovery Console for OT, Discovery Sensor for OT, and OT Discovery Collector—effectively across different network topologies such as flat networks, segmented sites, and micro-segmented sites with multiple networks.

    Show full answer Show less

    Each scenario considers key factors like network segmentation, communication pathways, network traffic, redundancy, and physical environment constraints to optimize deployment and discovery operations.

    Deployment Scenarios

    • Flat network architecture across multiple sites: All components connect within a single network allowing direct communication. One Discovery Console can manage multiple sites, with Sensors deployed to speed discovery. Consoles and Sensors reside at Purdue level 3.5, pushing data to ServiceNow through existing network infrastructure.
    • Multiple independent segmented sites: Network is divided into isolated segments, each with its own Discovery Console and Sensors. These segments operate independently without inter-site communication, enhancing security and visibility per zone. Consoles and Sensors report findings locally without direct internet access.
    • Micro-segmented site with multiple networks: Complex segmentation with multiple network segments, each containing its own Discovery Console and Sensors. Sensors must have communication pathways to their Consoles. OT Discovery Collector can be installed on existing hosts (e.g., HMI or Engineering Workstation) to assist discovery within the network segments.

    Key Components and Their Roles

    • Discovery Console for OT: Acts as the command-and-control interface for managing credentials, protocol handlers, and initiating discovery operations within its network segment.
    • Discovery Sensor for OT: Performs active discovery and network traffic analysis, querying known OT protocols (Modbus, DNP3, BACnet), and reports findings to the Console.
    • OT Discovery Collector: Installed on Windows or Linux hosts to collect data and perform discovery tasks, especially useful on existing operational hosts.

    Resource Recommendations

    To ensure efficient operation, consider the following minimum system requirements for OT Discovery components, while reviewing your own system needs based on network complexity and traffic:

    • Discovery Console for OT: Minimum 16 GB RAM, 100 GB hard drive, 2 CPUs.
    • Discovery Sensor for OT: Minimum 2 GB RAM (8 GB recommended for all queries), 100 GB hard drive, 2 CPUs, 2 virtual NIC cards.
    • OT Discovery Collector: Compatible with Windows 10/11 (x8664) or supported Linux systems; ARM or Apple Silicon devices are not supported.

    Practical Considerations

    When planning your OT Discovery deployment:

    • Assess your network segmentation and communication pathways to determine console and sensor placement.
    • Deploy multiple sensors to increase discovery speed in flat networks.
    • In segmented environments, isolate Consoles and Sensors per segment to enhance security and operational clarity.
    • Install OT Discovery Collectors on existing operational hosts where appropriate to leverage existing infrastructure.
    • Review physical and environmental conditions affecting hardware placement and network connectivity.

    Deployment scenarios for OT Discovery vary based on a network's architecture. Use these scenarios to help determine how to deploy the OT Discovery components in your OT environment.

    Note:
    The OT Discovery Collector can be deployed to the same locations as the Discovery Sensor for OT.

    General recommendations

    General recommendations and guidance are listed in each scenario in these sections. Not all networks are the same. The requirements in this section are a generalization for the scenario. Consider factors such as segmentation level, communication pathways, network traffic, redundancy, and environmental conditions. For resource recommendations for the Operational Technology Discovery components see the Resources for OT Discovery System section.

    Flat network architecture across multiple sites

    A flat network architecture is a network design that has all available Discovery Console for OT, Discovery Sensor for OT, and OT Discovery Collector connected to a single network, where the Sensors and Collectors can communicate with each other directly.

    You can have one or more sites that communicate with each other.
    Figure 1. Flat network
    Flat network

    The Console, Sensors, and MID Server connect at Purdue level 3.5 and push data through the switches and the firewall to the ServiceNow instance for ingestion.

    Components in the flat network

    The following are the components in a flat network.
    • Discovery Console for OT and Discovery Sensor for OT.
    • A localized appliance or VM that serves as the command-and-control interface for asset discovery and communication in its respective segment. This appliance or VM manages credentials, protocol handlers, and initiates querying operations locally. In such a scenario, a typical deployment means that one Console covers multiple sites.
    • Deploy the Console at a layer where the MID Server can connect to the Console and the ServiceNow instance.
    • Deploy Sensors based on the desired speed of the discovery. In a truly flat network, a Discovery Sensor for OT can reach all the OT assets in that network. More Sensors in the network can help improve the speed of discovery.

    Multiple independent segmented sites

    A segmented site architecture is a network design that has the network split into multiple segments. Each segment contains its own Discovery Console for OT and multiples of the Discovery Sensor for OT and the OT Discovery Collector. There is no communication between sites. Each of the segments could be considered a flat network.

    Figure 2. Segmented sites

    Segmented site
    In this OT environment, the network is segmented into three distinct zones for operational clarity, security, and control:
    • Site 1 Operational Technology segment
    • Site 2 Operational Technology segment
    • Physical Security Network segment
    Each segment contains its own isolated infrastructure to reduce risk and increase visibility in its respective domain. Components in each segment:
    • Discovery Console for OT or VM that serves as the command-and-control interface for asset discovery and communication in its respective segment. It manages credentials, protocol handlers, and initiates scanning operations locally.
    • Discovery Sensor for OT is deployed in each segment. The Sensor performs active discovery, collects network traffic, and queries for known protocols (for example, Modbus, DNP3, BACnet). It reports findings to its segment's Console.

    The Consoles and Sensors are deployed in their respective network zones and don't have direct outbound access to the internet.

    Micro-segmented site with multiple networks

    A segmented site architecture with multiple networks is a network design that has more than one network split into multiple segments. Each segment contains multiple network segments and its own Discovery Console for OT and Discovery Sensor for OT.
    • Make sure the Sensors and Collectors have a communication pathway to the Console.
    • Deploy Sensors in each segment where the Sensor can perform active discovery in the segment and collect network traffic and can scan or query for known protocols (for example, Modbus, DNP3, BACnet). It reports findings to its segment's Console.
    • If you use an existing host to do the discovery in the network such as Human Machine Interface (HMI) or Engineering Workstation (EWS), you can install the OT Discovery Collector to perform discovery.
    Figure 3. Segmented site with multiple networks

    Micro-segmented site with multiple networks

    Resources for OT Discovery System

    The requirements in this section are a generalization. Consider factors such as segmentation level, communication pathways, network traffic, redundancy, and environmental conditions. Also account for physical constraints when determining network requirements. The following tables provide resource estimates for each OT Discovery component. Review your system requirements beyond these minimums.

    Table 1. Discovery Console for OT System requirements
    Component Minimum System Requirements
    Discovery Console for OT
    • 16 GB RAM
    • 100 GB Hard drive
    • 2 CPUs
    For additional requirements for the Console, see Requirements for Discovery Console for OT installation and Install the Discovery Console for OT.
    Table 2. Discovery Sensor for OT System requirements
    Component Minimum System Requirements
    Discovery Sensor for OT
    • 2 GB RAM*
    • 100 GB Hard drive
    • 2 CPUs
    • 2 virtual NIC cards
    *8 GB of RAM is recommend for all queries.

    For additional requirements for the Sensor, see .

    Collector minimum system requirements

    The OT Discovery Collector can be installed and run on either a Windows OS or a Linux OS.

    Component Operating System Minimum System Requirements
    Windows

    The OT Discovery Collector installation is compatible with Windows 10 or Windows 11 systems.

    The required Windows (10 or 11) environment for the OT Discovery Collector is x86_64. ARM or Apple Silicon devices are not supported.

    See Install the OT Discovery Collector on a Windows system.
    Linux See Install OT Discovery Collector on a Linux system for specific information.