When a UK power plant went offline for four days after a suspected state-sponsored intrusion, the government's response was telling: "At no point was there a risk to the wider energy system." While technically true, this reassurance allows dangerous misconceptions to persist.
You'll find similar thinking across organizations running operational technology: the belief that air gaps still exist, that compliance checkboxes equal security, and that attackers won't bother with small targets. Meanwhile, threat actors are using AI-generated scripts to exploit internet-exposed programmable logic controllers across water, manufacturing, and energy facilities. The FBI and four other federal agencies call it "an active threat," not a theoretical one.
These myths don't just create vulnerabilities. They shape how you allocate budget, design controls, and respond to incidents. Let's correct them.
Myth 1: "Our OT network is air-gapped, so we're protected"
Reality: Your PLCs are probably internet-exposed right now, and you might not know it.
Recent attacks on Siemens S7 Series PLCs occurred because these devices were accessible from the public internet. Not through sophisticated supply chain compromises or zero-days, but through basic network exposure.
Check your asset inventory against Shodan or similar scanning tools. You're looking for devices that shouldn't appear in public search results but do. This isn't a penetration test; it's basic reconnaissance that threat actors perform before you wake up Monday morning.
ISO/IEC 27001 Annex A 8.20 (Networks Security) and A 8.22 (Segregation of Networks) require you to control information flow between network domains. If you're claiming air-gap protection during a certification audit but haven't verified it with network scanning and segmentation testing, you're documenting a control that doesn't exist. Your lead auditor will find that gap, or worse, an attacker will.
SOC 2 CC6.6 similarly requires logical and physical access restrictions. "We don't think our OT is connected" won't satisfy an auditor reviewing your network architecture documentation.
Myth 2: "State-sponsored actors only target major infrastructure"
Reality: The UK incident involved a "small-scale energy generator," and suspected Iranian operatives hit more than 30 water facilities in Minnesota alone, with intrusions reported across at least 11 other US states.
Small doesn't mean safe. It often means easier.
Smaller facilities typically have fewer security resources, older equipment, and less mature incident response capabilities. They're also components in larger supply chains and regional grids. Disrupting several small targets can achieve strategic goals without triggering the defensive response that hitting a major utility would provoke.
Your risk assessment under ISO/IEC 27001 Clause 6.1.2 must account for threat actors whose objectives aren't financial. State-sponsored groups pursue geopolitical goals, test capabilities, and send messages. The likelihood ratings you'd assign to ransomware groups don't apply here.
For SOC 2, this affects how you describe risks in your system description. If you operate critical infrastructure of any size, your risk environment includes actors with nation-state resources and patience. Your compensating controls need to reflect that reality.
Myth 3: "Compliance frameworks cover OT security adequately"
Reality: ISO/IEC 27001 and SOC 2 provide control objectives, not OT-specific implementation guidance.
ISO/IEC 27001 Annex A 8.31 (Separation of Development, Test and Production Environments) matters differently when you can't just reboot a production PLC to test a patch. A 5.23 (Information Security for Use of Cloud Services) doesn't address the legacy protocols that your SCADA systems rely on.
You need to layer in OT-specific standards. IEC 62443 provides industrial automation and control systems security requirements that actually map to how PLCs, HMIs, and industrial networks operate. NIST SP 800-82 offers guidance for industrial control systems security that fills gaps your ISO/IEC 27001 ISMS won't catch.
During your next management review (ISO/IEC 27001 Clause 9.3), ask whether your documented controls account for OT-specific attack vectors: ladder logic manipulation, protocol abuse, engineering workstation compromise. If your controls documentation treats OT assets like IT endpoints, you're missing the threat model.
Myth 4: "We'll detect OT intrusions through our SIEM"
Reality: Traditional security monitoring doesn't see what matters in operational technology environments.
Your SIEM ingests logs from systems that generate logs in formats your log parser understands. Many PLCs don't log authentication attempts, configuration changes, or unauthorized commands in ways that integrate with enterprise security tools. Even when they do, the baseline of "normal" looks nothing like IT traffic patterns.
ISO/IEC 27001 A 8.16 (Monitoring Activities) requires you to detect anomalous behavior, but you need OT-aware monitoring to do that. Consider a scenario where an attacker modifies PLC logic to change operational parameters slightly, not enough to trigger immediate alarms, but enough to cause equipment degradation over weeks. Your SIEM won't catch that unless you're monitoring process values, not just network flows.
For SOC 2 CC7.2 (system monitoring), describe what you actually monitor in OT environments. If you're relying on network IDS alone, you're documenting a detective control with a significant blind spot. Asset-level monitoring, protocol analysis, and process behavior baselines belong in your control description.
Myth 5: "AI-assisted attacks are too sophisticated for us to defend against"
Reality: The AI-generated exploitation scripts targeting Siemens PLCs automate reconnaissance and exploit development, but they still rely on fundamental security gaps you can close.
Attackers use AI to scale attacks, not to bypass properly implemented controls. The scripts identify internet-exposed devices, probe for default credentials, and exploit known vulnerabilities faster than humans can. That's automation, not magic.
Your defense is equally straightforward: remove unnecessary internet exposure, eliminate default credentials, apply available patches (with proper OT change control), and implement network segmentation.
ISO/IEC 27001 A 5.23 (Information Security for Use of Cloud Services) and A 8.7 (Protection Against Malware) need interpretation for this threat. Your risk treatment plan should address automated reconnaissance as a specific attack vector, with controls that reduce your attack surface before the AI-assisted scanning finds you.
For SOC 2, this affects CC6.1 (logical and physical access controls) and CC7.1 (detection of threats). Document how you're reducing exposure to automated scanning and what detective controls you've implemented for OT-specific protocols.
What to Do Instead
Start with visibility. You can't protect what you don't know you have. Build an asset inventory of every PLC, HMI, RTU, and engineering workstation in your OT environment. Include firmware versions, network locations, and communication protocols.
Next, verify your network segmentation. Test whether your OT networks are actually isolated from IT networks and the internet. If you find unexpected connectivity, treat it as a major nonconformity against your documented controls.
Review your vendor advisories for the specific OT equipment you operate. Siemens publishes security updates for S7 PLCs; your other vendors do the same. Map these updates to your change control process (ISO/IEC 27001 A 8.32) and determine which patches you can apply within your operational constraints.
Update your incident response plan (ISO/IEC 27001 Clause 5.24, SOC 2 CC7.4) to include OT-specific scenarios. Who makes the decision to disconnect a PLC during an active intrusion? What's your communication protocol with operational staff who need that equipment running? These questions don't have IT-standard answers.
Finally, brief your executive leadership on OT risks in terms they'll understand: operational downtime, safety implications, regulatory consequences. When the UK Energy Minister briefed energy CEOs after the power plant incident, it wasn't a technical deep-dive. It was a conversation about organizational resilience. Have that conversation before an incident forces it.
The myths persist because they're comfortable. Correcting them requires work, budget, and sometimes uncomfortable conversations about risks you've been accepting without realizing it. But the alternative, learning these lessons during a four-day outage, costs more.
