--- sourceDocument: Australia Operational Technology Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/operational-technology Release : - australia ft:locale : - en-US ft:publication_title : - Australia Operational Technology Management ft:clusterId : - optm bundleId : - optm workflow : - Technology --- # Architectural considerations # Architectural considerations {#ariaid-title1} Release version: Australia Updated May 8, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 7 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Architectural considerations ServiceNow Operational Technology (OT) Discovery provides a scalable, safe, and integrated solution to identify and inventory devices across industrial OT environments. It actively communicates with devices using their native industrial protocols (e.g., Modbus, DNP3, EtherNet/IP) to collect detailed asset data without disrupting sensitive operational processes. The architecture is designed to accommodate complex, segmented networks common in industrial settings, enabling comprehensive OT visibility integrated directly into the ServiceNow platform. Show full answer Show less ## Key Features * **Active Discovery Approach:** Sends native protocol queries indistinguishable from normal device traffic, ensuring network safety and minimizing operational impact. This approach detects silent and dormant devices and captures granular information like firmware versions and configurations. * **Three Core Components:** * **Discovery Console for OT:** Central interface for configuring discovery queries, defining network zones and sites, managing Sensors and Collectors, and viewing results. Typically deployed in a secure management or IT/OT DMZ zone. * **Discovery Sensor for OT:** Software deployed on virtual or physical machines that actively performs device discovery within accessible network zones using configured protocols and queries. * **OT Discovery Collector:** Lightweight application installed in restricted or segmented network zones to extend discovery reach where Sensors cannot directly access devices. * **Flexible Deployment:** Sensors and Collectors can be deployed on bare-metal or virtual machines depending on network architecture, allowing tailored coverage for complex OT environments. * **Comprehensive Query Configuration:** Users can specify protocols, brands, network ports, asset ranges, sites, and query types (including advanced types like OPC-UA for visual data). Queries can target specific Sensors and Collectors based on network placement. * **Integrated Workflow:** Discovery jobs are initiated from the Console, executed by Sensors and Collectors across network zones, and results are uploaded into ServiceNow CMDB, mapping devices to industry-standard configuration items. ## Key Outcomes * **Accurate and Up-to-Date Inventory:** Automated discovery creates a detailed, current inventory of OT assets visible through a single interface, eliminating manual tracking and spreadsheets. * **Safe for Operational Networks:** Queries mimic normal engineering traffic, ensuring discovery processes do not disrupt sensitive industrial operations. * **Scalable Architecture:** Supports environments ranging from single sites to large enterprises with multiple segmented zones, adapting to diverse OT network designs. * **Direct Integration with ServiceNow:** Discovered devices are mapped into the ServiceNow CMDB, allowing seamless correlation with IT service management and enhanced operational visibility. This document intends to describe the ServiceNow Operational Technology Discovery architecture and covers how discovery components find, identify, and inventory devices in an Operational Technology environment. ## Operational Technology Discovery software architecture {#architect-considerations__section_xlt_zx4_2jc} Today's industrial environments are made up of hundreds --- sometimes thousands --- of connected devices: programmable logic controllers, remote terminal units, human-machine interfaces, protection relays, and more. Tracking all of them --- what they are, where they sit in your network, and whether they behave as expected --- is a foundational challenge of operational technology. The following describes the software architecture underlying the ServiceNow Operational Technology Discovery platform. ## How Discovery works {#architect-considerations__section_inb_ty4_2jc} At its core, Operational Technology Discovery actively reaches out to devices on your network using the same protocol language those devices already speak. Each device receives a query in its native protocol and responds with identifying information. A Modbus device gets a Modbus query. An EtherNet/IP device gets an EtherNet/IP query. This approach avoids aggressive network scanning that can disrupt sensitive industrial equipment. The result is an updated inventory of your OT environment, visible through a single interface and integrated directly into your broader IT service management platform. Note: The user sets the protocol parameters for the query from the Discovery Console for OT. ## Active Discovery approach {#architect-considerations__section_pnl_pgp_2jc} Before exploring how the discovery components work in detail, it helps to understand the Operational Technology Discovery uses an active discovery approach. The Active discovery initiates communication directly with devices using their native industrial protocol language --- sending the same kinds of queries an engineering workstation or HMI would send to a PLC. These queries are indistinguishable from normal operations. Devices can't distinguish these queries from regular engineering traffic, making properly implemented active discovery safe for operational networks. Active discovery is easier to setup and start because it can require a Console and a single Sensor or Collector rather than a distributed set of SPAN ports and collection devices. The key advantage of active discovery is coverage. Because it reaches out to devices rather than waiting for them to communicate, it can detect silent and dormant assets that passive monitoring would never see. It also retrieves granular details --- firmware versions, serial numbers, configurations --- that may never appear in normal network traffic. ## The Discovery components {#architect-considerations__section_y5f_hz4_2jc} The architecture is built around three components that work together. It is important to understand each component's distinct role and responsibilities. The Discovery Console for OT is the interface you use to configure discovery, define the areas of your network you want to scan, and view the results. You can place more than one Console in your network. * The Console is your starting point. It is where you define your industrial sites, configure the network zones and sites you want to discover, and set up the queries that drive the process. After discovery is running, the Console is also where you view results --- seeing your OT environment take shape as devices are identified and cataloged. * In terms of network placement, the Console typically, but not necessarily, sits in an IT/OT DMZ or a dedicated secure management zone. It doesn't perform discovery itself, but it configures the Sensor and serves as the central point of visibility across your entire deployment. {#architect-considerations__ul_n1b_3bp_2jc} The Discovery Sensor for OT does the discovery work. Deployed as software on a virtual machine or physical server, the Sensor reaches out to devices in your network, identifies them, and builds your device inventory. It does this actively --- on a schedule you configure. You can place Sensors throughout your network. * The Sensor does the active discovery. Deployed as software on a virtual machine or bare metal system, it executes the queries configured in the Console. It builds your device inventory from the responses it receives. When the Sensor queries a device, it uses that device's native industrial protocol --- Modbus, DNP3, EtherNet/IP, and others. This keeps the interaction safe for the network. You can select the protocol for the query in the Console. * However, industrial environments are often deeply segmented by design --- and the Collector addresses this. {#architect-considerations__ul_ryh_lbp_2jc} The OT Discovery Collector extends the Sensor's reach into parts of your network that the Sensor can't access directly. In large or highly segmented industrial environments, a single Sensor may not have network visibility into every zone. Collectors are lightweight components deployed within those zones to bridge the gap. You can also use more than one of these components in your OT environment. * The Collector is a (small) application that can be installed on exiting systems (for example, HMIs) to extend discovery. * Combined with the Sensor, it offers flexible deployment options to assist with maximum coverage of the OT network. {#architect-considerations__ul_qtc_4bp_2jc} ## The Discovery workflow {#architect-considerations__section_szw_2bp_2jc} It is easier to understand how the three components work together when you follow a discovery job from start to finish. The following covers that process --- from building a query in the Console through to a fully populated device inventory in the ServiceNow instance. **Step 1: The network is built with Discovery in mind** Before any discovery runs, the Consoles, Sensors, and Collectors are deployed at positions in the network that reflects the user's OT environment. There are no fixed rules about how many OT components are needed to deploy or exactly where to place them. This depends on your OT network. Sensors and Collectors are deployed to cover the network. They can be deployed on bare-metal hardware or on a Virtual Machine, depending on what suits each part of the network. The Console, however, is recommended to run on a Virtual Machine. Discovery can return photographic data alongside standard device attributes. A Linux distribution should be installed on the same VM before the Console is installed. **Step 2: Build a query in the Console**. Discovery begins when you create a query in the Console, where you define exactly what you want to discover and how. Query parameters include: * Protocols: Which industrial protocols to use when communicating with devices, such as Modbus, DNP3, or EtherNet/IP. * Brands: Filtering discovery toward specific device manufacturers if needed. * Ports: Which network ports to include in the query. * Assets: Which devices or ranges of devices to target. * Sites: You can create or discover sites. * Query type: Simplified and advanced query types such as the OPC-UA type, which captures photographic and visual data from devices rather than relying solely on protocol-based communication. {#architect-considerations__ul_dkc_f2p_2jc} You can also select specific Sensors and Collectors the query should use. Because Sensors and Collectors are deployed at known positions in the network, you can pick specific components by name --- choosing the Sensor inside Line #1, for example, because you know that's where the devices you want to discover are located. Alternatively, you can let the query use the appropriate components based on where they are positioned in the network. **Step 3: The query runs through the selected components**. Once configured and launched, the query drives everything. Each Sensor and Collector executes the query within its part of the network, reaching out to devices using the protocols and parameters the user defined. A Sensor handles discovery in the zones it can directly access. A Collector does the same in the deeper or more restricted zones where it has been positioned. Because both Sensors and Collectors are independently deployed and selectable, a single query can span multiple zones simultaneously. The Sensor handles one part of the network and the Collector handles another, all driven by the same query configuration. **Step 4: Results upload to ServiceNow**. As devices respond, their details are collected and returned to the Console. These include device type, vendor, model, firmware version, network address, zone, Purdue level, and where applicable, photographic data. From the Console, the data is uploaded to the ServiceNow instance. Note: It should be noted that depending on your network structure, there are additional OT components used to reach the ServiceNow instance, if needed. For further information on OT Discovery connections, see the [OT Discovery deployment scenarios](https://www.servicenow.com/docs/lezgQYcTHgx5vj0Uwkn__w "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.") or the [Service Graph Connector for ServiceNow OT Discovery Guided Setup](https://www.servicenow.com/docs/Fpscnw17XDEIP3gL3Pw0IA "Use the Guided Setup for the Service Graph Connector for ServiceNow OT Discovery to lead you through the installation, connection, configuration, and integration steps for the OT Discovery environment."). Within the ServiceNow instance, discovered devices are mapped to configuration items predefined in the CMDB. These configuration items are based on industry and operational device types, reflecting the OT world your team works in every day. They can be edited and adjusted to fit the data retrieved, giving your team flexibility to tailor the inventory to your environment. The result is an accurate, up-to-date inventory of your OT environment --- built through the discovery components your company has positioned in the network. It is visible through a single interface and integrated directly to ServiceNow without manual surveys or spreadsheets. ## Wrapping up {#architect-considerations__section_whx_lqp_2jc} Operational Technology Discovery is built on the principle that visibility should not come at the cost of safety. By deploying the Console, Sensor, and Collector at deliberate positions within your network --- and querying devices in a way that is safe for operational environments --- the system adapts to your environment rather than requiring you to adapt your environment to it. Whether you're managing a single compact site or a large enterprise with dozens of segmented zones, the architecture scales accordingly. The result is a current, accurate inventory of your OT environment, fully integrated into ServiceNow and built without disrupting the operational processes your network supports.