OTSSM: AMDT's OT Service and Security Management, and Where octoplant Fits in an IT/OT Stack

OTSSM, short for OT Service and Security Management, is AMDT’s name for bringing the discipline of IT service management to the plant floor. AMDT frames it in four disciplines (OT asset and configuration management, OT change management, OT incident management and OT problem management), and its OTSSM page opens on the claim that ITSM brought order to IT and that AMDT is now bringing it to OT (AMDT, OTSSM). This page explains what the model means, how it maps onto the ITIL practices an IT department already runs, where octoplant and octovision sit next to a CMDB, a SIEM and a network security platform, and what is not yet integrated as of October 2026.

The reason it matters to a plant is organisational before it is technical. IT already has a system of record for assets, changes and incidents. OT usually has spreadsheets, laptops and memory. When the two meet (an audit, a ransomware event, a merger) the gap shows up as hours of downtime and findings nobody can close.

What OTSSM is, and where it came from

ITSM, and the ITIL framework behind most implementations, gave IT departments a shared answer to four questions: what do we have, what changed, what broke, and why does it keep breaking. Those answers live in a configuration management database (CMDB) and a ticketing workflow, and every team works from the same records.

AMDT’s OTSSM page poses the same four questions in plant terms:

• OT Asset and Configuration Management: what do we have, where is it, how is it configured and what state is it in?
• OT Change Management: what is being changed, who is changing it, and can it be put into production safely?
• OT Incident Management: what happened, what was changed, and how do we restore production safely?
• OT Problem Management: why does this keep happening, and what do we have to change to prevent it?

The same page lists what makes OT different: heterogeneous devices, asset lifecycles measured in decades, limited maintenance windows, third-party service providers and environments where availability is critical. That list is accurate, and it is why copying an IT change process onto a packaging line rarely survives the first night shift.

OTSSM is a vendor framing, not a standard. It does not appear in ITIL, IEC 62443 or NIST guidance. Read it as AMDT’s description of the problem octoplant and octovision are built to address, and judge the products on what they actually do inside each discipline.

OTSSM mapped to ITIL practice and OT reality

The mapping below is our own reading. AMDT does not publish a formal ITIL crosswalk.

OTSSM discipline	Closest ITIL practice	What IT usually has	What OT usually has	What octoplant and octovision contribute
OT Asset and Configuration	Service configuration management, IT asset management	A CMDB fed by discovery agents	A spreadsheet, a network scan export, or nothing	Device content from backups: firmware, software and project versions, components, via the octovision asset inventory
OT Change	Change enablement	Change requests, approvals, change windows	A logbook, if anyone signs it	Check-out and check-in, approval workflows and change detection of running against approved
OT Incident	Incident management	Tickets, runbooks, restore from image	A phone call to whoever wrote the program	Known-good versions and disaster recovery per device
OT Problem	Problem management	Root cause records, known-error database	Tribal knowledge	Version history and audit trail showing what changed before each failure

Two things stand out in the table. First, the OT column is where most of the risk sits, and none of it is solved by buying software alone; someone has to own the process. Second, the right column is about device content, not about tickets. octoplant is not an ITSM tool. It produces the facts an ITSM process needs, and the question for an integration project is how those facts reach the system of record.

What this looks like on a plant floor (illustrative)

A night-shift technician changes a timer preset on a filler to clear a recurring jam. Under an OTSSM model, the change is caught by the next scheduled compare, flagged as unapproved, and shows up as a change record that the controls lead reviews in the morning. If the same jam recurs on three lines over a month, the version history becomes the input to a problem record. Without it, the change is invisible until the next download overwrites it, and the jam comes back with no explanation.

Where octoplant and octovision sit in an IT/OT tool stack

Most mid-size and large plants end up with five kinds of tool that touch OT assets. They overlap less than vendors suggest, because each one reads a different source of truth.

The five roles, in plain terms:

Tool	Source of truth	Answers	Typical owner
Engineering tools (TIA Portal, Studio 5000, CODESYS)	The project file on an engineer’s PC	What the program is meant to do	Controls engineering, integrators
octoplant	Uploads from the running devices, plus checked-in projects	What is running, what changed, how to put it back	Controls and maintenance
octovision	octoplant’s configuration data, plus CSV imports	Which assets carry which firmware, CVEs and lifecycle risk, across sites	OT security, engineering management
Network OT security platforms	Network traffic, passive or active	Which devices exist and talk, and what looks anomalous	OT security, often with the SOC
CMDB / ITSM and SIEM	Whatever is fed into them	The record of assets, changes and incidents; security event correlation	IT, the SOC, governance

AMDT itself draws the line between the middle rows. Its enterprise OT visibility page contrasts octovision, built from “project and configuration data already collected through Octoplant,” with network-centric discovery that relies on “active queries or passive observation of network traffic.” The same page says octovision makes data available “through structured exports and APIs” to SIEM, CMDB, ticketing, analytics and reporting platforms.

The integration mechanisms, in date order:

1. octoplant 105 (August 2025): a REST export API “for centralised access” to octoplant data (Novotek UK).
2. octoplant Spring Release 107 (April 2026): an octovision Export API to “transfer production data to ITSM platforms such as ServiceNow and other enterprise systems” (AMDT).
3. octovision exports: CSV and JSON, and an “open API to connect with your SIEM, CMDB, ticketing, or analytics tools” (octoplant.com).
4. octovision Summer Release 2026: import of external assets by CSV from discovery tools, maintenance systems or spreadsheets, with a managed versus unmanaged coverage view (octoplant.com).

The three pages below take each direction in turn. For the wider architecture question of how OT data should reach business systems, see our plant data overview.

Limits and open questions about OTSSM and integrations

• No certified integrations found publicly. As of October 2026 we found no ServiceNow Store application and no published joint integration with Claroty, Nozomi, Dragos or Armis. ServiceNow is named only as an Export API target. Integrations may exist privately; ask for references.
• API documentation is gated. Endpoint lists, authentication and data schemas sit behind the myAMDT login. You cannot size an integration from public material.
• Deployment statements disagree. octoplant.com describes octovision as “on-prem, cloud, or SaaS,” while other AMDT material treats cloud and SaaS as roadmap. Confirm what is generally available for your site before designing a data flow that assumes either.
• OTSSM is process, not product. Change, incident and problem management need named owners, approval rules and response playbooks. The tool records evidence; it does not run the process.
• Mapping is your cost. Every export into a CMDB needs field mapping, identity matching (which octoplant component is which configuration item) and a plan for when either side upgrades.
• Direction of flow is one way, as far as public material shows. We found nothing describing a change ticket in ServiceNow driving an approval inside octoplant, which is what a closed-loop change process would need.

How to evaluate it

Questions we would put to AMDT or a partner before committing an integration budget:

• Which data objects does each API expose (components, versions, jobs, compare results, CVEs, lifecycle status), and in which format?
• How does the API authenticate, and can access be scoped to read-only and to specific sites?
• Is there a reference integration for ServiceNow, and who maintains it across releases?
• Can octovision import discovery exports from our specific security platform, and how are matches between imported and managed assets decided?
• Can an approval or change number from our ITSM tool be recorded against an octoplant check-in?
• What breaks on an octoplant upgrade, and what is the API versioning policy?
• Which customers run this integration in production, and can we speak to one?

If the integration sits inside a broader effort to connect plant and enterprise systems, our IT/OT integration work starts from exactly these questions.

Deeper

• octoplant and ServiceNow: ServiceNow’s OT strategy, what octoplant data can add to a CMDB, and a design for the data flow.
• The octoplant Export API: the REST export API, the octovision Export API, the use cases and the security of API access across zones.
• octoplant and OT security platforms: how configuration data complements Claroty, Nozomi, Dragos and Armis, and the workflows where the combination pays off.

Back to the AMDT hub, or across to octovision and Compliance, where the same records serve as audit evidence.