Key takeaways

• 30+ facilities were breached the same way: internet-facing FortiGate VPN portals with no MFA, using accounts stored locally on the device rather than a central identity provider.
• Credential reuse across sites turned one compromised account into a fleet-wide problem; a leaked FortiGate config at one target was functionally a leaked password list.
• A destructive function inside one wiper shows signs of LLM generation — and got the logic backwards, making the wiper slower than a naive full overwrite.
• Canary-file detection stopped the wiper twice at the CHP plant, without needing a signature for the malware family, forcing the attacker to burn around 50 minutes recompiling and retrying.

On the morning of 29 December 2025, coordinated attacks hit at least 30 wind and solar farms across Poland, alongside a combined heat and power plant supplying heat to nearly half a million people. Temperatures were dropping, snowstorms were moving across the country, and New Year’s Eve was days away. The timing of it all certainly was not a mistake. CERT Polska has published a thorough technical account of what happened, and if you want the full attack chain, malware analysis, and indicators of compromise, that is the place to start. [1] This blog post will not retell the attack but rather highlight some important lessons: how straightforward the initial access actually was, an observation about how one of the malware samples was likely built, and detection engineering that worked.

Ease of Access

CERT Polska’s attribution points to an activity cluster tracked under several names by different organisations, most notably Static Tundra, with a documented history stretching back over a decade and a consistent focus on the energy sector. [1] This is not a smash-and-grab criminal operation but likely a state-backed Russian threat actor. It is patient, well-resourced, and has a track record of getting into industrial environments and staying there.

So how exactly did they breach the perimeter? At every one of the 30 renewable energy facilities, a FortiGate device sat at the network perimeter, doing double duty as VPN and firewall. The VPN portal was reachable from the internet, which is normal enough, plenty of legitimate remote access setups work this way. What was not normal is that authentication relied on accounts statically defined inside the device’s own configuration file, with no multi-factor authentication sitting in front of them.

“Statically defined” can sound abstract, so it’s worth being precise about what it means in practice. These are local user accounts, username and password, stored directly on the FortiGate itself rather than authenticated against a central identity provider. The attacker did not need to pivot through some other compromised system to get them. They needed valid credentials for one of those accounts, and the login page was sitting on the open internet waiting for them.

Where the credentials came from differs slightly by target, which is itself informative. CERT Polska notes that credential reuse across facilities was common industry practice at the renewable energy sites, meaning a single compromised account could plausibly unlock all 30. Some of the devices had also been vulnerable to remote code execution issues at various points in their history, which is one obvious route to harvesting credentials in the first place. [1] At the manufacturing company hit on the same day, the picture is more damning still: the FortiGate’s configuration had been stolen at some point in the past and posted publicly on a forum used by criminal communities. [1] Older FortiGate firmware has a history of storing local account secrets in a weakly protected format, so a leaked configuration file is functionally equivalent to a leaked password list. CVE-2022-40684, a well-documented authentication bypass affecting FortiOS, is the kind of vulnerability that produces exactly this scenario, though CERT Polska’s report does not confirm which specific CVE was involved at this target. [2]

Once inside, the attacker had admin-level privileges on the FortiGate, which they used to obtain or fabricate VPN accounts with access spanning all internal subnets, segmentation or no segmentation. From there, the rest of the network offered remarkably little resistance. Hitachi RTU560 controllers running the substations had a built-in account literally named “Default”. [1] Mikronika RTUs, built on Linux, accepted default SSH credentials straight to a root shell. Moxa NPort serial device servers had their web interfaces wide open with factory credentials still in place. None of this required any skill beyond knowing where to look, and a simple web search for default credentials.

Consider that this is a group capable enough to have been linked to power grid attacks and malware deployments against critical infrastructure for the better part of ten years. They got into 30 separate facilities, simultaneously, using a login page with no second factor and a password that, in some cases, was sitting in a forum post. Sophistication in this incident lived in the planning, the coordination across targets, and the choice of timing. No zero-days necessary.

The fix here is not overtly complex and should lie well within the skill bounds of any team tasked with protecting these types of assets. Centralised authentication through RADIUS or LDAP rather than accounts baked into each device, mandatory MFA on any internet-facing OT ingress point, and credentials scoped to least privilege rather than blanket subnet access. ISA/IEC 62443-3-3 covers most of this directly under its identification and authentication requirements. [3] It’s not groundbreaking advice.

LLM in the Loop

Buried in CERT Polska’s malware analysis section is a detail that, as far as I can tell, hasn’t shown up in a formally attributed nation-state incident report targeting OT environments before. The attack against the manufacturing company used a PowerShell-based wiper the report names LazyWiper, which overwrites files with pseudorandom byte sequences to render them unrecoverable. Inside it, a C# function (invoked from the PowerShell script) responsible for overwriting file contents stood out from the rest of the script: different coding style, inconsistent indentation, and comments that, in CERT Polska’s words, “would likely not be written by a human developer”. [1] Their conclusion is that the function was probably generated using an LLM.

There’s a slightly comic footnote to this: The function exists because the technique of overwriting selected byte ranges rather than the whole file is, in theory, faster than a full overwrite. Whoever or whatever wrote it got the logic backwards: the way the file operations were actually implemented made it significantly slower than just overwriting everything would have been. [1] So the AI-assisted component of a nation-state wiper attack appears to have made the wiper worse at its job, not better. It’s somewhat comforting to know that even the bad guys struggle with agentic coding.

CERT Polska is appropriately cautious here, and I’ll take my lead from them. This is inferred from the code characteristics and not something confirmed as fact. If true, this pattern is indicative of the broader trend of attackers leveraging LLMs. You no longer need a malware developer on staff, the bar to entry for creating malware has been significantly lowered. (Even if the LLM inverts the logic).

The Detection That Held

At the CHP plant, the same actor had been inside the network for months before the destructive phase. Reconnaissance activity going back to March 2025, credential theft via LSASS memory dumps, a full Active Directory database extraction in July, all quietly building toward something. [1] When the wiper, a native Windows binary CERT Polska calls DynoWiper, was finally distributed across the domain via a Group Policy Object on 29 December, it began executing on more than 100 machines.

Somewhat fortunately, it didn’t get to finish. The organisation’s EDR deployment used a canary file mechanism, essentially planted files that trigger an alert the moment their contents start changing, and the wiper’s overwrite activity tripped it. Execution was halted before the damage spread further. [1]

The attacker didn’t give up. They recompiled a modified version of DynoWiper within roughly 50 minutes and tried again. CERT Polska’s table of analysed samples shows two compile timestamps around 50 minutes apart on the same day, which is about as close as you get to watching an attacker’s reaction time in real time. [1] That attempt was blocked too.

There’s more here than “a defence worked”. First, it’s a clean demonstration that detecting wiper behaviour doesn’t require predicting the specific malware family or having a signature for it in advance. Canary files work because they detect the behaviour, indiscriminate overwriting, rather than the binary. Second, GPO-based distribution, while a convenient and quiet way to push malware across a domain, leaves a trail in event logs that’s detectable if anyone is looking for it, which CERT Polska’s forensic timeline confirms they were able to reconstruct after the fact in considerable detail. Third, the roughly-50-minute recompile-and-retry tells you something about operational tempo: a good detection control doesn’t just block one attempt, it forces the attacker to burn time and resources reacting in the moment, which is exactly the kind of friction a defender wants to introduce.

Lessons Learned

Default credentials in OT environments are not a theoretical finding from a penetration test report. They were the literal mechanism that let a state-sponsored group into 30 separate facilities at once. Credential reuse across sites turns a single compromise into a fleet-wide one, which is a particularly bad trade when the alternative, centralised identity management, is neither new nor exotic technology. And detection engineering, specifically behaviour-based controls like canary files that don’t depend on knowing what the potentially LLM generated malware looks like in advance, demonstrably worked against a capable, patient, and reactive adversary under live conditions.

The CERT Polska report has the full attack chain, the IoCs, the YARA rules, and the MITRE ATT&CK mappings for both enterprise and ICS environments, and it’s worth reading in full if any of this is relevant to your own environment. [1] If any of this overlaps with the kind of thing you’d rather see firsthand, my colleague Colin Cassidy is giving a talk called ACME Windpharm at hack::soho in London, walking through lessons learned from a real windfarm security assessment. Catch it in person or live on our YouTube channel.

References

[1] CERT Polska. Energy Sector Incident Report – 29 December. 2025. https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf

[2] Cybersecurity and Infrastructure Security Agency. CVE-2022-40684. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2022-40684

[3] ISA/IEC 62443-3-3. System Security Requirements and Security Levels. Research Triangle Park: ISA. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards

Key Takeaways:

• The UK Government published their Energy Sector Cyber Security Strategy on 28 May 2026, setting out a four-year roadmap to 2030
  
• Jointly authored by DESNZ, Ofgem, NCSC and NESO, the strategy signals an unprecedented level of coordinated regulatory intent
  
• Clean Power 2030 ambitions are expanding the attack surface at pace, introducing new vulnerabilities alongside new technologies
  
• Regulatory scope is widening well beyond current NIS-regulated operators, with Cyber Essentials proposed as a baseline for all Ofgem licensees
  
• Supply chain security, OT resilience, and board-level accountability sit at the heart of the strategy’s expectations
  
• Organisations that move ahead of compliance deadlines will be better positioned for both security resilience and commercial credibility

A Strategy for a Critical Moment

Energy infrastructure has always been a target. What has changed is the scale, the sophistication, and the geopolitical intent behind those who are seeking to compromise it.

Published on 28 May 2026, the UK Government’s Energy Sector Cyber Security Strategy^[1] arrives at a moment of acute tension. A national drive toward Clean Power 2030 is accelerating the transformation and digitalisation of the energy system faster than many organisations can embed the security controls needed to protect it. Adversaries have taken notice.

The NCSC has reported a stark increase in threats to Critical National Infrastructure. In January 2026, CERT Polska attributed a cyberattack on Polish renewable energy infrastructure directly to Russian actors, an incident that caused physical damage to industrial equipment alongside IT disruption.^{[4, 5]} A month earlier, in December 2025, threat actors targeted distributed energy resources in a separate Polish incident designed to destabilise grid operations.^[4] In 2024, the NCSC and international partners issued a joint advisory on China state-sponsored actors observed compromising US energy, transport, and water systems, assessed as pre-positioning for future disruptive or destructive attacks.^{[2, 3]}

The message for UK energy sector leaders is unambiguous. This threat is real, escalating, and targeting precisely the kinds of assets the sector is now deploying at pace.

What Does the Energy Sector Cyber Security Strategy Set Out?

Developed jointly by the Department for Energy Security and Net Zero (DESNZ), Ofgem, the National Cyber Security Centre (NCSC), and the National Energy System Operator (NESO), (collectively referred to as the ‘Quad partners’) the strategy is built around five strategic outcomes to be delivered between now and 2030.^[1]

• Understanding Threat, Vulnerability, and Risk.  Building a whole-system picture of the energy sector, including supply chain interdependencies, critical failure points, and areas of risk concentration.
  
• Prevention Through Enhanced Resilience.  Accelerating cyber maturity across operators, expanding regulatory scope beyond current NIS-regulated entities, and embedding security by design in new infrastructure.
  
• Preparedness, Response, and Recovery.  Developing detection capabilities, testing cross-sector response plans, and building access to advanced adversary simulation schemes.
  
• Monitoring, Regulation, and Enforcement.  Strengthening oversight through the forthcoming Cyber Security and Resilience Bill (CSRB), introduced to Parliament in November 2025,^[6] and leveraging Ofgem licensing powers more actively.
  
• Fostering Partnership, Culture, and Skills.  Addressing structural skills shortages, expanding security clearance access, and embedding a risk-driven security culture from the boardroom downward.

Two shifts stand out above others. The first is the explicit intention to expand regulatory reach, with the strategy proposing Cyber Essentials as a baseline requirement for all Ofgem licensees, not merely those currently in scope of the NIS regulations.^{[1, 7]} The second sees supply chain security elevated from a good-practice consideration to a formal, time-bound regulatory objective, with critical supplier designation expected by 2030.

Who is Affected by the Energy Sector Cyber Security Strategy?

Energy Operators and Utilities

For NIS-regulated Operators of Essential Services, the clock is already running. Accelerated maturity targets for the most critical systems are due by 2027 for downstream gas and electricity, and 2028 for oil and upstream gas.^[1] Critically, the Quad partners are explicit that operators should move ahead of ministerial deadlines wherever operationally feasible. Boards and executives are called out directly, with cyber risk expected to be governed with the same rigour as safety and physical resilience.

Smaller Operators and New Market Entrants

The strategy’s most commercially significant expansion is its reach toward organisations historically outside formal regulatory scope. Distributed energy resources, battery storage providers, demand flexibility aggregators, and new digital market participants all carry system-level risk. The proposal to extend Cyber Essentials requirements to all Ofgem licensees means no corner of the licensed energy market should expect to remain unaffected.^[1]

Supply Chain Vendors and Technology Providers

Preliminary supply chain security principles are due by end 2026. A framework for designating and directly regulating critical suppliers follows by 2030.^[1] Vendors and technology providers serving the energy sector need to begin assessing and evidencing their security posture now, well ahead of formal requirements.

What are the Key Challenges Organisations Will Face?

Translating the strategy’s objectives into operational reality will require organisations to navigate several persistent and interconnected challenges.

Legacy OT and ICS Infrastructure

Much of the sector’s OT predates modern cybersecurity practice. Integrating new digital systems with ageing industrial control environments creates complex interdependencies that are difficult to monitor, segment, or patch without operational risk.

The Cyber-Engineering Skills Gap

The UK faces a structural shortage of professionals combining deep cybersecurity knowledge with OT and engineering expertise.^[1] Without sustained investment in building this dual capability, regulatory ambitions will outpace the delivery capacity available to meet them.

Supply Chain Visibility

Many operators have limited transparency into the security posture of their Tier 2 and Tier 3 suppliers. Without a comprehensive view of supply chain interdependencies, systemic risk cannot be managed, only tolerated.

Expanding Attack Surface from Clean Energy Technologies

Wind, solar, battery storage, and smart grid assets each introduce new attack vectors, many built and operated by new market entrants with limited security maturity. The pace of Clean Power 2030 deployment risks creating security debt at scale.

IOActive’s own research in this area is instructive. Our Principal Consultant Colin Cassidy, presenting at BSides OT UK in April 2026,^[9] drew on direct wind farm security assessments to illustrate a recurring and concerning pattern. An over-reliance on security product solutions has left basic hygiene critically lacking, with systems discovered to have been installed insecurely from the outset and left unpatched for years. His research also challenges a common assumption in OT security circles, namely that cutting off power supply represents the ceiling of attacker ambition. In practice, the more technically sophisticated threat involves cyber-physical attacks capable of causing actual physical damage to turbine infrastructure. This is not a theoretical scenario. The 2019 GB power outage, in which wind farm behaviour during the incident complicated system restoration, demonstrated the real-world consequences of how micro-generation is modelled and controlled within energy management systems.^[8]

Board-Level Cyber Literacy

The strategy repeatedly calls for board-level ownership of cyber risk.^[1] Many boards still lack the literacy to interrogate it meaningfully, creating a governance gap between technical teams and strategic leadership at precisely the moment when that gap is most dangerous.

How IOActive Can Help?

IOActive’s work at the intersection of OT/ICS security, adversarial simulation, and critical infrastructure advisory positions us directly to support the energy sector in responding to this strategy. Testing is the thread that runs through everything we do, not compliance checkbox exercises, but technically credible, operationally grounded assessments designed to find what adversaries would find before they do.

OT/ICS Full Stack Security Assessments

Our specialist teams conduct rigorous assessments of OT environments, from generation and transmission through to distribution, renewables, and emerging clean energy assets. We examine the full stack, covering field devices, communication protocols, engineering workstations, historian systems, and the IT/OT interfaces where risk is often most concentrated. Our wind farm assessment experience, including the research presented by Colin Cassidy at BSides OT UK,^[9] gives us direct, practitioner-level insight into the vulnerabilities specific to renewable energy infrastructure. Findings are delivered as risk-prioritised remediation roadmaps grounded in operational reality, not generic frameworks.

Red Team and Purple Team Services

The strategy’s call for advanced capability testing, aligned to schemes such as the NCSC’s Cyber Adversary Simulation (CyAS) scheme,^[1] reflects a recognition that compliance assessments alone cannot validate resilience against determined, capable threat actors. IOActive’s Red Team operations emulate the specific tactics and techniques of the nation-state actors most likely to target UK energy infrastructure, including the IT-to-OT lateral movement paths and cyber-physical attack chains that standard penetration testing does not reach. Our Purple Team engagements bring offensive findings directly into structured collaboration with defensive teams, accelerating the translation of assessment outcomes into measurable improvements in detection and response capability.

Supply Chain Integrity

With supply chain security set to become a formally regulated requirement,^[1] IOActive’s Supply Chain Integrity service helps both operators and their vendors identify and address risks before they become compliance findings or, more consequentially, incident vectors. We assess the security posture of technology providers, software vendors, and critical third parties, reviewing firmware, embedded systems, and procurement processes for vulnerabilities that organisations may be unknowingly inheriting. For operators preparing for the Quad partners’ forthcoming supply chain security principles, this work provides the evidential baseline that regulators will increasingly expect to see.

Threat Modelling and Advisory

Our threat modelling and risk assessment engagements provide the analytical foundation the strategy’s first objective demands. Working from a structured, evidence-based understanding of the threat landscape, we translate findings into prioritised investment decisions that boards and executive teams can act on with confidence. We work with CISOs, risk directors, and senior leadership to align security investment with the specific risk profile of their assets, sector role, and regulatory obligations.

Preparedness and Resilience Testing

Preparedness is a capability, and like any capability, it must be tested to be trusted. IOActive designs and facilitates structured tabletop exercises and crisis simulation scenarios that stress-test the cross-cutting response plans the strategy mandates,^[1] without the risk of a live incident. We help organisations identify gaps in their detection, escalation, and recovery processes and develop the internal muscle memory needed when a real incident demands fast, coordinated action. This work directly supports the board-level governance expectations embedded throughout the strategy.

What are the Recommended Next Steps for Energy Sector Cyber Security Strategy Application?

The strategy is clear that urgency is required.^[1] Waiting for regulatory deadlines is not a viable risk management posture. We recommend the following immediate actions.

1. Assess current maturity against the NIS Cyber Assessment Framework^[7] and identify gaps relative to the strategy’s resilience expectations.^[1]
   
2. Map your supply chain to understand critical dependencies and begin engaging key suppliers on their security posture.
   
3. Prioritise OT visibility by deploying monitoring capabilities across industrial control environments before scope expansion regulations take effect.
   
4. Engage your board with a structured cyber risk briefing that translates technical findings into business, reputational, and regulatory risk terms.
   
5. Test your defences through a red team or adversary simulation engagement that probes your most critical operational systems against real-world threat actor TTPs.
   
6. Evaluate Cyber Essentials readiness across your asset and licensee portfolio, ahead of proposed baseline requirements.^[1]

Conclusion

The Energy Sector Cyber Security Strategy is the clearest signal the UK government has sent to the energy industry in years. It reflects both the escalating reality of the threat and the recognition that the clean energy transition cannot succeed if it creates vulnerabilities faster than the industry can address them.

The four-year roadmap to 2030 provides structure, but the expectation embedded throughout the strategy is that the strongest organisations will not wait for deadlines. They will assess their position now, invest in the capabilities that matter, and treat cyber resilience as the strategic enabler it has become.

The clean energy transition will only deliver on its promise if it is secured from the outset. The window to act ahead of the regulatory curve, and ahead of the next significant incident, remains open, but is narrowing.

If you would like to discuss how your organisation measures up against the strategy’s objectives, or how IOActive can support your cyber resilience programme, we welcome the conversation.

References

[1]  Department for Energy Security and Net Zero, Ofgem, National Cyber Security Centre, National Energy System Operator. Energy Sector Cyber Security Strategy. 28 May 2026. https://www.gov.uk/government/publications/energy-sector-cyber-security-strategy/energy-sector-cyber-security-strategy

[2]  National Cyber Security Centre. NCSC and Partners Issue Warning About State-Sponsored Cyber Attackers Hiding on Critical Infrastructure Networks. 7 February 2024. https://www.ncsc.gov.uk/news/ncsc-and-partners-issue-warning-about-state-sponsored-cyber-attackers-hiding-on-critical-infrastructure-networks

[3]  CISA, NSA, FBI and international partners incl. NCSC. PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (Advisory AA24-038A). 7 February 2024. https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a

[4]  CERT Polska. Energy Sector Incident Report: Coordinated Cyberattacks on Polish Renewable Energy Infrastructure, 29 December 2025. Published 30 January 2026. Reported in: The Hacker News. https://thehackernews.com/2026/01/poland-attributes-december-cyber.html

[5]  Notes from Poland. Poland Suffers Major Cyberattack on Power Grid, Says Russia Likely Responsible. 14 January 2026. https://notesfrompoland.com/2026/01/14/poland-suffers-major-cyberattack-on-power-grid-says-russia-likely-responsible/

[6]  UK Parliament. Cyber Security and Resilience (Network and Information Systems) Bill 2024-26. Introduced to the House of Commons 12 November 2025. https://bills.parliament.uk/bills/4035

[7]  UK Government. The Network and Information Systems (NIS) Regulations 2018 (SI 2018/506). Came into force 10 May 2018. https://www.legislation.gov.uk/uksi/2018/506/contents/made

[8]  Ofgem. Investigation into 9 August 2019 Power Outage. Published 3 January 2020. https://www.ofgem.gov.uk/publications/investigation-9-august-2019-power-outage

[9]  IOActive. BSides OT UK: Acme Windpharm – Colin Cassidy, Bristol, UK. 10 April 2026. https://www.ioactive.com/event/bsides-ot-uk-april-10-acme-windpharm-colin-cassidy-bristol-uk/

Walk into most introductory OT security talks and you will hear the same piece of advice. Forget CIA, think AIC: Availability first, Integrity second, Confidentiality last. It has become one of those things repeated so often nobody questions it anymore.

The problem is that a shorthand for adjusting how people think about OT has gradually been treated as a security architecture principle, and those are two very different things.

Key Takeaways

• AIC was never designed to be a security architecture principle, it was a corrective for IT practitioners entering OT environments.
• The Stuxnet, Triton/TRISIS, and Industroyer attacks all targeted integrity, not availability. Integrity failures persist undetected where availability failures trigger immediate response.
• Triton/TRISIS targeted the Safety Instrumented System rather than the process itself. Keeping the plant running was the mechanism of harm.
• OT confidentiality matters not for regulatory reasons but as reconnaissance. Network diagrams, setpoints, and credentials are what targeted attacks are built from.
• Safety and availability are not interchangeable. Taking a system offline to contain a safety risk is the correct response to a compromise.

Neither IEC 62443 nor NIST SP 800-82 endorses a priority ordering of CIA. Both derive control requirements from threat modelling and zone classification.

The CIA Triad, Briefly

The CIA triad is a foundational security model with three parts:

• Confidentiality means only authorised people can access information.
• Integrity means data is accurate and untampered.
• Availability means systems are there when you need them.

Where AIC Comes From (And Why It Stuck)

The reordering reflects something genuinely true about OT environments: plants do not tolerate downtime the way office networks do. An unexpected outage does not mean someone cannot access their email, it means a blast furnace cannot be shut down safely, or a production run is wasted mid-process, or a water treatment facility loses pressure at the wrong moment. Operators in these environments make availability-first decisions every day, and most of them understand the operational fragility in their systems far better than any incoming security team does.

As the progressive IT/OT convergence brought IT security thinking into industrial environments, the mismatch between those instincts and operational reality became a practical problem. For people arriving with IT instincts, AIC was a reasonable enough flag that those instincts needed adjusting.

Where it went wrong is that it kept getting repeated long after it had served that purpose. What was a shorthand for adjusting instincts is not a framework for building controls.

A Coverage Model, Not a Hierarchy

The CIA triad was never a ranked list. It asks whether you have addressed all three properties of a secure system. The order the letters appear in does not carry argumentative weight any more than the order of items on a nutrition label tells you which nutrient the food is optimised for.

Reordering it to AIC imposes a hierarchy the original model never had. Once that becomes the working assumption, it influences which controls get funded, which risks get accepted, and which conversations get closed down with “we prioritise availability.”

The Integrity Problem

Stuxnet is cited a lot, possibly too much, but it remains the clearest illustration of why the integrity argument matters more than the availability argument in OT, so it is worth being precise about what it actually did.

The malware did not shut down centrifuges at Natanz. Shutting them down would have triggered alarms and ended the attack’s usefulness almost immediately. Instead, it manipulated them, driving them outside safe operating parameters while feeding false readings back to the control room. Operators watched dashboards showing normal operation for months while the equipment was being destroyed. The attack worked precisely because it preserved the appearance of availability.

Triton/TRISIS, discovered in 2017 at a petrochemical facility, took that logic further. It targeted Safety Instrumented Systems, the independent layer designed to shut a process down safely before it becomes catastrophic. The attackers were not trying to cause an outage. They were trying to remove the safeguard that would have prevented a process failure from becoming a physical disaster.[1]

Industroyer, deployed against Ukraine’s power grid in 2016, issued commands directly to substation equipment using native industrial protocols rather than simply cutting power.[2]

All three targeted integrity. Sophisticated actors structure attacks this way because availability failures generate alerts and incident responses. An integrity failure that looks like normal operation can persist far longer, and by the time it is identified the window for intervention has often closed. If your security model places integrity below availability, you are deprioritising the failure mode that the most capable threat actors have consistently chosen.

On Confidentiality

The standard dismissal goes like this: “OT data is not sensitive in the way personal data or financial records are; there’s no GDPR exposure in a PLC ladder diagram.” That argument confuses data sensitivity with operational value to an attacker.

Stuxnet required detailed knowledge of Siemens S7-315 configurations, specific rotational tolerances, and the operational parameters of the enrichment process before a line of code was written. Network topology, engineering diagrams, process setpoints, HMI software versions, vendor access credentials. None of this is sensitive in a regulatory sense, but it is the reconnaissance material from which a targeted, high-consequence attack is built. The Government Accountability Office (GAO) has noted that attacks on OT increasingly originate in IT systems and migrate laterally across boundaries that exist more reliably in architecture diagrams than in actual network configurations.[3]

Those paths are considerably easier to navigate when the attacker already knows what’s on the other side.

The Property That Is Not in the Triad

Safety.

In environments where process failures can cause physical harm, the operational hierarchy does not start with availability. When a system is compromised in a way that creates a safety risk, the correct response is to shut it down and accept the availability loss. Operators in nuclear, chemical, and oil-and-gas environments do this routinely. AIC collapses safety into availability by treating them as the same concern ranked at the top of the hierarchy. Triton was designed precisely to exploit that conflation. Neutralise the safety layer first, and the availability of the process becomes the mechanism of harm.

As a small aside, it’s worth noting that German has only one word for both concepts: “sicherheit,” which covers safety and security without distinction. Whether that reflects a more integrated way of thinking about the two or is simply a linguistic coincidence, it’s a neat arrangement, and one the English-speaking security world could learn from.

What the Actual Frameworks Say

IEC 62443 does not organise security requirements around CIA or AIC. It uses security levels assigned to zones and conduits, derived from an assessment of breach consequences and the capabilities of realistic threat actors for that environment.[4] Confidentiality, integrity, and availability are all addressed. The zone model determines which controls are proportionate, not a mnemonic ordering.

NIST SP 800-82 Rev 3, updated in 2023, works similarly.[5] It was written specifically to account for the operational constraints that make OT different from enterprise IT, including the availability concerns the AIC framing was originally meant to highlight. It does not endorse deprioritising the other two properties as a result.

A More Useful Frame

The narrower point is that AIC was a useful corrective that has been promoted into something it was never designed to be. The evidence from actual attacks does not support the hierarchy it implies. Integrity and confidentiality are not lower-priority concerns to be addressed after availability has been secured. They are where the most consequential attacks have been constructed. IEC 62443 offers a more structurally sound basis for these decisions, treating asset criticality, zone classification, and threat modelling as the inputs. NIST SP 800-82 provides the operational context for applying it within real industrial constraints. Neither is a quick read, which is partly why the shorthand persists

About IOActive

IOActive is a global cybersecurity services firm specialising in critical infrastructure security, OT/ICS assessments, adversary simulation, supply chain integrity, and preparedness testing. To speak with our specialists, visit ioactive.com.

References

[1]  Federal Bureau of Investigation. TRITON Malware Remains Threat to Global Critical Infrastructure Industrial Control Systems, Private Industry Notification 20220324-001. FBI/IC3, 24 March 2022. https://www.ic3.gov/CSA/2022/220325.pdf

[2]  Cybersecurity and Infrastructure Security Agency. CrashOverride Malware (CISA Alert TA17-163A, updated July 2021). https://www.cisa.gov/news-events/alerts/2017/06/12/crashoverride-malware

[3]  US Government Accountability Office. Critical Infrastructure Protection: Actions Needed to Better Ensure an Effective Cybersecurity Approach, GAO-24-106576. Washington DC: GAO, 2024. https://www.gao.gov/assets/d24106576.pdf

[4]  ISA/IEC 62443-3-3, System Security Requirements and Security Levels. Research Triangle Park: ISA. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards

[5]  National Institute of Standards and Technology. Guide to Operational Technology (OT) Security, NIST SP 800-82 Rev 3. Gaithersburg: NIST, September 2023. https://doi.org/10.6028/NIST.SP.800-82r3

An enterprise with a long-running public bug bounty shipped a major release. Weeks later, a critical SQL injection surfaced in an authenticated reporting path. More than ten thousand PII records and clear-text card data were reachable via crafted queries. The vulnerable code sat behind role checks and a legacy admin flag; a helper function concatenated user input into a dynamic SQL fragment and bypassed the ORM’s protections. WAF rules didn’t match the payload shape. Classic failure chain; very modern consequences.

The surprise wasn’t the injection. It was the assumption that a bounty program made a professional, scoped assessment unnecessary. That premise shows up across the industry. It’s wrong.

This post is about how bug bounties and professional services actually work, where each is strong, and why neither replaces the other. No dunking on bounties, no hero worship of pen tests, just the operating reality.

What bug bounties reliably provide

Bug bounties and vulnerability disclosure programs (VDPs) deliver continuous external discovery on exposed surfaces. They create a safe intake path, reward useful reports, and sometimes attract brilliant researchers who invest weeks because a target is interesting. On internet-facing web and mobile, you’ll see wins on misconfigurations, straightforward input handling, direct object references, missing rate limits, unauthenticated logic, and the like. Private or curated bounties can improve signal by focusing experienced researchers on well-defined scopes.

Bounties work best when:

• Targets are public and testable without privileged context.
• The organization can triage at scale and respond quickly.
• The program shares enough detail to focus effort (new endpoints, known deltas, testing notes) without exposing sensitive internals.

The natural limits of bounties

Bounties are volunteer-driven. Researchers choose what to test, when to stop, and which scopes are “worth it.” You can influence attention with payouts, but you cannot guarantee time-on-task. That matters because many high-severity defects live behind authentication and require effort and context to reproduce.

Five practical limits show up repeatedly:

1) Access and trust
Crowds don’t get source-adjacent context, internal environments, realistic seeded datasets, multi-role identities, private APIs, or OT/embedded targets. Those require NDA, vetting, and clear handling expectations. Without that access, stateful, role-dependent paths remain opaque.

2) Coverage you can’t assert
A bounty payout total doesn’t map to hours of systematic scrutiny or to which flows were exercised. You don’t know which role matrices, token transitions, cache behaviors, or policy enforcement points were tested. No coverage model, no assurance claim.

3) Attention economics.
Public programs cluster attention around brands, “fun” scopes, and higher payouts. Low-profile assets can starve. A thin inbox reflects low researcher interest, not low risk.

4) Signal vs. noise
Report quality varies. Duplicates and misunderstandings create triage drag. Your team pays that tax. The question then becomes, ‘Does AI make bug bounty programs more efficient, or does AI fill reports with information that isn’t relevant, further slowing down the review process?’

5) Threat realism
Opportunistic bounties rarely model stealthy, multi-stage actors. Techniques like valid account abuse, authz abuse, and “living off the land” often require scenario-driven testing.

None of this makes bounties bad. It defines what they are: valuable, opportunistic discovery on surfaces the public can reach without privileged access.

What professional services deliver

Professional assessments, by contrast, are scoped, authenticated, and design-aware. They guarantee time-on-asset and let the client organization direct priority. They run under NDA to unlock views bounties can’t: the code and configs that implement authorization, pre-production with realistic identities and data, device and embedded paths, internal networks, and regulated systems.

The difference is method:

• Threat model first. Identify trust boundaries, intended guarantees, and abuse cases. Decide what must not happen (e.g., cross-tenant reads, stale claims elevating privilege, replay windows).
• Authenticated, role-aware testing. Ecosystem-wide evaluation covering hybrid systems and hosted subscription levels with a focus on real identities, feature tiers, entitlement models, and advanced features that get scant scrutiny in most bug bounty programs.
• State and consistency under distributed load. Assess how caches, message brokers, microservices, and async workers coordinate identity and access decisions, especially in areas where consistency or propagation missteps can spawn privilege gaps, race conditions, or unexpected cross-service behavior.
• Data-access fidelity. Examine how systems construct and execute data operations across SQL, NoSQL, and service-based data-access patterns. Reconcile data returns with user authorization policies and verify underlying storage behavior matches API or UI responses.
• End-to-end trust across services and devices. Examine how cloud services, internal systems, and connected/embedded devices establish trust and enforce identity and integrity. Uncover assumptions between services as well as between devices and backend systems especially in places where access or identity is inferred rather than explicitly checked. Gaps here are rarely revealed in bounty programs.

Outputs are different too: developer-ready reproduction, precise impact, root cause, and fix guidance tied to design; an executive summary with severity and blast radius; and retest to close the loop. You can point to what was covered, not hope it was looked at.

Where bounties miss

In this anonymized case, the vulnerable path lived behind authentication and required design context to exercise correctly. Public bounty researchers set their own priorities and typically lack the vetted access needed to test multi-role, stateful flows with confidence. You can raise payouts or share hints, but you still don’t control time-on-task or achieve coverage you can assert across authorization logic and internal data paths. That mismatch, not researcher skill, explains why critical issues in authenticated, design-dependent areas can survive a long-running public program.

These conditions don’t always exist on public tenants, and the effort required to discover them without access to code or design may keep them unscrutinized for long periods. At some point you’re trying to crowdsource a design review without giving the crowd the design.

Where bounties outperform, and how to let them

Bug bounties are not without significant intrinsic value, however. There’s a class of issues where public researchers consistently shine:

• Internet-facing edges with novel parsing or request handling (e.g., HTTP desync quirks, cache poisoning).
• Complex client behavior in mobile and web apps where deeplinks, intents, URL handlers, and WebViews interact.
• Hardening gaps and misconfigurations exposed by competition between services (e.g., CDN, WAF, gateway).
• Creative chains pieced together over time by a researcher “obsessed” with a target.

If you want that strength, there are steps you can take to make the programs more attractive and valuable to participants while also making them more effective for your organization.

• Run curated or private waves after major releases to focus attention on changed surfaces.
• Publish sanitized change notes that point researchers toward likely deltas.
• Provide robust test accounts (even if not full NDA access): multiple roles, realistic entitlements, toggleable features.

Introduce a loyalty program that adds incentives on top of the gamification already built into most bug bounties. This rewards the efforts of long-term participants and makes them want to keep coming back.

You’ll still lack coverage guarantees, but you’ll get better discovery where bounties are strong.

Program design that treats both as first-class

You need an operating model.

Before major releases or architectural change
Do a scoped, authenticated assessment on identity, authorization, data-plane access, and service-to-service trust. Focus first on those assets most recently updated. Capture abuse cases and add regression tests for anything you fix.

After you ship
Run a private or curated bounty wave on changed public surfaces. Share enough detail to focus work without exposing sensitive internals. Track time-to-first-valid and duplicate rate to gauge drift and attention.

Between releases
Keep VDP open with clear SLAs. Route valid reports quickly. Escalate ambiguous or systemic reports to professional services for root cause and verification.

For internal, OT/embedded, or regulated environments
Use vetted, NDA-bound testing only. These systems need access controls, chain-of-custody, and safety discipline the crowd can’t assume.

What to measure

You can’t declare systems “secure.” You can, however, track specific metrics to determine whether any program is mitigating risk.

• MTTR for critical/high and percentage verified by retest.
• Authenticated coverage: which roles, tenants, and state transitions were exercised.
• Change-driven retest cadence aligned to the release train.
• Time-to-first-valid bounty finding after major releases.
• Duplicate rate/triage time as a signal of bounty noise and focus.
• Severity mix by asset class over time.
• Escalation rate from bounty intake to scoped assessment (proxy for “needs design context”).

These numbers tell you if the mix you chose is working.

Common objections

“Our bounty is quiet; we must be fine.”
Or you’re not interesting to researchers. Quiet inbox does not equal coverage.

“A bounty found something after we ran a professional assessment.”
Expected. Environments change daily, and attacks always get better. Fix it, verify with retest, and add a guardrail (test, rule, or policy) to prevent recurrence.

“We’ll just raise payouts.”
Money redirects attention; it doesn’t create vetted access, design context, or guaranteed time-on-task behind auth. Know what you’re buying.

Bottom line for the industry

• Keep bounties and VDPs. They are the right way to engage the external community and maintain attention on public surfaces.
• Don’t treat them as a substitute for scoped, authenticated, design-aware testing under NDA. That’s where authorization, business logic, and safety-critical guarantees live.
• Design your program so each model does what it’s good at, and measure outcomes with retest and coverage, not with a quiet inbox.

This is not about choosing sides. It’s about refusing false assurance. Bounties provide discovery. Professional services provide an established level of confidence. Mature programs run both, and can explain, with evidence, what was covered and what still needs eyes.

AI-powered code generation is now embedded in mainstream software development, with tools like GitHub Copilot generating nearly half of developers’ code. However, IOActive’s April 2026 whitepaper, *The Security Gap in AI-Generated Code*, reveals a critical and systemic security shortfall: AI models frequently generate insecure code by default.

IOActive evaluated 27 leading AI models and AI-powered coding tools using 730 real-world programming prompts across 27 languages and 219 vulnerability categories. Prompts intentionally avoided mentioning security to reflect typical developer usage. Security outcomes were measured using 72 automated vulnerability detectors, producing nearly 20,000 analyzed code samples.

Key Findings:

• Average security performance across all models was just 59%.
• Nearly one-third (31.6%) of AI-generated code samples were fully exploitable.
• No model achieved 100% secure output; even the best configuration produced 90 vulnerabilities.
• Infrastructure and DevOps code (Dockerfiles, Terraform, CI/CD pipelines) was the most dangerous, exceeding 70–97% vulnerability rates.
• Authentication, rate limiting, and cryptography consistently failed across nearly all models.

Advanced “wrapper” tools and security-aware system prompts significantly improved results, boosting security by up to 25 percentage points. AI “temperature” settings also impacted security, with some models producing safer code at higher temperature settings. In contrast, simple prompts like ‘write secure code’ were often ineffective or counterproductive.

Memory-safe languages such as Rust and Go generated fewer vulnerabilities than Python or JavaScript, but still failed in cryptography and business logic. Dockerfiles were the single worst-performing language, with almost universal failure.

The primary takeaway from IOActive’s research is that AI-generated code is not secure by default. This means that organizations using AI for software development must treat AI output as untrusted input—especially for infrastructure, authentication, and cryptography—and enforce mandatory security review before deployment. While AI can accelerate development, without proper controls it currently introduces substantial, measurable security risk.