What Do Managed OT Services Include? A Plain List for Plant Operators

A managed OT service covers the day-to-day security and health of the control network in each plant you run, under one operating model. In practice that means continuous monitoring of the switches and firewalls on the plant floor, an engineer on call for incidents against a written response target, firmware and security updates coordinated with the equipment vendors around your production calendar, and reporting on a fixed cadence that your audit and insurance reviewers can read without assembly. Anything sold under that name that lacks one of those four parts is something else, usually a monitoring subscription or a block of consulting hours.

The reason the list matters is that "managed OT" is used loosely. Managed IT providers extend their endpoint tooling to the plant and call it managed OT. Monitoring vendors sell a sensor and a dashboard and call it managed OT. Neither is wrong to exist, but neither will take the call at two in the morning when a control network fault halts a line, and neither will negotiate a firmware compatibility matrix with the drive vendor before a maintenance window. The rest of this post goes through each part, what it should contain and what to ask for in a scoping call.

Continuous monitoring of the control network

The foundation is OT network monitoring: passive observation of a copy of plant traffic, from mirror ports or taps, by a device that injects nothing. It maintains the asset inventory as devices appear and disappear, learns which controllers talk to which HMIs over which protocols, and alarms on a new talker, a new protocol or a write command from an unexpected source. The appliance should be read-only, should understand the industrial protocols on your floor, and should not depend on one manufacturer's tooling, because your fleet does not run on one manufacturer.

What to ask: who sees the alarm first, and is it the same triage process at every plant? A console per site, with a different definition of critical at each, is the failure mode this service exists to remove.

An engineer on call, with a response target in the contract

The second part is a human with OT experience who answers when monitoring or the plant raises an incident. The distinction from IT support is not politeness. A reboot that is routine for an email server can stop a production line or create a safety event, so the person triaging has to understand control loops and shift handoffs before touching a device. Our earlier post on SIEM versus SOC in OT makes the same point from the other direction: a tool is not a function.

What to ask: what is the response target for a critical incident, is it written into the contract, and does every closed incident carry a root cause? Also ask what the coverage hours are per plant. Round-the-clock coverage is a cost decision each site should make on purpose.

Vendor-coordinated patching and vulnerability management

Third is the planned work. Firmware and security updates on switches, firewalls and the servers that host OT applications, scheduled around the production calendar and coordinated with the equipment vendors themselves. Vulnerability management in OT is a matching exercise between published advisories and the inventory, followed by a decision about which fixes are worth an outage and which risks are better handled by isolation until the next planned stop.

This part also carries the quiet engineering: switch hardening, configuration backups, a governed remote access path for vendors, and migrations off legacy fieldbus segments as the plant allows. None of it is visible when it works, which is why it needs to be itemized in the scope.

What to ask: who talks to the OEM about compatibility before a firmware change, your team or the provider's? If the answer is your team, you have bought monitoring and a phone number.

Reporting on a fixed cadence

The fourth part is the paper trail, and it is the part your board, your audit team and your insurance renewal actually see. A sound service produces the same artifacts on the same schedule at every plant: a weekly activity summary by severity and site, a monthly network performance report, a quarterly strategic assessment with trends and a forward roadmap, and a semi-annual refresh of the inventory and topology drawings. Reports should be retained long enough to show trends across renewals.

What to ask: can you see a redacted example of each report before signing? The format tells you whether the provider runs the service or only answers tickets.

What is usually not included

Managed OT support operates on a network that has been documented. It does not usually include the initial topology assessment that produces the inventory and drawings, which is a scoped project of its own, and it does not include capital projects such as building an industrial DMZ or re-segmenting a flat network, though it will plan and sequence them. It also does not replace the OEM's own support contract for the controllers. It governs when that support is used.

How to scope it

Count the plants, list the monitoring and network equipment already in place, and describe how incidents are handled today, including who gets the night call. That is enough for a provider to return a scoping proposal rather than a slide deck. The managed OT support page lists the deliverables and cadence we work to, so you can compare any proposal line by line.