Technical Due Diligence for Industrial Software M&A: What Generic Checklists Miss

A standard technical due diligence checklist was built for SaaS and enterprise software — source-code review, cloud cost modeling, API surface, engineering velocity. Apply that same checklist to a manufacturer whose core systems are an MES, a SCADA/HMI layer, and a fleet of PLCs on the shop floor, and it passes clean while missing most of what actually determines whether the acquired plant keeps running the day after close.

Independent technical audits ahead of a deal are frequently handled by a team outside the deal's own IT function, precisely because OT review needs different assumptions than IT review. YuSMP Group runs this kind of technical due diligence for industrial software assets, assessing the control-system and plant-software layer that a generalist audit typically treats as out of scope.

This guide covers why generic checklists miss OT risk, the five areas standard frameworks routinely skip, a practical sequence for running the audit, what a strong report should cover, and who should be doing the work.

Why Generic Tech Due Diligence Checklists Fail on the Factory Floor

Most tech due diligence frameworks follow a predictable arc: deal-thesis alignment, technology baseline, red-flag analysis, deal implications, and a post-close roadmap. That structure holds up fine for a SaaS acquisition. It starts to break down the moment the target's "technology" is a manufacturing plant, because the baseline assumptions underneath each phase were written for IT, not OT.

IT due diligence vs. OT due diligence — different assumptions

IT due diligence assumes source code is available, documentation roughly reflects reality, the stack is internet-connected enough to scan and inventory remotely, and vendors still support most of what's deployed. OT due diligence can't assume any of that. Plant networks are often deliberately air-gapped or segmented for safety reasons, PLC and HMI logic is frequently undocumented because it was written by someone who left the company a decade ago, and control hardware can run for 15-20 years past the point a generic IT audit would flag it as end-of-life. A checklist that doesn't account for those differences isn't incomplete — it's auditing the wrong system.

The Five Areas Standard Checklists Skip

These are the recurring gaps that show up when a generic tech DD process is applied to a manufacturing target. None of them are exotic — they're just outside the frame of reference a SaaS-oriented checklist was built around.

Air-gapped and segmented networks

A plant's OT network may be intentionally isolated from the corporate IT network, or segmented into multiple zones per the Purdue model. Standard vulnerability scanning and asset-discovery tools built for connected IT environments often can't reach these segments at all, which means a "clean scan" result may simply reflect a scanner that never saw the systems that matter most.

Undocumented PLC and HMI logic

Control logic running on PLCs and the HMI screens operators use every shift frequently has no up-to-date documentation — sometimes none at all. Buyers evaluating a plant's software maturity need to know whether that logic can be read, maintained, and modified by someone other than the one engineer who originally wrote it, because SCADA and HMI modernization projects routinely stall on exactly this gap.

Protocol and vendor lock-in (OPC UA, Modbus, proprietary SCADA)

Industrial systems talk to each other over a mix of modern and decades-old protocols — OPC UA, Modbus, and proprietary SCADA vendor protocols among them. A target's leverage after close depends heavily on whether its systems use open, well-supported protocols or a single vendor's closed stack. Reviewing OPC UA security practices at the target is a useful proxy for how modern — or how locked-in — the overall integration layer actually is.

Industrial cybersecurity posture (IEC 62443 maturity)

IEC 62443 is the standard most acquirers benchmark industrial cybersecurity maturity against. A target with no documented IEC 62443 alignment — no security zones, no conduit model, no patch-management process for control systems — carries materially more post-close risk than one that can show even a partial maturity assessment, regardless of how clean its IT-side security posture looks.

Legacy license and support-contract risk

SCADA and MES licenses are often tied to specific hardware, site counts, or vendor relationships that don't transfer cleanly in a change-of-control event. Some legacy automation vendors have been acquired, discontinued their product lines, or stopped selling new licenses entirely — which means a system that works perfectly today may have no path to expansion, support renewal, or even replacement parts.

A Practical Due Diligence Sequence for Industrial Software Assets

A sequence built for OT risk doesn't replace the standard tech DD phases — it adds the steps a generic checklist leaves out, run in parallel with the usual technology and red-flag review.

1. Baseline the OT/IT architecture. Map how the plant network is segmented, what protocols connect which systems, and where the boundary between IT and OT actually sits — not where a network diagram says it sits.
2. Interview the engineers who actually run the systems. Documentation gaps get filled by the people who operate the HMI and maintain the PLCs daily; a conversation with them surfaces undocumented logic and workaround processes faster than any scan.
3. Red-flag triage specific to manufacturing. Rank findings by production impact, not generic severity scores — an unpatched but air-gapped HMI may be lower risk than a licensing gap that blocks adding a second production line.
4. Check license transferability and vendor viability for every SCADA, MES, and automation platform in use, including whether the original vendor still exists in a form that can support the system post-close.
5. Benchmark cybersecurity posture against IEC 62443 rather than a generic IT security framework, since IT frameworks don't account for the availability and safety constraints unique to control systems.

Baseline the OT/IT architecture

Start with a current-state map of network zones, protocols in use, and data flows between the plant floor and business systems — built from direct observation, not the existing network diagram, which is frequently out of date.

Interview the engineers who actually run the systems

The people maintaining PLC logic and HMI screens know where the undocumented dependencies live. Structured interviews with this group consistently surface more real risk than a document review alone.

Red-flag triage specific to manufacturing

Score findings against production continuity and deal thesis, not a generic CVSS-style severity scale that wasn't designed for control-system constraints like uptime and safety interlocks.

What a Strong Industrial Tech DD Report Should Cover

A report that actually informs the deal — rather than just checking a box — should cover: the OT/IT architecture baseline and segmentation model; an inventory of MES, SCADA, and HMI platforms with version and support status; PLC and HMI logic documentation state; protocol dependencies and vendor lock-in exposure; IEC 62443 maturity against a defined target level; license transferability for every control-system platform; and a prioritized, production-impact-weighted red-flag list with estimated remediation cost and timeline for each item. Anything less leaves the buyer pricing the deal on an incomplete picture of what they're actually acquiring.

Who Should Run This — and When to Bring in Outside Help

Internal IT and corporate development teams can usually handle the standard technology and code-quality layer of tech DD on their own. The OT-specific layer — PLC logic review, SCADA license transferability, IEC 62443 benchmarking, protocol compatibility assessment — is a different skill set, one that most internal IT teams don't maintain day to day because it isn't part of their regular workload. Bringing in a technical partner that routinely works across MES, SCADA, and plant-floor systems for exactly this kind of pre-deal audit closes that gap without requiring the acquirer to build an OT security practice in-house just for one transaction. The build-vs-buy decisions manufacturers face with MES are a good illustration of how specialized this layer gets — the same holds true for auditing it before a deal.

Frequently Asked Questions

What is technical due diligence for industrial software?

It's the technical audit of the software, control systems, and infrastructure behind a manufacturing business before a sale or merger closes — covering not just application code and IT architecture, but the MES, SCADA/HMI layer, PLC logic, and OT network that actually run the plant.

How is OT due diligence different from standard software due diligence?

Standard software DD assumes a cloud-friendly stack with current documentation, available source code, and vendors that still support every component. OT due diligence has to account for air-gapped or segmented networks that resist conventional scanning, PLC and HMI logic that was never documented, proprietary protocols with limited interoperability, and control hardware that can be older than the engineers maintaining it.

How long does a technical audit of a plant's software take before a deal?

A focused industrial tech DD for a single-site deal commonly runs two to four weeks, covering architecture review, on-site or remote interviews with the engineers who run the systems, and a red-flag triage pass. Multi-site deals or plants with heavy legacy automation can extend that timeline, especially if PLC and HMI logic needs reverse-engineering because documentation doesn't exist.

Should the audit be run by an internal team or an outside partner?

Internal IT teams are a reasonable starting point for the software and infrastructure layer, but OT-specific review — PLC logic, SCADA licensing, IEC 62443 posture, protocol compatibility — usually needs engineers who work with industrial control systems day to day. Most acquirers bring in an outside technical partner for that OT layer rather than relying solely on a generalist IT audit team.