--- sourceDocument: Australia Operational Technology Management sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/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 for ServiceNow Operational Technology Discovery The ServiceNow Operational Technology (OT) Discovery platform provides a safe, scalable, and integrated solution to discover, identify, and inventory devices in industrial OT environments. It addresses the challenge of tracking numerous connected devices such as programmable logic controllers, remote terminal units, and human-machine interfaces by actively querying these devices using their native industrial protocols. This approach ensures minimal disruption to sensitive equipment while delivering a comprehensive, up-to-date inventory integrated into ServiceNow's IT service management platform. Show full answer Show less ## Key Features * **Active Discovery:** The system initiates direct queries to devices using native protocols (e.g., Modbus, EtherNet/IP, DNP3), mimicking normal engineering communications for safe interaction with operational networks. This enables detection of silent or dormant assets and retrieves detailed device information like firmware versions and serial numbers. * **Core Components:** * **Discovery Console for OT:** Central interface for configuring discovery queries, defining network zones and sites, selecting protocols and devices, and viewing discovery results. It typically resides in a secure IT/OT DMZ or management zone and does not perform discovery directly. * **Discovery Sensor for OT:** Software component deployed on virtual or physical machines that executes active discovery queries within accessible network zones and builds the device inventory. * **OT Discovery Collector:** Lightweight application deployed within segmented or restricted network zones to extend the Sensor's reach, ensuring full coverage of complex OT networks. * **Flexible Deployment:** Multiple Consoles, Sensors, and Collectors can be deployed based on network topology, with placement tailored to site segmentation and operational needs. * **Query Customization:** Users can configure protocol parameters, device brands, network ports, asset ranges, and query types (including advanced options like OPC-UA for photographic data) to precisely target discovery efforts. * **Integrated Inventory Management:** Discovered device data is uploaded to the ServiceNow instance, where it is mapped to configuration items in the CMDB, enabling tailored, industry-specific asset management. ## How It Works * **Deployment:** Consoles, Sensors, and Collectors are strategically deployed in the network to reflect the OT environment and ensure comprehensive coverage. * **Query Execution:** Discovery queries created in the Console are executed by Sensors and Collectors within their respective network zones, enabling simultaneous multi-zone discovery. * **Data Collection:** Responses from devices include detailed attributes such as device type, vendor, model, firmware, network address, and optionally photographic data. * **Integration:** Collected data is consolidated and uploaded to ServiceNow, providing a unified, accurate, and current OT device inventory accessible through a single interface. ## Benefits for ServiceNow Customers * **Safe and Non-Disruptive:** Active discovery uses native protocols indistinguishable from normal device communications, protecting sensitive industrial processes. * **Comprehensive Visibility:** Detects all devices, including dormant and silent assets, ensuring complete situational awareness of your OT environment. * **Scalable Architecture:** Supports deployments from single sites to large enterprises with multiple segmented zones, adapting to your network's complexity. * **Streamlined Operations:** Eliminates manual asset surveys or spreadsheets by automating discovery and integrating results directly into the ServiceNow CMDB. * **Customizable and Flexible:** Tailor discovery parameters and inventory mappings to fit your unique industrial environment and operational needs. 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://servicenow-prod.fluidtopics.net/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://servicenow-prod.fluidtopics.net/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.