TL;DR
- Most OT pen test findings are legitimate. The recommendations that follow them are often not.
- CVSS scores do not account for the physical context, distribution, or scale of OT devices. A vulnerability on one device in a locked room is not the same as the same vulnerability on 400 devices spread across a county.
- Impractical recommendations do not get ignored entirely, but they do get deprioritised. The important ones get lost in the noise.
- Every finding should have a practical fix for today and a strategic recommendation for the next generation of equipment.
Why so many OT pen test findings miss the point
I have read a lot of OT pen test reports and I can tell you that the majority of them contain recommendations that will never be actioned. Not because the client is unwilling, but because the recommendations are somewhere between difficult and impossible to put in place.
The findings themselves are often correct. Modbus is unencrypted. That Human Machine Interface (HMI) is running XP. The Simple Network Management Protocol (SNMP) community string is “public.” Nobody is disputing the facts. The problem is what comes next: a recommendation that does not account for the constraints of the environment, and a risk rating that treats an OT network like a corporate LAN.
The pattern is often the same. Take a legitimate observation, rate the risk using the Common Vulnerability Scoring System (CVSS), and write a remediation that would require replacing half the plant. The plant engineer reads it, recognises that the tester has limited experience of OT environments, and pays less attention to the rest of the report. The findings that genuinely matter get lost alongside the ones that cannot be actioned. That is the real cost.
We need to do more to address this. If you are pen testing OT environments and producing these reports, you are making it harder for the rest of us to deliver findings that get taken seriously.
What follows is a set of examples that appear in OT pen test reports regularly. For each one, I will show you the impractical recommendation that gets written, explain why the risk is often different from what the scanner says, and then describe what a more useful recommendation looks like.
Plaintext protocol in use (Modbus/TCP)
The impractical recommendation: “Migrate to an encrypted, authenticated protocol.”
The finding is correct. Modbus/TCP has no authentication or encryption. It never has. The original Modbus protocol dates back to 1979. The TCP variant arrived in 1999 and inherited exactly none of the security features you might expect from something designed at the turn of the millennium. Everyone who works in OT knows this.
But the recommendation is to migrate the entire plant to an encrypted protocol. Think about what that actually means. Every Programmable Logic Controller (PLC), every Remote Terminal Unit (RTU), every HMI, and every piece of Supervisory Control and Data Acquisition (SCADA) software that speaks Modbus would need to support the replacement protocol. The vendors who wrote the SCADA software would need to build entirely new communications stacks. The PLC manufacturers would need to ship firmware that supports it. Every integration between every system on the plant would need to be re-engineered, tested, and validated. On a site commissioned fifteen years ago, with equipment from vendors who may not even exist any more, this is not a remediation. It is a complete rebuild.
The risk also depends enormously on context. On an air-gapped process network where physical access is required to reach the Modbus traffic, the practical risk of someone intercepting or injecting commands is vastly different from the same protocol running on a network with a route to the corporate LAN. The rating should reflect that. It often does not.
Strategic fix: Segment the network so that Modbus traffic is confined to dedicated process Virtual LANs (VLANs) with no unnecessary routes from higher-level networks. Monitor for anomalous Modbus writes. Restrict physical access to network infrastructure in the field. These are things you can do now, on the plant you have.
Long-term fix: When specifying the next control system upgrade or new plant, require protocol support for authentication in procurement specifications. Build the requirement into the project, not into a pen test remediation column.
SNMP using default community string
The impractical recommendation: “Change to a complex community string and migrate to SNMPv3.”
On managed switches the information disclosure often amounts to a hostname and some interface statistics. Even with the private community string, you often cannot reconfigure these devices in any meaningful way. The risk of someone reading the uptime of a switch on an isolated process network is not a high. It is barely worth mentioning. Yet Nessus plugin 10264 flags default SNMP community strings as a critical. A critical. On a managed switch on an air-gapped process network. Nobody stopped to think about what it actually means in this specific environment.
Strategic fix: Change the community strings where the devices support it. Many managed switches do allow this, and it is a low-effort change. Prioritise any devices where the write string is also default and where SNMP access could allow meaningful reconfiguration. For everything else, document it and move on.
Long-term fix: Include SNMPv3 support as a procurement requirement for new network infrastructure. Ensure new deployments use authentication and encryption by default.
Unsupported operating system
The impractical recommendation: “Upgrade to a supported operating system.”
That Windows XP Embedded HMI is running a process visualisation application from a vendor that went out of business in 2014. There is no update. There will never be an update. The hardware it runs on cannot support a newer operating system. Recommending “upgrade to a supported OS” is not a remediation. An HMI is not a Dell server in a data centre where you can swap in a new OS image over lunch. It is a purpose-built appliance running vendor-specific software that was qualified to run on that exact hardware and OS combination. Changing the OS means requalifying the application, if the vendor even supports it. If the vendor is gone, so is that option.
Is it a risk? Potentially, yes. But the risk depends entirely on what else can reach that machine. If it is sitting on a flat network with a route to the corporate LAN, that is a serious problem. If it is on an isolated segment behind a properly configured firewall with no inbound access, the risk is significantly lower.
Strategic fix: Isolate the machine. Ensure it sits on a dedicated network segment with firewall rules that restrict access to only what is operationally required. Remove any routes between the XP machine and higher-level networks. Add network monitoring on that segment so you know if something unexpected talks to it. The XP machine is not going anywhere. Work with that reality.
Long-term fix: When the HMI reaches end of operational life or the next major refit comes around, replace it with a system that runs a supported OS and has a vendor who still exists. Write the security requirements into the procurement specification now so they are ready when the time comes.
Screen lock after inactivity
The impractical recommendation: “Enable screen lock after 10 minutes of inactivity.”
This one is the clearest example I have of a security recommendation making things actively worse.
We pen tested a large cruise ship with HMIs distributed across the vessel, including in HVAC rooms and pool plant rooms that were routinely left unlocked. Anyone could walk in and interact with the automation system. Our recommendation was to reconfigure those HMIs so they could only control local plant. An HMI in an HVAC room should only control HVAC. Limit the blast radius.
Someone else recommended the IT approach: lock the screens after two minutes and require a username and password. The problem is that these were resistive membrane touchscreens. Typing credentials on a resistive touchscreen is painful. Engineers maintaining plant would step away, come back, and find the screen locked. Every time.
So the engineers found a workaround. Two accounts on the system, “C” and “E,” did not have the lockout applied. We are fairly sure these stood for “Chief” and “Emergency.” Both had full administrative rights across the entire automation system. Engineers started logging into these accounts to avoid the lockout, and those sessions were left open on HMIs in unlocked spaces across the vessel.
Before the “fix,” exposed HMIs were logged in as normal users with limited privileges. After the fix, they were logged in with unrestricted access to the entire vessel’s automation. The security recommendation made things measurably worse.
Strategic fix: Limit what each HMI can access based on its physical location. Lock the rooms, not the screens.
Long-term fix: For new builds, specify automation systems that support location-based access control natively. Consider proximity-based authentication using crew ID badges rather than password entry on unsuitable hardware.
Deploy EDR to all assets
The impractical recommendation: “Install Endpoint Detection and Response (EDR) software on all devices.”
On a PLC running proprietary firmware. It is not running Windows. It is not running Linux. You cannot install software on it. You certainly cannot install CrowdStrike on it. This recommendation tells the client that the tester does not know what a PLC is.
Strategic fix: You cannot put EDR on a PLC, but you can monitor the network around it. Deploy network-based anomaly detection that understands industrial protocols. Monitor for unexpected connections to PLCs, logic changes, and firmware uploads.
Long-term fix: Some modern PLCs support cryptographic authentication for programming access and firmware integrity checking. Specify these capabilities in procurement for new projects.
Disable unnecessary services
The impractical recommendation: “Disable all services not required for device operation.”
On an RTU where every service is baked into the firmware image. The manufacturer compiled the firmware, signed it, and shipped it. The client has no ability to modify what runs on the device.
Strategic fix: Control access to services from the network. Use firewall rules to restrict which hosts can reach each service. If the RTU exposes a web interface that nobody uses, block access to it at the network level.
Long-term fix: When replacing RTUs, require that new devices support disabling unused services or access control lists on the device itself.
SSH v1 is enabled
The impractical recommendation: “Disable SSH v1 and enable SSH v2.”
On 400 field devices deployed across outstations across several counties. Every one of them only supports SSH v1. The remediation is to buy 400 new devices, install them, commission them, and validate the process. That is a multi-year capital project. It is not a quick win.
And the risk, once again, depends on context. If those devices are on a well protected network with access restricted to two engineering workstations, the practical risk of the SSH v1 weakness being exploited is low. It is low however it is deployed. The finding is valid. The rating and the recommendation are not proportionate.
Strategic fix: Restrict SSH access to those devices to specific management workstations on a dedicated VLAN. If possible, use a bastion host so that the SSH v1 traffic stays within a tightly controlled segment. Monitor for any unexpected SSH connections.
Long-term fix: As field devices are replaced through natural lifecycle or capital projects, specify SSH v2 support as a minimum requirement. Plan the replacement as part of the broader asset refresh, not as a standalone security project.
Give the tester some grace
It is worth acknowledging that the tester does not always have full visibility of the environment. A week on site is not enough to understand every device, every constraint, and every operational workflow. Sometimes you cannot tell from the outside that an RTU’s services are baked into firmware and cannot be disabled. Sometimes you do not know that the vendor went bust a decade ago. Sometimes the documentation you are given is out of date or incomplete.
That is not an excuse for poor recommendations, but it is a reason to write them carefully. If you are not sure whether a service can be disabled, say so. Recommend it as a best practice, note that it depends on the device’s capabilities, and suggest the client confirm with the vendor or their engineering team. That is a reasonable and honest recommendation. What is not reasonable is writing “disable unnecessary services” as though it is a universal truth and leaving the client to work out that it is impossible.
The best approach is to make the best recommendation you can with the information you have, and be transparent about what you do not know. That builds trust. Pretending you understand the environment when you clearly do not is what destroys it.
Why this matters
This is not just an annoyance. It causes real problems.
When a report is full of recommendations that cannot be actioned, the whole thing loses credibility. The findings that genuinely matter get less attention than they deserve. The plant engineer who could fix a real problem has already formed the view that the testers do not fully understand their environment. They pay less attention to the rest of the report. The important recommendations get deprioritised alongside the impractical ones.
Over time, this trains asset owners to treat pen test reports as compliance exercises rather than genuine security improvements. They commission the test because a regulation or a standard requires it. They receive the report. They file it. Nothing changes. The next test produces the same findings. The cycle continues.
This is how you end up with organisations that have been pen tested annually for a decade and have not meaningfully improved their security posture. The reports are not driving change because the recommendations are not proportionate and the risk ratings do not reflect reality.
Raise the finding. Fix the recommendation.
I want to be clear about what I am not saying here. I am not saying these findings should be left out of reports. Modbus is unencrypted. XP is unsupported. SSH v1 is weak. These are facts and they should be documented. The client needs to understand the state of their environment, and a pen test report is the right place to do that.
The problem is not the finding. It is the recommendation that follows it, and the risk rating that accompanies it. Telling someone their plant uses Modbus is useful. Telling them to replace Modbus by next quarter and rating it as a critical is not.
A better way to structure recommendations
Every OT pen test finding should offer the client a range of options, because we do not always know what is possible in their environment. What we do know is that a single line saying “fix this” is not good enough.
The ideal fix. The long-term, proper solution. It may never happen. It might require a capital project, a plant redesign, or a vendor that does not exist yet. But it is worth documenting because it gives the client something to specify when they build the next plant or commission the next generation of equipment. We do not always know what budget or timeline the client has. Stating the ideal fix means they have it on record for when the opportunity arises.
The mid-term fix. Something achievable within a reasonable timeframe and budget. Network segmentation, firewall rules, access restrictions, monitoring. These are the recommendations that actually get implemented.
The quick win. A real sticking plaster. Something that can be done in days, at low cost, without disrupting operations. Changing a default password. Blocking a port on a firewall. Removing an unused network route. Often the most valuable recommendations in the entire report.
Compensating controls. Sometimes you cannot fix the issue at all. The device is what it is. In those cases, the recommendation should focus on what can be done around the issue to reduce the likelihood and impact of exploitation. Monitoring, segmentation, physical access controls, alerting.
A report that offers this range gives the client something to work with at every level. The CISO can plan the capital project. The OT engineer can implement the network changes. The site team can action the quick wins next week.
Conclusion
The findings are usually correct. Nobody is arguing with the facts. But a finding without a usable recommendation is just a description of the environment. And a risk rating that ignores the operational context is just a number from a scanner.
Every OT pen test finding should answer three questions. What is the actual risk, given the specific environment and compensating controls? What can the client do about it now, with the plant they have? And what should they specify for next time, so the problem does not get built into the next twenty years of operation?
If your pen test report reads like a Nessus scan with “OT” written on the cover page, you are not providing value. You are providing noise. And noise is worse than silence, because it teaches people to stop listening.
