octoplant ServiceNow Integration: Putting OT Device Content into the CMDB

Most questions about an octoplant ServiceNow integration come down to one: can the device content octoplant collects (program versions, firmware, backup status) land in ServiceNow’s CMDB, where IT, security and governance already work? As of October 2026 the short answer is that AMDT ships an export path aimed at ServiceNow, but we found no certified integration, so the mapping is something a site designs and owns. This page sets out ServiceNow’s OT strategy, what octoplant data adds to it, and a data flow design that holds up.

It sits under OTSSM and Integrations, which explains AMDT’s OT Service and Security Management model and where each tool fits.

Why ServiceNow is the ITSM platform that matters for OT

Among ITSM vendors, ServiceNow is the one with a developed OT strategy. We found no comparable OT products from BMC, Ivanti or Atlassian.

• Operational Technology Management (OTM) extends the CMDB with OT asset classes and production-process context, plus OT asset management and OT incidents.
• OT Vulnerability Response prioritises vulnerabilities by the criticality of the process a device controls (ServiceNow documentation).
• Armis. ServiceNow completed its $7,750,000,000 acquisition of Armis on 20 April 2026, giving it network-based asset discovery across IT, OT and IoT (ServiceNow).
• Siemens. Since October 2024, output from Siemens SINEC Security Guard and Industrial Copilot can flow into ServiceNow workflows (ARC Advisory Group).

What that stack still lacks is device-content truth. Discovery tells ServiceNow a controller exists, roughly what it is and what it talks to. It does not tell it which program version is running, whether that matches the approved version, or whether a restorable backup exists. That is exactly what octoplant holds.

What octoplant can send to ServiceNow today

Two AMDT features are relevant, both covered in more depth on the Export API page:

1. The octovision Export API, introduced in Spring Release 107 on 7 April 2026, to “transfer production data to ITSM platforms such as ServiceNow and other enterprise systems” (AMDT).
2. octovision’s exports and open API: CSV and JSON exports, and an API to “connect with your SIEM, CMDB, ticketing, or analytics tools” (octoplant.com).

octovision’s own inventory is built bottom-up from octoplant’s project and configuration data: vendor, type, firmware and software, components, jobs and CVEs, plus backup and job visibility. The octovision asset inventory page covers how that inventory is assembled. The CMDB-relevant point is that these fields come from the device’s own project data, not from a network fingerprint.

What we could not confirm publicly: the exact field list, the API’s authentication method, and whether the export is pull, push or both. The documentation sits behind the myAMDT login.

octoplant ServiceNow fields: which come from where

The table below is a design proposal, not AMDT’s schema. It assigns each OT configuration item field to the source we would trust most.

CMDB field (OT configuration item)	Best source	Why
Name, site, line, cell	ServiceNow OTM (process context)	The plant hierarchy is a governance decision, not a device fact
IP and MAC address, communication peers	Network discovery (Armis or another platform)	Seen on the wire; octoplant does not focus on traffic
Vendor, model, hardware components	octovision (from project data)	Read from the configuration, including modules a scan may miss
Firmware and software version	octovision	Exact versions from project data rather than inferred fingerprints
Program or project version, last change	octoplant	Version history with who and when
Last backup date and job status	octoplant / octovision backup visibility	Proves a restore point exists
Running versus approved compare result	octoplant change detection	The integrity signal no other tool provides
CVE matches	octovision, reconciled with OT Vulnerability Response	Firmware-exact matching; ServiceNow adds process criticality
Lifecycle and obsolescence status	octovision lifecycle data	Feeds capital planning
Criticality	ServiceNow OTM, or octovision criticality classification (Summer 2026)	Decide which one wins before go-live
Owner, support group	ServiceNow	Organisational data

Designing an octoplant ServiceNow data flow

A design we would start from:

1. Fix the scope. Pick one site and one asset class (for example, the line PLCs) before touching every device.
2. Agree the identity key. Decide how an octoplant component maps to a ServiceNow configuration item: asset tag, serial number, or a site-line-device naming convention. This is the step that fails quietly, so test it on real data first.
3. Decide field ownership. Use the table above. Each field gets exactly one authoritative source, so discovery and octovision do not overwrite each other on every sync.
4. Prefer a scheduled, read-only collection through a defined conduit. A service account with read-only rights collects from the export on a schedule, through the plant’s zone and conduit rules. Confirm with AMDT how the API is called before fixing the direction. The Export API page covers the zone considerations.
5. Start with read-only enrichment. Firmware, backup status and compare result on each OT configuration item, before any automated ticket creation.
6. Then add events. An unapproved change detected by octoplant raises an incident or a change review task; a new CVE match raises a vulnerability item that OT Vulnerability Response ranks by process criticality.
7. Close the loop by reference. Record the ServiceNow change number in the octoplant check-in comment, and attach the compare result to the change record.

A plant scenario (illustrative). A pharmaceutical site’s change board approves a firmware update on a filling-line controller. The ServiceNow change record carries the number; the engineer checks out the project in octoplant, makes the change and checks it in with that number in the comment. The next scheduled compare confirms running matches approved, and the CMDB item shows the new firmware and a fresh backup. The auditor reads one record, not three systems.

How to tell the integration is working. Three numbers, reviewed monthly, show whether the data is trusted or quietly decaying:

Measure	What a healthy value looks like	What a bad trend means
OT configuration items with a backup date newer than the agreed interval	Close to every in-scope item	Jobs failing, or devices added to the CMDB but never to octoplant
Duplicate or unmatched OT configuration items	Falling after go-live, then near zero	The identity key from step 2 is not holding
Items where running does not match approved for more than a week	A short list, each with an owner	Change records and device reality are drifting apart

Where it gets hard

• No certified connector. Without one, every ServiceNow or octoplant upgrade is a regression test for your integration. Budget for ownership, not just the build.
• Identity matching. octoplant names devices the way engineers named them; the CMDB names them the way IT did. Mismatches create duplicate configuration items that erode trust in the CMDB.
• Two criticality models. octovision’s Summer Release 2026 added criticality classification (octoplant.com), and ServiceNow OTM has its own. Running both without a rule produces two answers.
• Alert volume. Feeding every detected change into the incident queue will swamp the service desk during a commissioning week. Filter by approval status and asset criticality.
• Organisational ownership. The service desk owns ServiceNow, controls owns octoplant, and neither owns the mapping. Name an owner before go-live; our IT/OT integration work usually starts there.

For the network discovery side of the same CMDB, including Armis, see octoplant and OT security platforms. Back to the AMDT hub.