Facebook
Google
GitHub
Linkedin
Here’s a situation that probably sounds familiar to many automation engineers.
Your PLC has been running reliably for 15 years.
No unexpected shutdowns. No major incidents. Production is stable.
Then a cybersecurity assessment comes along and suddenly everything is marked as a risk.
The security team recommends immediate remediation.
The automation engineer asks a perfectly reasonable question:
“Are you seriously suggesting we risk stopping production to fix something that isn’t broken?”
And this is where many OT cybersecurity assessments go wrong.
A technically valid security finding isn’t automatically an operationally practical recommendation.
In industrial environments, cybersecurity needs to account for more than vulnerabilities.
It needs to consider
1. Operational consequences: What actually happens if this system becomes unavailable?
2. System dependencies: Which PLCs, HMIs, engineering workstations, and industrial processes depend on it?
3. Safe assessment methods: Can we evaluate the risk without disrupting production?
4. Compensating controls: If patching isn’t feasible, can segmentation, access restrictions, or monitoring reduce the exposure?
5. Realistic remediation: Can the proposed improvements be implemented during planned maintenance windows?
After working with SCADA and industrial cybersecurity environments, I’ve become increasingly interested in bridging this gap between security assessments and engineering reality.
That thinking also motivated me to develop a practical OT/ICS Cybersecurity Audit & Risk Assessment Toolkit, aimed at helping teams structure their assessments and prioritize improvements.
But I’d rather start a discussion than simply share another checklist.
For the automation engineers here:
What’s the most unrealistic cybersecurity recommendation you’ve received during an OT security audit?
And for cybersecurity professionals
How do you balance security requirements with the operational constraints of legacy industrial systems?
I think both sides have a lot to learn from each other.
Your PLC has been running reliably for 15 years.
No unexpected shutdowns. No major incidents. Production is stable.
Then a cybersecurity assessment comes along and suddenly everything is marked as a risk.
- Unsupported operating systems.
- Legacy communication protocols.
- Missing security patches.
- Flat industrial networks.
- Shared engineering accounts.
The security team recommends immediate remediation.
The automation engineer asks a perfectly reasonable question:
“Are you seriously suggesting we risk stopping production to fix something that isn’t broken?”
And this is where many OT cybersecurity assessments go wrong.
A technically valid security finding isn’t automatically an operationally practical recommendation.
In industrial environments, cybersecurity needs to account for more than vulnerabilities.
It needs to consider
1. Operational consequences: What actually happens if this system becomes unavailable?
2. System dependencies: Which PLCs, HMIs, engineering workstations, and industrial processes depend on it?
3. Safe assessment methods: Can we evaluate the risk without disrupting production?
4. Compensating controls: If patching isn’t feasible, can segmentation, access restrictions, or monitoring reduce the exposure?
5. Realistic remediation: Can the proposed improvements be implemented during planned maintenance windows?
After working with SCADA and industrial cybersecurity environments, I’ve become increasingly interested in bridging this gap between security assessments and engineering reality.
That thinking also motivated me to develop a practical OT/ICS Cybersecurity Audit & Risk Assessment Toolkit, aimed at helping teams structure their assessments and prioritize improvements.
But I’d rather start a discussion than simply share another checklist.
For the automation engineers here:
What’s the most unrealistic cybersecurity recommendation you’ve received during an OT security audit?
And for cybersecurity professionals
How do you balance security requirements with the operational constraints of legacy industrial systems?
I think both sides have a lot to learn from each other.
