Operational technology has long operated in isolation, with security defined by physical barriers. However, a recent cyberattack on a UK power plant, which exploited an unsecured programmable logic controller (PLC), highlights the urgent need for enhanced cybersecurity measures in critical infrastructure. The gap between what risk managers believe about industrial control systems and what adversaries exploit has never been clearer.
Myth 1: Air-Gapped Systems Can't Be Compromised
Reality: Air gaps are ineffective once a laptop is connected for maintenance, a USB drive is used for updates, or remote monitoring is enabled. The UK incident involved a PLC exposed to the internet. Attackers used AI-generated scripts to find exposed PLCs, logged in with default credentials, and disabled the device by altering its settings. This required only basic reconnaissance and a failure to follow foundational security practices.
If your team relies on network segmentation as a primary defense, audit every maintenance port, vendor access pathway, and monitoring system in your OT environment. Document exceptions, as most breaches start with an undocumented connection.
Myth 2: Securing the Main Control System Is Sufficient
Reality: Facilities like peaker plants have multiple control systems, each capable of shutting down the entire operation if compromised. For example, if a PLC connected to a water storage tank is taken offline, the plant shuts down even if the main turbine control system remains secure.
Your risk assessment should inventory every PLC, human-machine interface, SCADA component, and ancillary system. Map dependencies. A compromised environmental monitoring system might not pose a direct safety risk, but it can trigger automatic shutdowns that achieve an attacker's goal of disruption.
Myth 3: Default Credentials Are an Entry-Level Problem
Reality: Default credentials are a common attack vector in OT environments because changing them requires coordination across operations, engineering, and IT teams. Many PLCs come with hardcoded passwords that can't be changed without firmware updates. Others need downtime to reconfigure, which is challenging in a peaker plant designed for rapid deployment.
Establish a credential management protocol that treats OT devices with the same rigor as enterprise IT assets. If a device can't support password changes, isolate it behind authentication gateways or replace it during the next maintenance cycle. Document every exception in your Cybersecurity Risk Register with compensating controls and a remediation timeline.
Myth 4: Regulatory Compliance Equals Security
Reality: The UK's Department of Energy Security plans to update cybersecurity regulations following the incident, indicating that existing requirements were insufficient. Compliance frameworks set minimum baselines and don't account for the speed at which adversaries adapt or specific configuration weaknesses.
Your compliance program should inform your security posture, not define it. Map regulatory obligations from your Regulatory Inventory to specific controls, then layer on threat intelligence, vulnerability assessments, and lessons learned from incidents like the UK attack. When the UK's National Cyber Security Centre publishes its incident report, integrate those findings into your control design immediately. NCSC Cyber Security Guidance
Myth 5: Attribution Matters More Than Remediation
Reality: While reports suggest the attack may be linked to the Iranian Revolutionary Guard Corps hacking unit known as CyberAv3ngers, the focus should be on remediation. Whether the adversary is a nation-state actor or a criminal, the vulnerability remains: an exposed PLC with default credentials.
Focus your incident response on technical remediation. Document the attack path, identify similar exposures, and patch, harden, and monitor. Attribution can inform your threat intelligence program, but it shouldn't delay containment and recovery actions.
What to Do Instead
Start with an OT asset inventory that includes every device capable of affecting operations. Document network exposure, authentication mechanisms, and failure impact for each asset.
Implement a zero-trust approach to OT access. Require multi-factor authentication for remote connections, disable default accounts, and enable logging on every device that supports it. If a device can't support modern security controls, isolate it and monitor the network perimeter around it.
Engage with government resources like the NCSC and industry-specific Information Sharing and Analysis Centers. Treat post-incident reports as free penetration test findings. If an attack path worked against a UK power plant, assume it could work against your facility until proven otherwise through testing.
Schedule tabletop exercises simulating attacks on ancillary systems. Test whether your team can maintain operations if the environmental monitoring system goes offline. Confirm that your incident response structure includes OT-specific playbooks, not just IT protocols adapted for industrial environments.
The UK incident showed that a capable adversary who understands peaker plant operations can cause real damage. Close the gap between your OT security assumptions and what an attacker can exploit through continuous assessment, honest inventories, and a willingness to challenge outdated assumptions.





