OT Security Assessment: What It Covers and How It Differs From IT

Most MSPs price an OT security assessment like an internal network test with a strange address range. It isn't one. The methodology, the tooling, the rules of engagement and the definition of a bad outcome are all different. That's down to one question an IT assessment never has to ask: if this goes wrong, does product stop moving, or does somebody get hurt?

That question changes everything downstream.

Here's what the engagement is. A structured review of the systems that run your client's physical process: the PLCs, HMIs, historians, engineering workstations, drives and the network carrying traffic between them. MSP Pentesting delivers that work channel-only. Your brand on the proposal, your logo on the report, and nobody from our side ever turns up in your client's inbox.

Get the first one wrong and you'll learn it expensively, so here's the version that holds up in front of a controls engineer.

What an OT security assessment covers

Scope varies by plant, but a serious assessment covers six areas. If a proposal skips half of them, you're looking at an IT test wearing a hard hat.

• Asset inventory, built passively. Most plants can't tell you what's on the wire. The assessment builds that list from span port captures, configuration exports and a physical walkdown rather than an active sweep, because plenty of controllers fall over when you scan them.
• Network architecture and trust boundaries. Where OT ends and IT begins, what crosses that line, and whether anything enforces it. At minimum the assessment establishes what the boundary is supposed to be, so the segmentation work has a baseline to measure against.
• Remote access paths. Vendor VPNs, cellular modems bolted into a panel, remote support software on the HMI, the integrator tunnel nobody remembers approving. That's where the ugly findings live.
• Controller and protocol exposure. Modbus TCP, EtherNet/IP, DNP3, S7comm and PROFINET were designed for trusted networks. Most carry no authentication by default. The assessment documents what's reachable and from where.
• Host and lifecycle reality. The engineering workstation still on an unsupported Windows build because the vendor software won't run on anything newer. Frozen patch levels. Validation requirements that block updates. You're not fixing most of this. You're compensating around it.
• Operational process. Change control on the plant floor, who holds keys to the panel, how a contractor gets a laptop onto the network, and whether anyone would notice an unplanned PLC download.

That last one gets skipped constantly, and it produces some of the highest value findings, because the fix is a procedure rather than a capital project.

How it differs from an IT security assessment

The gap isn't tooling. It's priority order. IT security defends data. OT security defends a physical process that has weight, pressure, heat and people standing next to it.

Invert that one thing and the rest of the discipline inverts with it. Active scanning stops being routine and becomes the exception you have to justify in writing. Patching stops being a monthly cycle and becomes a line item in the next shutdown window, if it happens at all.

Refresh cycles stretch past anything an IT budget recognizes. NIST SP 800-82r3 puts OT component lifetime at 10 to 15 years and frequently longer. On the plants we walk, twenty year old gear still in production is routine.

Ownership flips too, and that one catches MSPs out. The IT director doesn't own these systems. Operations does, usually under a vendor contract saying nobody touches the machine without putting support at risk. You'll be negotiating scope with a plant manager, not a CIO.

Different buyer, different veto.

Then there's the worst realistic outcome, and that's the one to internalize. In IT, knocking a box offline to prove a finding is an inconvenience. In OT it can be a scrapped batch, a safety event, or a plant that takes nine hours to restart. Nothing in a properly run OT assessment happens without the operations lead knowing exactly when it happens and how to stop it.

Which is also why the deliverable reads differently. An IT report ranks by CVSS. An OT report ranks by what the affected asset does to the process.

ICS security assessment or OT security assessment

Buyers use both terms and they aren't synonyms. An ICS security assessment targets industrial control systems specifically: SCADA, DCS, PLCs, RTUs and safety instrumented systems, the equipment directly running the process. OT is the wider bucket. It covers all of that plus building management, power monitoring, physical access control, warehouse automation and the plant network tying them together.

Practically, scope the wider one and document the exclusions in writing. A client who asks for an ICS security assessment and gets one that ignores the building management system sitting on the same flat VLAN has been sold a narrower answer than the risk deserved.

Say which one you're doing in the proposal. Terminology arguments after delivery are a bad look.

Which standards to cite, and what each one is for

Four references carry weight in this space. Knowing what each one is for is what keeps you credible in front of a controls engineer.

• IEC 62443. The standard series for industrial automation and control system security. It gives you zones and conduits as design language and security levels as a target. IEC 62443-3-2 covers security risk assessment for system design, which is the part assessment work leans on hardest.
• NIST SP 800-82. The Guide to Operational Technology Security. Revision 3 broadened it from ICS to OT and expanded the guidance considerably. It's free, it's practical, and it maps to the NIST Cybersecurity Framework if the client's already working there.
• NIST CSF. Not OT specific, but useful as the reporting frame when the client's board already understands the functions. Good for the executive summary, weak as a technical methodology.
• CIS Controls. Solid for baseline hygiene on the IT side of the boundary. It wasn't written for process safety, so don't present it as an OT methodology.

One thing to be careful about in a proposal. An assessment tells a client where they stand against these standards. It doesn't make them compliant with any of them, and IEC 62443 certification is an entirely separate exercise. Promise the evidence, not the outcome.

What the findings look like, plant after plant

The pattern repeats hard enough that you can predict most of it before anyone shows up.

• One flat network from the front office to the machines. The VLAN diagram exists. The switch configuration doesn't match it.
• Vendor access nobody scoped. A standing tunnel with shared credentials, no MFA, no logging, and a support contract that says the vendor requires it.
• Domain joined engineering workstations. Same Active Directory as the office, which puts the phishing email that lands in accounts payable two hops from an HMI.
• Unmanaged switches nobody can log into. Bought by an integrator, installed in a panel, no configuration, no monitoring, and nobody holds the password.
• No baseline of normal. Nothing records what the plant network is supposed to look like, so nothing can flag when it changes.

Notice how few of these need a zero day.

They need someone to actually look.

What a good OT assessment report contains

OT reports fail differently from IT reports. The usual failure is a wall of technical findings with no operational context, which the operations lead reads once and then ignores forever.

• Findings ranked by process impact. A medium severity issue on the controller running the extruder outranks a high on a spare HMI in a storage cupboard. CVSS is an input, not the answer.
• Remediation split by outage requirement. Separate what gets fixed on a Tuesday from what needs the next scheduled shutdown. Operations budgets those two lists completely differently.
• Compensating controls where fixing is off the table. That unsupported workstation isn't getting replaced this year. Say what to wrap around it instead of writing "upgrade" and moving on.
• An asset list the client keeps. Half the value of a first assessment is that the client finally has an accurate inventory of their own plant.

If you already sell a risk assessment practice, the OT version slots in as a specialized scope rather than a new service line. Same conversation, different room, much older equipment.

How an MSP delivers this without an OT team

You're not going to hire a controls security specialist. The salary's high, the utilization is low, and the person leaves for an integrator inside two years.

So don't try.

Scope the engagement with the client, walk the floor with the operations lead, and hand the technical work to a partner that works only through the channel. The report comes back carrying your logo.

That last part matters more in OT than it does in IT. Plant people are suspicious of outsiders touching their network, and one bad interaction with an unfamiliar vendor ends the relationship. When the assessment arrives under the brand they already trust, the conversation stays yours.

That's the entire point of white-labeled pentesting. You keep the account and the margin. Somebody else carries the specialist payroll.

Frequently asked questions

What does an OT security assessment cost?

It scales with sites, cells and how much documentation already exists. A single plant with a cooperative controls engineer and a current network drawing is a fraction of the effort of a three site manufacturer where nobody's mapped anything in a decade. Always run a scope call first. Quoting an OT engagement off a headcount number is how people lose money on the first one.

Will the assessment take the plant down?

Not if it's run properly. The default posture is passive: traffic capture, configuration review, interviews and a physical walkdown. Anything active is agreed in advance, scheduled into a window, and run with the operations lead present and a stop signal defined. An assessor who won't work that way shouldn't be near the equipment.

Where does an assessment stop and a penetration test begin?

They're different jobs. The assessment maps the environment and measures it against a standard. A penetration test proves specific attack paths. Most clients need the assessment first, because there's no meaningful way to test a network nobody has documented.

How often should a client repeat it?

Annually is the common cadence, plus a repeat after any significant change: a new production line, a network refresh, a new integrator, or an acquisition that connected two plants together. OT changes slowly, then all at once during a capital project.

Does an ICS security assessment satisfy an auditor?

It gives an auditor evidence, not a pass. IEC 62443 and NIST SP 800-82 both expect documented risk assessment activity, and a good report demonstrates the work happened. Whether the auditor accepts the result depends on their scope and on what the client remediated. Nobody should promise more than that.

What to do with this

An OT security assessment answers what an IT assessment structurally can't: whether a compromise on the business network reaches something that moves, heats or holds pressure. Different methodology, inverted risk order, stricter rules of engagement.

Your manufacturing clients already carry this exposure. Somebody's going to assess it eventually. It may as well be the MSP whose name is already on their support contract.

If you've got a client with a plant floor and no real idea what's on it, get a pentest quote and scope the first one properly.