Tag: supply chain security

INSIGHTS | September 17, 2026

Internet-Exposed OT: What the UK Generator Incident Tells CNI Operators About Attack Surface

By IOActive

Key Takeaways

  • A small UK power generator was reportedly forced offline for four days in July 2026. Press reporting attributes the incident to Iran-linked actors, but the UK government has confirmed only that an incident occurred, declining to attribute it or identify the facility.
  • The initial access vector has not been disclosed. Operators cannot map the incident to a specific product or vulnerability, and any vendor claiming otherwise is speculating.
  • CISA’s Internet Exposure Reduction Guidance, revised on 21 August 2026, sets out four steps for identifying and removing unnecessary internet exposure, alongside a discovery port list covering common OT and remote access protocols.
  • CISA observed malicious activity against more than 100 internet-exposed systems in the US Water and Wastewater Systems Sector during July 2026, commonly involving PLCs connected directly to cellular modems.
  • UK guidance and regulation already point in the same direction. The NCSC’s secure connectivity principles for OT and the DESNZ and Ofgem proposals for baseline cyber resilience requirements both target the exposure and boundary weaknesses that recur across these incidents.

Why Does Internet-Exposed OT Matter Now?

Two items arrived within days of each other in late August 2026. CISA revised its Internet Exposure Reduction Guidance on 21 August, anchoring the document in malicious activity it had observed against internet-exposed industrial systems the previous month [5]. The Telegraph reported the following day that hackers linked to Iran had forced a small British power generator offline for four days during July [1]. Britain briefed energy company chief executives on 24 August, and the Department for Energy Security and Net Zero wrote to companies advising them on next steps [2][3].

The proximity is coincidental. The underlying subject is not. CISA describes adversaries reaching controllers through connectivity that asset owners had not catalogued, and a UK generation asset has now lost four days of output to cyber activity. The common factor across both is not a particular adversary or a novel technique. It is attack surface that organisations created themselves and did not measure.

The wider trend line supports that reading. The NCSC’s chief executive told the RUSI Annual Security Lecture in June 2026 that around 75 per cent of cyber activity targeting UK critical infrastructure can be linked to state actors, and that the agency had managed more than 200 incidents affecting CNI and its wider ecosystem over the previous year [13].

For security leaders, the useful question is not whether Iran shut down a British generator. It is whether the organisation can demonstrate, with evidence rather than assumption, what of its own operational technology is reachable from the public internet.

What Is Known About the UK Generator Incident?

The facts that can be stated with confidence are narrow. The Telegraph broke the story on 22 August 2026, reporting that a cyber attack in July had forced a small British generator offline for four days [1]. The Financial Times, BBC and Guardian subsequently published accounts largely derived from the original reporting [4].

The UK government has confirmed that an incident occurred while declining to attribute it or identify the facility. A government spokesperson described the affected asset as a small-scale energy generator and stated that at no point was there a risk to the wider energy system [3]. Michael Shanks, the minister for energy, said the government and industry were treating the incident seriously and were working with regulators and the NCSC to assess threats and strengthen protections, adding that there was no threat to the wider grid and that nobody lost power [2].

Attribution to Iran therefore rests on press reporting rather than on any official assessment. The Iranian Embassy in London did not respond to requests for comment [7]. Little technical detail has emerged through official channels, and the initial access vector remains undisclosed [4].

That gap matters for defenders. Without a published vector, the incident cannot be mapped to a specific vulnerability or product, and no defensive shopping list follows from it directly. What the incident does establish is that a UK generation asset sustained four days of outage arising from cyber activity. That is a materially different proposition from the access-without-effect intrusions that have characterised much reported CNI targeting to date, and it is the part operators should brief upwards.

What Does CISA’s Internet Exposure Reduction Guidance Recommend?

In the absence of a disclosed vector, the most useful available material addresses the attack surface rather than the adversary. CISA’s guidance approaches this from the discovery end, setting out four steps:

  1. Assess current exposure by identifying which assets are reachable via the internet, using scanning tools and services to gain visibility of the organisation’s online footprint.
  2. Evaluate the necessity of that exposure, and remove or restrict access for assets that do not need to be internet-accessible.
  3. Mitigate risks to assets that must remain exposed, through default password changes, patching, replacement of unsupported devices, use of a jump host, ingress and egress monitoring, and multi-factor authentication.
  4. Establish routine assessments so that new exposures are identified as IT and OT environments evolve [5].

The guidance is anchored in observed activity rather than theory. CISA reports that in July 2026 it observed malicious cyber activity targeting more than 100 internet-exposed systems in the US Water and Wastewater Systems Sector, commonly involving programmable logic controllers connected directly to a cellular modem [5]. Threat actors remotely accessed those exposed PLCs, changed device IP addresses and passwords, and caused loss of monitoring and control functionality and, in some cases, operational disruption [5].

The cellular modem detail deserves attention. Connectivity installed by vendors or integrators for maintenance convenience frequently sits outside the corporate network and outside routine attack surface scanning. The controller is directly reachable while the organisation’s own exposure reporting shows nothing [5].

CISA also publishes a port list for discovery work, covering remote access services and OT protocols including Modbus on 502 to 507/TCP plus additional implementation ports, Niagara Fox on 1911/TCP and 4911/TCP, EtherNet/IP on 2222/UDP and 44818/TCP, DNP3 on 19999/UDP and 20000/TCP and UDP, OPC UA on 4840/TCP and 4843/TCP, and BACnet on 47808/TCP [5]. An open port is not itself evidence of compromise, but CISA advises that any internet-accessible OT or remote access service should be investigated and unnecessary exposure removed [5].

One point of discipline applies here. CISA does not attribute the July water sector activity to a named actor in this document. The description does resemble the Iranian-affiliated campaign against internet-exposed PLCs set out in advisory AA26-097A, which was updated on 22 July 2026 to add Schneider Electric and Siemens controllers alongside Rockwell, and which names the water and wastewater sector directly [6]. IOActive examined that update in Iranian-Affiliated Actors Expand PLC Targeting to Siemens and Schneider Electric. Resemblance is not attribution. CISA does not join the two, and operators briefing boards should be precise about the difference between an observed exposure pattern and an attributed campaign. Neither should be joined to the UK incident without evidence.

What Do UK Guidance and Regulation Already Require?

UK operators do not need to wait for American guidance to act, because equivalent direction already exists. The NCSC’s secure connectivity principles for OT address the same weaknesses, covering the requirement that OT devices are not directly exposed to the public internet, that management protocols and the OT boundary are hardened, that secure versions of industrial protocols are adopted where available, and that OT, management and business networks are segmented [8]. A worked example for the water sector was added to the collection on 11 August 2026, the first content authored by the Industrial Control System Community of Interest to appear on the NCSC website [9]. Separate NCSC guidance covers creating and maintaining a definitive view of OT architecture, which is the UK equivalent of CISA’s first step [10].

The regulatory position is also moving. DESNZ and Ofgem published their response on reshaping cyber regulation in downstream gas and electricity on 5 August 2026, confirming an intention to develop baseline cyber resilience requirements for all Ofgem licensees and to review which operators fall within the Network and Information Systems Regulations 2018 [11]. Ofgem will lead development of the detailed proposals, working with DESNZ and the NCSC.

The direction of travel matters for smaller generators in particular. The current regime concentrates obligations on the largest operators, while the incident reported in July involved a small asset. The Cyber Security and Resilience Bill would expand the existing framework, including powers intended to allow ministers to direct regulated organisations to take proportionate action where an imminent or live cyber threat puts national security at risk [12]. Shanks has also indicated that a wider Energy Resilience Strategy is due later in 2026 [7].

Operators should expect the compliance floor to rise. Building an accurate exposure picture now is cheaper than doing it under a regulatory deadline.

Who Is Affected by Internet-Exposed OT Risk?

Electricity generation and distribution operators

The UK incident involved a small generation asset, and that is the substance of the concern rather than a mitigating detail. A distributed generation fleet multiplies near-identical assets running comparable equipment sourced from a small pool of suppliers. A weakness that is inconsequential in one asset compounds when repeated across hundreds [7].

Water and wastewater utilities

CISA’s observation of more than 100 exposed systems in a single sector within one month indicates that exposure is systemic rather than exceptional [5]. Smaller utilities with limited engineering headcount are least likely to hold an accurate inventory of internet-facing assets.

Manufacturers and process industries

Nothing in the exposure problem is specific to CNI designations. Discrete manufacturing, chemicals, food production and building management run the same protocols on the same controllers, frequently with weaker segmentation and no regulatory driver.

Suppliers, integrators and maintenance providers

Cellular modems, remote access appliances and vendor support tunnels are installed for legitimate operational reasons and rarely appear in the asset owner’s exposure register [5].

Boards and audit committees

The question of what the organisation exposes to the internet is an assurance question rather than a technical one, and it is answerable with a number.

What Are the Challenges for Operators?

The published guidance is not technically demanding. The difficulty is organisational and operational.

Verification is harder than assertion. Most operators can state that their OT is segmented. Fewer can evidence that claim against an external view of their own address space, and fewer still have examined infrastructure introduced by vendors, contractors or legacy projects [5].

Patching carries operational and safety consequences. OT frequently runs software that cannot be updated remotely, and operators must weigh intervention against the risk that downtime itself creates a safety issue. Replacement programmes run for years, and exposure cannot simply be accepted in the interim. The workable response is to move carefully when changing the plant and quickly when reducing the risk around it.

Ownership is the recurring failure. Guidance of this kind repeats the same controls because no single person owns the outcome of knowing what the organisation exposes and acting when a scan flags the same default credential six months running.

Detection in OT is more tractable than in IT, and is routinely neglected. OT environments are typically static and predictable, which makes baseline monitoring effective at identifying unauthorised activity and misconfiguration [8]. Few operators exploit that property.

How Can IOActive Help?

The defining feature of this incident is that the vector is undisclosed. There is no patch to apply and no indicator to hunt for. What remains actionable is the attack surface itself, and establishing that is an assessment problem rather than a threat intelligence problem.

IOActive has worked in industrial control environments since building the first proof-of-concept worm against the smart grid in 2009 [14], and its team has contributed to standards and best practice including NIST 800-53 and 800-37. The services below address the gaps this incident and the accompanying CISA guidance expose.

Full Stack Security Assessments

CISA’s first step, and the NCSC’s guidance on maintaining a definitive view of OT architecture, both require an operator to establish what is reachable rather than to assert it [5][10]. Our Full Stack assessments examine the whole environment rather than a single layer, covering internet-facing controllers and HMIs, the OT and IT boundary, the cellular modem paths that frequently give field sites their only route to the internet, and the firmware and silicon of the devices themselves through penetration testing, reverse engineering, side-channel analysis and fault injection. Where an asset has lost four days of output and no vector has been published, that depth is what separates a finding from a reassurance.

Supply Chain Integrity

The activity CISA observed in the water sector involved controllers connected directly to cellular modems, which is connectivity the asset owner frequently did not commission and does not monitor [5]. Our Supply Chain Integrity work assesses the security posture of technology providers and critical third parties, covering firmware, embedded systems, remote access arrangements and procurement processes, so that inherited exposure is identified before it becomes a shared incident. For UK operators this maps onto the critical supplier designation powers in the Cyber Security and Resilience Bill [12].

Advisory Services

The regulatory floor is rising for precisely the class of asset involved here. DESNZ and Ofgem intend to develop baseline cyber resilience requirements for all Ofgem licensees and to review which operators fall within the NIS Regulations 2018 [11]. We examined what that direction of travel means for operators in The UK Energy Sector Cyber Security Strategy. Our Advisory Services cover programmatic security review, security programme development and management, and Virtual CISO support, turning an exposure picture into a prioritised remediation plan with named accountability and the evidence a board needs for CAF or equivalent regulatory assurance.

The water sector offers a useful contrast. While recent attention has centred on attacks against US water infrastructure, coverage of how UK water regulators are responding has been comparatively thin — despite water companies having been in scope of the NIS Regulations since 2018 and required to submit annual OT resilience risk assessments against the NCSC’s Cyber Assessment Framework. Ofwat’s lever here is largely financial: PR24 price control deliverables are tied to the Drinking Water Inspectorate’s regulation 18 notices, with penalties layered on top of any Inspectorate enforcement. What’s less visible, compared to Ofgem’s published guidance for energy OES, is an equivalent public baseline for water operators to work against — sector performance data isn’t published, and companies are largely left to interpret CAF outcomes on their own. That’s exactly the kind of gap our cross-industry ICS/OT experience is built to close.

If you would like to discuss how your organisation’s internet-facing OT exposure measures up against the activity described in CISA’s guidance, we welcome the conversation.

Connect With a Security Expert

  1. Establish an external view of the estate. Use exposure discovery tooling to enumerate what is reachable from the public internet across known organisational IP space, rather than relying on the internal asset register as the source of truth [5].
  2. Reconcile the external view against the register. Treat every unexplained result as an incident precursor. The gap between the two views is the working measure of unmanaged exposure.
  3. Interrogate vendor and contractor connectivity. Identify cellular modems, support tunnels and remote access appliances installed outside change control, including those commissioned during legacy projects [5].
  4. Remove what is unnecessary and secure what remains. Route required remote access through a managed gateway, firewall or VPN rather than connecting directly to a PLC, HMI or RTU, and enforce unique credentials with phishing-resistant multi-factor authentication [5].
  5. Harden the OT boundary against the NCSC principles. Confirm that boundary devices are within vendor support, that management interfaces are unreachable from the internet, and that segmentation between OT, management and business networks is enforced rather than assumed [8].
  6. Verify controller state across the estate. Confirm that controllers are not left in programming or maintenance modes and that write protection is applied to control logic.
  7. Baseline OT network traffic. Establish what normal communication looks like and alert on attempts to reach controllers and HMIs from unexpected devices, networks or routes [8].
  8. Report exposure to the board as a measurable figure. Present the count of internet-facing OT assets, the proportion with a documented operational justification, and the trend across reporting periods, ahead of the baseline requirements now being developed by Ofgem [11].

Conclusion

The UK generator incident may never be attributed publicly with the confidence operators would prefer, and the vector may never be disclosed. Waiting for either would be a mistake, because the actions that reduce this risk do not depend on knowing who was responsible. Guidance on both sides of the Atlantic describes an attack surface that organisations create for themselves and can therefore measure and reduce for themselves. Four days of outage at a small generator is a manageable consequence for the grid as a whole; for the owner facing the remediation bill, the reputational fallout, and the regulatory scrutiny that follows, it is anything but manageable. The same weakness, repeated across a distributed estate and reached by an actor willing to cause visible disruption, stops being a grid-level inconvenience and becomes a systemic one. That asymmetry is sharper in the US, where water and electricity distribution are served by a much larger population of small, often municipally or cooperatively owned operators: a single incident is unlikely to trouble the wider grid or supply, but it can be existential for the operator itself. Further guidance and regulatory detail are expected through the remainder of 2026, and operators who can already answer the exposure question — at whatever scale they sit — will find the rest considerably easier.

References

  1. The Telegraph, “Iranian hackers shut down UK power plant”, 22 August 2026. https://www.telegraph.co.uk/news/2026/08/22/iranian-hackers-shut-down-uk-power-plant/
  2. Reuters, “UK briefs energy chiefs after Iran-linked cyber attack reports”, 24 August 2026. https://www.reuters.com/business/energy/uk-briefs-energy-chiefs-after-iran-linked-cyber-attack-reports-2026-08-24/
  3. CNBC, “Small UK power generator shut down after cyberattack linked to Iran”, 23 August 2026. https://www.cnbc.com/2026/08/23/small-uk-power-plant-shut-down-after-iran-linked-cyberattack-report.html
  4. SecurityWeek, “Iran-Linked Hackers Shut Down UK Power Plant for Four Days”, August 2026. https://www.securityweek.com/iran-linked-hackers-shut-down-uk-power-plant-for-four-days/
  5. Cybersecurity and Infrastructure Security Agency, “Internet Exposure Reduction Guidance”, revision date 21 August 2026. https://www.cisa.gov/resources-tools/resources/exposure-reduction
  6. CISA, FBI, NSA, EPA, DOE, CNMF and Department of the Treasury, “Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure”, AA26-097A, updated 22 July 2026. https://www.ic3.gov/CSA/2026/260722.pdf
  7. Industrial Cyber, “UK power generator reportedly taken offline in Iran-linked cyberattack, raising energy security concerns”, 24 August 2026. https://industrialcyber.co/utilities-energy-power-water-waste/uk-power-generator-reportedly-taken-offline-in-iran-linked-cyberattack-raising-energy-security-concerns/
  8. National Cyber Security Centre, “Operational Technology: Secure connectivity principles”. https://www.ncsc.gov.uk/collection/operational-technology/secure-connectivity
  9. National Cyber Security Centre, “Water sector example added to the NCSC’s Secure connectivity principles”, 11 August 2026. https://www.ncsc.gov.uk/blogs/water-sector-example-added-to-the-ncscs-secure-connectivity-principles
  10. National Cyber Security Centre, “Operational Technology: Creating and maintaining a definitive view of your OT architecture”. https://www.ncsc.gov.uk/collection/operational-technology/definitive-architecture-view
  11. Department for Energy Security and Net Zero and Ofgem, “Whole energy cyber resilience requirements: reshaping cyber regulation in downstream gas and electricity”, government response, updated 5 August 2026. https://www.gov.uk/government/consultations/whole-energy-cyber-resilience-requirements-reshaping-cyber-regulation-in-downstream-gas-and-electricity
  12. UK Government, “Cyber Security and Resilience (Network and Information Systems) Bill: Power to direct regulated entities”, factsheet, updated 30 June 2026. https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets
  13. Royal United Services Institute, NCSC Chief Executive remarks, RUSI Annual Security Lecture, June 2026. https://www.rusi.org/news-and-comment/rusi-news/hostile-states-behind-75percent-cyber-attacks-uk-infrastructure-ncsc-ceo
  14. M. Davis, IOActive, “Advanced Metering Infrastructure (Smart Grid) Device Security”, Black Hat USA 2009. https://blackhat.com/presentations/bh-usa-09/MDAVIS/BHUSA09-Davis-AMI-SLIDES.pdf
INSIGHTS | August 20, 2026

Key Takeaways from the 2026 OCP APAC Summit

By Alejandro Hernandez

IOActive recently attended the 2026 OCP APAC Summit in Taipei. Below are our key takeaways from two days with the Open Compute community, along with a short recap video from the show floor at the end of this post.

Key Takeaways

  • The 2026 OCP APAC Summit (August 11–12) drew hyperscalers, semiconductor companies, device manufacturers, and infrastructure providers under the theme “Leading the Future of AI.”
  • AI security conversations extended beyond compute performance to the full stack: networking, cooling, storage, power, firmware, and the security controls underneath all of it.
  • Openness was a recurring theme, anchored by a dedicated SONiC Workshop on the open-source network operating system.
  • Multiple talks and vendor conversations pointed to growing interest in OCP S.A.F.E., the framework for independent security review of device firmware.
  • IOActive helped develop OCP S.A.F.E. from its early stages and continues to evaluate firmware security for device manufacturers today.

AI in the Agentic Era

AI was naturally at the center of this year’s summit, but the conversation went well past GPUs and raw compute performance.

The future of AI depends as much on trustworthy infrastructure as it does on faster accelerators and larger clusters. That means thinking about security across the whole stack, from applications and operating systems down to the firmware and hardware controlling the physical devices.

Open Data Centers and Open Networking

Openness was the other constant. The Open Compute Project’s philosophy of open hardware specifications, interoperable architectures, open firmware increasingly extends to networking, and the summit’s dedicated SONiC Workshop was a good example. SONiC, the open-source network operating system, brought together developers, users, maintainers, and vendors to compare notes on real-world deployments.

The direction of travel is toward data centers built from a diverse ecosystem of components rather than a single vertically integrated platform. That shift raises a practical question for operators: as devices and firmware arrive from a wider set of suppliers, how do you know they were built securely?

OCP S.A.F.E. and the Case for Independent Security Review

That question was the throughline of many of our conversations at the summit. Multiple technical talks and device-vendor discussions pointed to growing interest in OCP S.A.F.E., which lets vendors have their products evaluated by independent security reviewers against an established methodology.

For manufacturers, that’s more than a compliance checkbox. An independent review can surface vulnerabilities in firmware and other security-critical components before devices ship at scale, and it gives customers a concrete basis for confidence in what they’re deploying. As the supply chain behind any given rack grows more diverse, security assurance needs to travel with it.

IOActive has been involved in developing the OCP S.A.F.E. framework since its early stages, and we continue to work with device manufacturers on firmware and security assessments across the infrastructure being deployed today.

Taipei as a Meeting Point

Taipei was a fitting location for these conversations. Taiwan sits at the center of the global technology supply chain, home to a dense concentration of semiconductor companies, server manufacturers, ODMs, component suppliers, and firmware developers—much of the ecosystem responsible for the infrastructure data centers worldwide run on.

The summit itself made room for those conversations to happen: networking lounges, meeting areas, and coffee stations throughout the venue, lunch on-site, and reception drinks in the Expo Hall on the first evening. Live translation kept the technical sessions accessible to an international audience.

If you’re a device vendor preparing for OCP S.A.F.E. or looking to strengthen your firmware’s security, contact IOActive. Our team supports OCP S.A.F.E. assessments and independent firmware source-code security reviews.

Watch Our OCP APAC Summit Recap

Want to see the event from the show floor? We captured some of the technologies, conversations, and demonstrations from our time at the 2026 OCP APAC Summit in Taipei.

INSIGHTS | August 18, 2026

The Five Eyes AI Shift in Cyber Risk Statement: What Industry Leaders Need to Know Now

By IOActive

Key Takeaways

  • On 22 June 2026, the leaders of the Five Eyes cyber security agencies issued a joint statement, The AI Shift in Cyber Risk: Why Leaders Must Act Now, warning that frontier AI is transforming cyber risk on a timeline measured in months, not years.
  • The statement is signed by the heads of the National Cyber Security Centre (NCSC, UK), Cybersecurity and Infrastructure Security Agency (CISA, US), National Security Agency (NSA, US), Australian Signals Directorate (ASD, Australia), Communications Security Establishment (CSE, Canada), and Government Communications Security Bureau (GCSB, New Zealand) — an unusually unified articulation of urgency from the Five Eyes partnership.
  • Cyber risk is explicitly reframed as a core business risk and board-level responsibility, not a technical issue to be delegated downward.
  • Five practical actions are prescribed: reduce attack surface, accelerate patching, address legacy systems, strengthen identity and access controls, and prepare for incidents before they happen.
  • The statement lands days after the NCSC’s own CEO disclosed that 75% of attacks on UK critical infrastructure over the past year are linked to hostile states, and weeks after NCSC guidance warning of an incoming “vulnerability patch wave” driven by AI-accelerated exploitation.
  • Organisations that treat this as a compliance afterthought will be out of step with where their regulators, and their adversaries, are already heading.

A Statement for a Narrowing Window

Joint statements from the Five Eyes cyber agencies are not issued lightly, and this one is notable for its tone as much as its content. Published on 22 June 2026, The AI Shift in Cyber Risk [1] is signed jointly by Stephanie Crowe (ASD), Rajiv Gupta (CSE), Catriona Robinson (GCSB), Richard Horne (NCSC), David Imbordino (NSA), and Nick Andersen (CISA). The framing is unambiguous: frontier AI models are expected to exceed current industry expectations, and the timeline for that shift is not years, it is months.

This is not an isolated warning. Five days before the statement was published, NCSC CEO Dr Richard Horne told the Royal United Services Institute’s Annual Security Lecture that the NCSC had managed more than 200 cyber incidents affecting the UK’s critical national infrastructure in the year to May 2026, with around 75% believed linked to hostile state actors including Russia, China, and Iran [2]. Horne went further, arguing that cyber security should no longer be framed as a risk to be tolerated within appetite, but as an ongoing contest with capable adversaries. He also pointed to an NCSC assessment that by 2028, AI-enabled capabilities will likely be used to exploit known vulnerabilities in legacy technology at scale across UK critical infrastructure.

That assessment builds directly on guidance the NCSC published in May 2026, warning organisations to prepare for a “vulnerability patch wave”: a forced correction in which AI-accelerated exploitation surfaces decades of accumulated technical debt across commercial, open source, and proprietary software simultaneously [3]. The Five Eyes statement should be read as the international consolidation of that warning, not a standalone development.

What Does the Statement Set Out?

The statement is short and deliberately free of new technical detail. Its purpose is to compress urgency into a small number of leadership-level actions, structured around four overarching asks and five practical steps [1].

Leaders are urged to:

  • Understand and assess risk, readiness, and accountability. Boards need a clear, current picture of organisational exposure, not a static risk register reviewed annually.
  • Prioritise foundational cyber security practices and controls. Sophistication in tooling does not substitute for getting the fundamentals right.
  • Empower cyber leaders with authority and resources. Cyber leadership requires the mandate to act, not just the responsibility to report.
  • Stay actively engaged as threats and guidance evolve. Static governance models cannot keep pace with a threat landscape that is itself accelerating.

Two structural points distinguish this statement from prior Five Eyes guidance. First, it reframes AI not solely as an adversary capability but as a defensive obligation: organisations are explicitly told to use AI deliberately to strengthen defence, not merely to improve efficiency. Second, it sets an expectation that breaches are not preventable in absolute terms; preparedness is reframed as the capability to contain incidents quickly before they escalate into operational and financial crises [1].

Who is Affected by the Statement?

Boards and Executive Leadership

The statement is addressed primarily upward, not downward. It states plainly that cyber resilience is not an IT issue, it is central to operational continuity and market trust, and that it is not enough to have controls; leaders must be confident those controls will perform during a real incident [1]. This places direct accountability on boards and executives to verify resilience, not simply to fund it.

CISOs and Security Leadership

For security leaders, the statement is a mandate to escalate. The call to empower cyber leaders with authority and resources [1] gives CISOs a clear external reference point when seeking budget, headcount, or the organisational authority to challenge unsafe trade-offs that have previously been accepted in the name of operational convenience.

Operators of Critical National Infrastructure

For CNI operators, the statement reinforces direction already set domestically. The NCSC’s own intervention five days prior, disclosing that three-quarters of attacks on UK CNI are state-linked [2], makes clear that the threat described in the Five Eyes statement is not a future scenario for this sector. It is the current operating environment.

Vendors and Technology Providers

The statement explicitly calls on leaders across industry, including vendors, to act now [1]. Combined with the NCSC’s separate warning that a wave of vulnerability disclosures is approaching across commercial, open source, and proprietary software [3], vendors should expect both faster exploitation of existing flaws and intensifying customer expectations around patch velocity and secure-by-design practice.

What are the Key Challenges Organisations Will Face?

Compressed Exploitation Timelines

The central technical claim underpinning the statement is that AI is shrinking the window between vulnerability discovery and exploitation [1]. Patch cadences and change-management processes built around weeks or months of lead time were not designed for this. Organisations with manual patching processes, particularly across operational technology environments with long update cycles, face a widening gap between the speed of the threat and the speed of their own response.

Your Adversary Already Has an AI Upgrade

Even if your organization hasn’t touched AI, your attackers have. The patch window that once gave defenders breathing room is effectively gone — Mandiant’s time-to-exploit tracking shows exploits now landing on or before the day a CVE goes public. Exploitation itself has become a commodity: working proof-of-concept exploits can be generated in about 15 minutes, and autonomous vulnerability discovery campaigns can be run for roughly $50. This isn’t theoretical. Recovered logs from a June incident (via OALABS) showed a single operator driving over 1,000 AI-agent sessions across 14+ companies, with the models flagging a policy violation only about 10 times — because every request was simply framed as “authorized red-team” work. Social engineering has scaled right alongside it: Arup lost $25.6 million in 2024 after a video call where every “colleague” on the line was a deepfake, and the economics of that kind of attack have only gotten cheaper since. None of this requires exotic new attack vectors. It’s the same attack surface organizations have always had, now facing an adversary that doesn’t sleep, doesn’t hesitate, and operates at machine speed.

Legacy and Unsupported Systems

The statement is blunt that unsupported systems are not just technical debt, they are strategic liabilities [1]. This sits uncomfortably with sectors where legacy estate is structural rather than incidental, where replacement cycles are measured in years and safety-critical considerations constrain how quickly systems can be patched or retired.

Governance Gaps Between Boards and Technical Teams

Repeated emphasis on board-level accountability assumes a level of cyber literacy that many boards do not yet have. The gap between technical risk and the language boards use to govern it remains one of the most persistent obstacles to the kind of confident assurance the statement demands.

AI as a Dual-Use Capability

The statement’s insistence that organisations use AI deliberately to strengthen defence, not just improve efficiency [1], is a meaningfully higher bar than most organisations’ current AI security posture. Many security teams have adopted AI tooling for productivity gains. Far fewer have built the detection, monitoring, and response capability the statement envisages, while simultaneously managing the new attack surface that frontier AI systems themselves introduce.

Shipping Faster Means Shipping More Attack Surface

AI coding assistants have undeniably accelerated software delivery — but speed and security are moving in opposite directions. Veracode’s testing across more than 100 models found that roughly 45% of AI-generated code carries a security weakness. What’s more concerning is the trendline: functional correctness has raced past 95%, while the security rate has stayed flat at around 55% for two years running. Newer, smarter models are writing code that works — not code that’s safe. The practical impact is that attack surface is now growing at delivery speed, with code merging faster than any human review process was designed to handle, whether that code was sanctioned by the organization or introduced through shadow AI use, often with no clear provenance to trace it back. At the same time, client appetite for security testing is rising faster than budgets are — creating a widening gap between how much validation organizations want and how much they’re actually resourcing. Closing that appetite-budget gap is, in many ways, the central challenge facing security teams right now.

Checkout Our Blog to Learn More – The Security Gap in AI-Generated Code

Zero-Day Proliferation

The statement warns directly that as AI systems evolve, new and previously unknown vulnerabilities will emerge, including zero-day vulnerabilities [1]. Defence-in-depth, rather than reliance on any single control or technology, is positioned as the only credible response to a vulnerability landscape that is itself becoming less predictable.

How IOActive Can Help

IOActive’s work across offensive security, operational technology and industrial control system (OT/ICS) assessment, and critical infrastructure advisory positions us to support organisations translating this statement’s leadership-level mandate into operationally credible defence. Testing, not assumption, is how organisations find out whether their controls will actually perform under pressure, which is precisely the bar the statement sets.

Red Team and Purple Team Services

The statement’s call to verify that controls will perform during a real incident, not merely exist on paper [1], is best answered through adversarial testing rather than compliance review. IOActive’s Red Team operations emulate the tactics of the threat actors most likely to target a given organisation’s sector and assets, while our Purple Team engagements translate offensive findings directly into measurable improvements in detection and response.

Full Stack Security Assessments

Reducing attack surface and accelerating patching, two of the statement’s five practical actions [1], both depend on first knowing where exposure actually sits. Our full stack assessments examine internet-facing systems, cloud environments, and on-premises infrastructure together, identifying the specific systems an attacker would prioritise rather than producing a generic vulnerability count.

Supply Chain Integrity

The statement’s call for action extends explicitly to vendors [1]. IOActive’s Supply Chain Integrity service assesses the security posture of technology providers and critical third parties, reviewing firmware, embedded systems, and procurement processes for inherited risk before it becomes either a compliance finding or an incident vector.

Preparedness and Resilience Testing

The statement’s framing of preparedness as a capability to be trusted, not assumed, aligns directly with our tabletop exercise and crisis simulation work. We help organisations stress-test detection, escalation, and recovery processes ahead of a real incident, building the operational muscle memory boards are now being asked to assure.

Threat Modeling and Advisory

Understanding and assessing risk, readiness, and accountability, the statement’s first call to action [1], requires a structured, evidence-based view of organisational exposure. Our threat modelling and advisory engagements give CISOs and boards a shared, prioritised picture of risk that can be acted on with confidence rather than debated indefinitely.

The statement is explicit that delay carries growing and avoidable risk [1]. We recommend the following immediate actions.

  1. Brief your board now on the statement’s core claim, that cyber risk assumptions can become outdated in months, and translate that into business, financial, and reputational terms.
  2. Map your patch and change-management cycle against the compressed exploitation timelines the statement describes, identifying where current processes cannot keep pace.
  3. Inventory legacy and unsupported systems with explicit reference to their exposure on external attack surfaces, not just their internal criticality.
  4. Review identity and access controls across critical systems, with particular attention to permissions that have accumulated without recent review.
  5. Test your incident response plan through a structured exercise that assumes a breach has already occurred, rather than one that tests whether it can be prevented.
  6. Evaluate how AI is currently used across your security function, distinguishing tools adopted for efficiency from capability genuinely built to strengthen detection and response.

Conclusion

The Five Eyes statement is short by design, but its brevity should not be mistaken for limited weight. Six of the world’s most authoritative cyber security agencies have chosen to speak with one voice, in plain language, to say that the basis on which most organisations currently assess cyber risk is already out of date.

The statement does not introduce new technical obligations. It does something arguably more consequential: it removes the option of treating AI-accelerated cyber risk as a future planning consideration. Combined with the NCSC’s own recent disclosures on the scale of state-linked attacks against UK critical infrastructure and the coming vulnerability patch wave, the message to leaders is consistent and increasingly difficult to defer.

Organisations that wait for a forcing event, whether a breach, a regulatory deadline, or a sector-specific mandate, will be acting from a position of weakness. Those that act now, testing their assumptions rather than reviewing them, will be the ones still standing when the window the statement describes finally closes.

If you would like to discuss how your organisation’s current posture measures up against the expectations set out in this statement, or how IOActive can support your cyber resilience programme, we welcome the conversation.

References

[1] Australian Signals Directorate, Communications Security Establishment, Government Communications Security Bureau, National Cyber Security Centre (UK), National Security Agency, Cybersecurity and Infrastructure Security Agency. The AI Shift in Cyber Risk: Why Leaders Must Act Now. 22 June 2026. https://www.ncsc.gov.uk/news/the-ai-shift-in-cyber-risk-why-leaders-must-act-now

[2] National Cyber Security Centre. NCSC CEO: Hostile States Linked to Three-Quarters of Cyber Attacks Affecting UK’s Critical Systems. 17 June 2026. https://www.ncsc.gov.uk/news/ncsc-ceo-hostile-states-linked-to-three-quarters-of-cyber-attacks

[3] National Cyber Security Centre. Preparing for a ‘Vulnerability Patch Wave’. 1 May 2026. https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave

INSIGHTS | August 10, 2026

When the Advisory Arrives First: Minnesota’s Water Utilities and the Limits of Warning

By IOActive

Key Takeaways

  • More than 30 Minnesota community water systems were targeted across July 26 and 27, 2026 in what Minnesota IT Services (MNIT) has characterized as a coordinated cyberattack. Automated control functions were affected at several utilities, and the City of Braham briefly took its water treatment plant offline [4][6][9].
  • No attribution has been made. Officials have not named a threat actor, identified an exploited vulnerability, confirmed which products were affected, or established whether data was taken [4][7].
  • The incidents followed four days after the July 22 update to joint advisory AA26-097A, which widened observed Iranian-affiliated targeting of internet-facing programmable logic controllers (PLCs) from Rockwell Automation equipment to include Schneider Electric and Siemens devices [1][3].
  • The City of Plymouth reported that impact was confined to equipment reached over cellular links. Remote assets — water towers, lift stations, pump stations — frequently sit outside the boundary of formal risk and vulnerability assessments [4][10].
  • The consequence class here is loss or manipulation of view and control, not data loss. Operators in the UK and Europe carry equivalent exposure, under a regulatory regime that is tightening as the UK Cyber Security and Resilience Bill progresses through Parliament [16].

Why This Incident Matters Now

A joint advisory told critical infrastructure operators, in specific terms, that state-linked actors were reaching internet-facing PLCs at water and wastewater utilities and manipulating what those controllers do. Four days later, more than 30 water systems in a single US state reported disrupted automated controls over a 48-hour period.

Whether the two events are connected has not been established publicly, and this analysis does not assume they are. The more useful question for security leaders is what the sequence reveals about the distance between a warning being issued and a warning being actioned. Advisory AA26-097A has been in circulation since April 7, 2026 [1]. Its July update did not describe a novel technique. It broadened the list of affected manufacturers and added detection guidance. For any operator running an internet-reachable controller from one of the named vendors, the required response was already documented, already free, and already several months old.

The Minnesota incidents are therefore worth examining less as a novel threat and more as a measurement of how much of the sector is positioned to act on advisories at the speed at which they are now being issued.

What Actually Happened in Minnesota

MNIT confirmed that more than 30 community water systems were targeted on July 26 and 27, 2026, and activated a statewide cybersecurity incident response [4][6][8]. The agency is coordinating with CISA, the Environmental Protection Agency (EPA), the FBI, state agencies and affected utilities [5][6]. The FBI has confirmed it is in contact with victims [6].

Four cities disclosed incidents publicly: Braham, Maple Plain, Plymouth and South St. Paul [4][9][10][11][12]. The reported pattern is consistent across them. Automated control functions were affected; contingency procedures were activated; in most cases water and wastewater operations continued. Braham took its treatment plant offline after detecting the incident and asked residents to limit water use, later reporting that the attackers had shut down operating controls, taking the well and treatment plant with them [4][9]. Maple Plain declared a local state of emergency to support its response [5][12]. South St. Paul reported that manual intervention by public works staff maintained normal operations despite the loss of some automated controls [4][11]. Plymouth attributed communications problems at two water towers and multiple lift stations to the incident, and stated that the impact was limited to equipment connected via cellular communications [4][10].

The affected cities have consistently informed residents that drinking water remains safe. MNIT stated on July 28 that it was aware of no active requests for residents to alter their water use [5].

Several material facts remain unpublished. MNIT has not released a full list of affected systems. No exploited vulnerability, affected product line or exfiltration finding has been made public. No actor has been named. Iranian-affiliated groups such as CyberAv3ngers and Handala fit the profile of the activity, and several outlets have noted the resemblance, but investigators have stressed that formal attribution has not been made [4][7]. Analysts should treat the attribution question as open.

What Changed in Advisory AA26-097A on July 22

Advisory AA26-097A was first published on April 7, 2026 by the FBI, CISA, the NSA, the EPA, the Department of Energy and US Cyber Command’s Cyber National Mission Force. It documented Iranian-affiliated advanced persistent threat (APT) actors exploiting internet-connected operational technology (OT) devices across the Government Services and Facilities, Water and Wastewater Systems, and Energy sectors, with confirmed disruption at victim organizations since at least March 2026 [1][2].

The July 22 update made three substantive changes [1][2][3].

Manufacturer Scope Widened

Observed targeting now extends beyond Rockwell Automation and Allen-Bradley controllers to Schneider Electric and Siemens PLCs, and potentially other branded devices. Specific models are named in the advisory, including Rockwell CompactLogix and Micro850, Schneider Modicon M340, and the Siemens S7-1200 series [3].

Detection Guidance for Reusable Code Modules

The update adds guidance on identifying malicious modifications to reusable logic — Add-On Instructions within Rockwell programs, for example — including validating project files and comparing running logic against a known-good baseline [3].

A Refreshed Indicator Set and a New Co-Authoring Agency

The update publishes a refreshed set of indicators of compromise, and the Department of the Treasury is added as a co-authoring agency [1][17].

The access method described in the advisory is the part that should concern operators most, because it is not a vulnerability in the conventional sense. Actors reach internet-exposed controllers from leased overseas hosting infrastructure and connect using the manufacturers’ own engineering software — Studio 5000 Logix Designer, EcoStruxure Control Expert, TIA Portal — the same tooling legitimate engineers use [1][3]. Connections made this way are difficult to separate from authorized administrative activity. From there, the advisory documents modification of control logic, disabling of alarm and shutdown functions, and alteration of data presented on operator displays [3].

Water and Wastewater Systems is named explicitly among the targeted sectors, and internet-exposed PLCs remain the primary access point [3].

Who Is Affected by Internet-Exposed OT?

US Water and Wastewater Operators

The sector’s risk profile varies enormously by resource level. Large municipal utilities often run segmented networks, dedicated security staff and formal asset lifecycle management. Most community water systems are small municipal utilities or rural cooperatives, some serving only a few hundred customers, without dedicated cybersecurity personnel or continuous monitoring [14]. A technique that a well-resourced utility would contain quickly can cause prolonged operational impact in a small system. The EPA leads federal water sector cybersecurity efforts but has no explicit statutory authority to mandate cybersecurity measures, relying on voluntary engagement and technical assistance [15].

UK and European Operators

Drinking water is an in-scope sector under the UK’s NIS Regulations 2018, and the UK Cyber Security and Resilience (Network and Information Systems) Bill would expand obligations, incident reporting requirements and regulatory powers across those sectors [16]. The Bill received its second reading in the House of Lords on July 14, 2026 [16]. The technical exposure is not materially different: the same vendors, the same engineering tooling, and the same practice of reaching remote assets over public networks.

Critical National Infrastructure (CNI) Operators in Other Sectors

Energy and government facilities are named alongside water in AA26-097A. Any organization running the named controller families in an internet-reachable configuration is within the described targeting scope, regardless of sector [1][3].

System Integrators and OT Suppliers

Where control system architecture is delivered by an integrator, the connectivity decisions — including secondary and backup communication paths — are frequently made outside the asset owner’s direct visibility. Under the Cyber Security and Resilience Bill, suppliers to regulated entities face obligations of their own [16].

What Are the Practical Challenges for Operators?

Remote Assets Are the Architecture’s Blind Spot

Plymouth’s disclosure that impact was limited to cellular-connected equipment is the most operationally instructive detail released so far. Water towers, lift stations and pump stations commonly report back to supervisory control and data acquisition (SCADA) systems over cellular modems, and these secondary or alternative communication links are routinely omitted from risk and vulnerability assessments [4]. This is not a new failure mode. In the 2020 attacks on Israeli water facilities, actors linked to the Iranian government used vulnerable cellular routers as the point of entry [4]. An assessment scoped to the plant boundary will not find a modem on a tower six miles away.

The Relevant Consequence Is Not Data Loss

In MITRE ATT&CK for industrial control systems (ICS) terms, the consequences at stake are denial or loss of view, denial or loss of control, and manipulation of view or control [4]. A physical process can continue running while operators lose the ability to see or influence it. Manipulation is the more dangerous case, because the process may be in a state that differs from what the screens report — precisely the scenario AA26-097A describes when it documents altered operator display data [1][3]. Detection strategies built around data exfiltration will not register any of this.

Advisory Volume Exceeds Absorption Capacity

Four days is a short interval between an advisory update and a sector-wide incident, but the underlying advisory was nearly four months old. The constraint is not awareness. It is the engineering time to inventory controllers, establish logic baselines, remove internet exposure and rehearse manual operation — work that competes with statutory obligations for water quality, capital works and day-to-day service delivery.

Attribution Absorbs Attention That Belongs Elsewhere

Whether the Minnesota incidents prove to be Iranian-affiliated changes very little about the required response. The controls that reduce exposure to this activity are the same controls regardless of who is behind it, and waiting for attribution before acting concedes time to the adversary.

How IOActive Can Help

IOActive’s work in critical infrastructure spans the technical and strategic worlds of OT and ICS security, from the semiconductor inside a controller to the governance program around it. Our team has operated in ICS environments since building the first proof-of-concept worm against the smart grid in 2009 [20], and has helped define standards and best practices including NIST 800-53 and 800-37. The two gaps this incident exposes are assessment problems before they are tooling problems: assessment scope that stops at the plant boundary and misses remote, cellular-connected assets, and the absence of an authoritative baseline against which controller logic can be validated. The services below address each directly.

Full Stack Security Assessments

Most providers scan at the network or application layer only. Our Full Stack Security Assessments examine the entire environment, drilling down to the facility and silicon level and up through the personnel, process, and supply-chain layers around it. For a water or wastewater operator, that means scoping to the whole estate rather than the plant boundary — the towers, lift stations and pump stations that report back over cellular modems, the OT/IT boundary, and the third-party managed links that are frequently the only route in. Drawing on our hardware research background, it also extends to the firmware and silicon of PLC and human-machine interface (HMI) devices themselves through penetration testing, reverse engineering, side-channel analysis, and fault injection. It is the same class of work behind our research Compromising Industrial Facilities from 40 Miles Away, which showed how a memory-corruption flaw in widely deployed industrial wireless automation devices could be exploited remotely to disable field sensor nodes — exactly the kind of remotely reachable field connectivity that Plymouth’s disclosure points to [18].

Red Team and Purple Team Services

Manipulation of view and control is the consequence class that matters here, and it is precisely what adversarial testing exists to surface. Our Red Team engagements emulate the tradecraft AA26-097A describes, including the “living off the land” use of vendors’ own engineering software in place of exploits, while our Purple Team work translates those findings into measurable improvements in whether your operators and analysts would actually detect unauthorized logic changes in time to act. It is the tabletop in step 6 below, run against the live environment rather than a whiteboard. IOActive research has repeatedly shown how attackers can blind the humans in the loop: our study SCADA and Mobile Security in the IoT Era found that more than 20% of the vulnerabilities identified across dozens of ICS mobile applications could let an attacker misinform operators or influence the industrial process directly [19].

Supply Chain Integrity

Where control system architecture is delivered by an integrator, connectivity decisions — including secondary and backup communication paths — are frequently made outside the asset owner’s visibility, and AA26-097A documents the vendors’ own configuration software being used as the access channel. Our Supply Chain Integrity service assesses the security posture of technology providers and critical third parties, reviewing firmware, embedded systems, remote-access arrangements, and procurement processes for inherited risk before it becomes an incident vector. Under the UK Cyber Security and Resilience Bill, suppliers to regulated entities will carry obligations of their own [16].

Secure Development Lifecycle

The advisory urges device manufacturers to adopt secure-by-default design rather than leaving operators to compensate for exposed controllers [1]. For the vendors and OEMs in the PLC, remote terminal unit (RTU) and HMI supply chain, our Secure Development Lifecycle work embeds security review into design and engineering — from threat modeling through code review and pre-release testing — so that the next generation of devices does not ship with the internet-reachable defaults this campaign depends on.

Advisory Services

Removing internet exposure is an architectural program, not a one-time patch, and there is no CVE here to wait for. Our Advisory Services — spanning programmatic security review, security program development and management, and Virtual CISO support — help water sector leaders and boards turn an advisory into a prioritized remediation plan, close the gap between a warning being issued and a warning being actioned, and prepare for the reporting obligations that arrive with an incident: Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) timelines in the US, and current and forthcoming NIS duties in the UK [15][16].

  1. Establish whether any controller is reachable from the internet. This means verification against the live estate, not a review of the network diagram. Include devices reached over cellular, satellite, radio and any third-party managed link, in line with the joint NCSC-UK, CISA and FBI secure connectivity principles for OT [13].
  2. Extend assessment scope to every remote asset. Towers, lift stations, pump stations and any site with an independent communications path. Where an integrator built the connectivity, request the full inventory of links in writing.
  3. Capture an offline logic and configuration baseline for every controller. This is both a detection capability and a recovery capability. Without it, comparing running logic to known-good logic — the core of the advisory’s new detection guidance — is not possible.
  4. Apply the AA26-097A mitigations directly. Remove direct internet exposure, change default credentials on PLCs and HMIs, enforce multi-factor authentication on all remote OT access, and enable controller key switches or run/program mode protections where the platform supports them [1][3].
  5. Ingest the refreshed indicators and hunt for engineering software activity. Look specifically for vendor engineering tooling running on hosts that are not designated engineering workstations, and for connections to controllers from unexpected sources [1].
  6. Rehearse the manipulation scenario, not the outage scenario. Run a tabletop in which operator displays report normal conditions while the process deviates. The exercise should establish how staff would detect the discrepancy, what independent instrumentation exists, and how manual operation would be initiated and sustained.
  7. Verify that incident reporting obligations are understood before they are triggered. For US utilities, CIRCIA reporting timelines; for UK operators, current and forthcoming NIS obligations under the UK Cyber Security and Resilience Bill [15][16].

Conclusion

The Minnesota utilities appear to have avoided serious consequences largely because staff reverted to manual operation and contingency plans held. That is a real result, and it reflects institutional competence that deserves acknowledgment. It is also a thin margin, and it depended on operators noticing that something was wrong.

The uncomfortable element of this incident is not that it happened without warning. It is that the warning was issued, updated, distributed through federal channels and sector information sharing and analysis centers (ISACs), and reported in the trade press — and the interval between that warning and disrupted controls in more than 30 communities was four days. Advisories are only a control if the organization receiving them has the capacity to act. For much of the water sector, on both sides of the Atlantic, that capacity is the constraint that needs addressing, and it will not be resolved by another advisory.

If you would like to discuss how your organization’s controller exposure and remote-asset connectivity measure up against the activity described here, or how IOActive can support your OT/ICS resilience program, we welcome the conversation.

References

[1] CISA, FBI, NSA, EPA, DOE, CNMF and US Department of the Treasury. Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure (AA26-097A), published April 7, 2026, updated July 22, 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-097a

[2] Internet Crime Complaint Center (IC3). Advisory AA26-097A (PDF), July 22, 2026. https://www.ic3.gov/CSA/2026/260722.pdf

[3] WaterISAC. (TLP:CLEAR) CISA Updates Iranian-Affiliated PLC Targeting Advisory (AA26-097A), July 2026. https://www.waterisac.org/tlpclear-cisa-updates-iranian-affiliated-plc-targeting-advisory-aa26-097a

[4] E. Kovacs. Dozens of Minnesota Water Utilities Targeted in Coordinated OT Attacks, SecurityWeek, July 29, 2026. https://www.securityweek.com/dozens-of-minnesota-water-utilities-targeted-in-coordinated-ot-attacks/

[5] Coordinated Cyberattack Targets 30+ Minnesota Water Systems as One Plant Goes Offline, The Hacker News, July 2026. https://thehackernews.com/2026/07/coordinated-cyberattack-targets-30.html

[6] Authorities investigating a coordinated cyberattack against Minnesota water systems, Cybersecurity Dive, July 28, 2026. https://www.cybersecuritydive.com/news/authorities-investigating-a-coordinated-cyberattack-against-minnesota-water/826427/

[7] Coordinated cyberattack disrupts water utilities in 30+ Minnesota communities, StateScoop, July 28, 2026. https://statescoop.com/coordinated-cyberattack-disrupts-water-utilities-in-30-minnesota-communities/

[8] Hackers target over 30 Minnesota water utilities in coordinated OT attack, BleepingComputer, July 29, 2026. https://www.bleepingcomputer.com/news/security/hackers-target-over-30-minnesota-water-utilities-in-coordinated-ot-attack/

[9] City of Braham. Cyber security incident statements, July 2026. https://brahammn.gov/

[10] City of Plymouth. News release, July 2026. https://www.plymouthmn.gov/Home/Components/News/News/8977/542

[11] City of South St. Paul. News release, July 2026. https://www.southstpaulmn.gov/m/newsflash/Home/Detail/900

[12] City of Maple Plain. Press Release: Cyber Security Incident, July 2026. https://www.mapleplainmn.gov/administration/page/press-release-cyber-security-incident

[13] NCSC-UK, CISA, FBI and international partners. Secure Connectivity Principles for Operational Technology, January 2026. https://www.cisa.gov/news-events/news/cisa-uk-ncsc-fbi-unveil-principles-combat-cyber-risks-ot

[14] Testimony before the US Senate Committee on Environment and Public Works. The Cybersecurity State of the Water Sector, February 4, 2026. https://www.epw.senate.gov/public/_cache/files/5/3/53d93dfe-ed8c-4e48-b705-0b16cb92c90a/FA38A32EE48D7F3D4B0C069FDC08A69E6327376EB85838A03310B2E91C8582C1.02-04-2026-dr.-simonton-testimony.pdf

[15] Nossaman LLP. Water Utilities: Congress Temporarily Extends Cyber Laws, EPA Releases New Guidance, November 2025. https://www.nossaman.com/newsroom-insights-water-utilities-congress-temporarily-extends-cyber-laws-epa-releases-new-guidance

[16] House of Lords Library. Cyber Security and Resilience (Network and Information Systems) Bill: HL Bill 32 of 2026–27, June 2026. https://lordslibrary.parliament.uk/research-briefings/lln-2026-0032/

[17] ComplianceHub. CISA Updates AA26-097A: Iranian-Affiliated PLC Targeting Widens to Schneider and Siemens, July 2026. https://compliancehub.wiki/cisa-aa26-097a-update-iranian-plc-targeting-critical-infrastructure-july-2026/

[18] IOActive. Compromising Industrial Facilities from 40 Miles Away (white paper). https://www.ioactive.com/wp-content/uploads/2018/05/IOActive_Compromising_Industrial_Facilities_from_40_Miles_Away.pdf

[19] IOActive (A. Bolshev, I. Yushkevich). SCADA and Mobile Security in the IoT Era. https://www.ioactive.com/scada-and-mobile-security-in-iot-era/

[20] M. Davis, IOActive. Advanced Metering Infrastructure (Smart Grid) Device Security, Black Hat USA 2009. https://blackhat.com/presentations/bh-usa-09/MDAVIS/BHUSA09-Davis-AMI-SLIDES.pdf

INSIGHTS | August 4, 2026

Cyber Attack Trends 2026: What Security Teams Face

By IOActive
Cyber Attack Trends 2026 at the Silicon Level; Firmware, Silicon, Software Supply Chains, Industrial Control Systems.

“The most significant cyber attacks of 2026 will target the systems organizations depend on most, not the systems they monitor most closely.”

Most cybersecurity forecasts treat ransomware, AI-enabled attacks, and supply chain risks as parallel threats of equal weight; a framing that produces the wrong priorities for security teams protecting complex organizations. The cyber attack trends in 2026 share a specific characteristic: they exploit environments organizations depend on most but monitor least, from industrial control systems running legacy protocols to firmware supply chains lacking integrity verification. This article evaluates which attack patterns represent confirmed, active risk across key threat categories.

ThreatKey Risk IndicatorLevel of ConcernRecommended Assessment
Ransomware

Targeting OT and critical infrastructure		$74B global damage projected¹EscalatingRed team, OT security assessments
Software Supply Chain Attacks

Build pipelines, open-source dependencies		$80.6B cost projection by 2026²UnderestimatedSecure development lifecycle (SDL)
OT/ICS Threats

PLCs, RTUs, engineering workstations		3,300+ industrial orgs impacted³UnderdetectedOT/ICS security assessment
AI-Enabled Attacks

Dev pipelines, social engineering		31.6% of AI code fully exploitable⁴Mixed: some confirmed, some speculativeSecure code review, SDL
Critical Infrastructure Cyberattacks

Energy, water, transport, defense		$4.82M average breach cost⁵UnderreportedFull-stack ICS/OT assessment

Ransomware: From File Encryption to Operational Disruption

Ransomware groups have moved beyond encrypting files and demanding payment. The operational model has shifted toward the targeted disruption of systems that organizations cannot quickly stop or replace.

Ransomware incidents reached 6,500 in 2025, up from under 1,400 in 2020, a more than 360% increase over five years.⁶ Global damage costs are projected to reach $74 billion in 2026, a 30% increase from $57 billion in 2025.¹ For organizations in critical sectors, the average breach cost stands at $4.82 million per incident, excluding production loss and regulatory response.

Ransomware CharacteristicTraditional Model (Pre-2022)2026 ModelRecommended Assessment
Primary objectiveFile encryption, ransom demandOperational disruption plus ransomOT incident response planning
Target selectionOpportunistic, volume-basedSector-targeted, timing-awareThreat modeling
OT environment knowledgeLowActive, documented reconnaissanceOT security assessment
Recovery timelineHours to days (IT)Days to weeks (OT)OT business continuity review
Payment pressure leverThreat of data exposureExtended process downtimeRed team exercise

How Threat Groups Are Targeting OT Environments

The threat model has changed in a specific way. Groups with OT knowledge now time attacks around operational windows: peak demand periods for energy utilities, scheduled maintenance cycles at manufacturers, pre-harvest windows in agricultural processing. Dragos tracked 3,300 industrial organizations affected by ransomware in 2025.³ These are not random hits. They reflect adversaries who understand operational context well enough to maximize financial leverage.

What Separates Fast Recovery From Extended Downtime

Organizations recovering fastest from ransomware incidents are those that have run realistic OT continuity exercises against adversary scenarios. Applying untested IT recovery playbooks to industrial environments results in extended downtime because the two environments fail differently and recover on different timelines.

Software Supply Chain Attacks: The Dominant Third-Party Risk Vector

The SolarWinds compromise in 2020 demonstrated that trusted software update mechanisms could deliver malware to thousands of organizations simultaneously. The XZ Utils backdoor in 2024 showed that state-sponsored actors were willing to invest years in maintaining access to open-source projects before activating a payload. Neither incident was an outlier. Both represent a confirmed shift in how sophisticated threat actors approach access at scale.

Supply Chain Attack TypeNotable CaseDetection DifficultyDownstream ScopeRecommended Assessment
Software build tool compromiseSolarWinds (2020)High18,000+ organizationsSecure development lifecycle (SDL) review
Open-source package backdoorXZ Utils (2024)HighMillions of Linux systemsSoftware composition analysis
Firmware implantVendor hardware (multiple)Very highFull device lifecycleFirmware security assessment
AI model poisoningEmerging (2025–2026)Very highDevelopment pipelinesAI supply chain review
Hardware and silicon-level attackAMD Sinkclose (2024)⁷Extremely highEndpoint device fleetsSilicon security assessment

Third-Party Risk Is Growing Faster Than Programs Can Track

Third-party involvement in security breaches rose from 15% to 30% in 2025.² Supply chain attack costs are projected to exceed $80.6 billion by 2026.² The attack surface is not shrinking: organizations now average over 1,000 third-party vendors, and the majority lack visibility into the security posture of their software dependencies beyond first-tier vendors.

One Compromise Can Expose Every Downstream Organization

The risk is systemic, not incidental. A single compromise of a widely used build tool, package manager, or firmware update process exposes every downstream organization that relies on it. Your environment’s security now depends in part on the security of every component that touches your build pipeline, whether or not you have audited it.

OT/ICS Threats: Adversaries Mapping Physical Processes

The 2026 Dragos OT Cybersecurity Year in Review documents a specific evolution in how adversaries approach industrial environments. They are no longer staging for future disruption. They are actively mapping control loops to understand how to manipulate physical processes with precision.³

OT Threat GroupPrimary Target SectorDocumented 2025 ActivityICS Kill Chain StageRecommended Assessment
VOLTZITEElectric, oil and gasGateway compromise, configuration extractionStage 2OT network security assessment
KAMACITEEnergy, water, heating (EU, US)Four-month ICS reconnaissance campaignStage 1ICS threat hunting
ELECTRUMUkrainian, Polish infrastructureDestructive wiper deployment (PathWiper)³Stage 2OT incident response planning
SYLVANITEUS utilities, SAP environmentsZero-day exploitation (CVE-2025-31324)Stage 1Vulnerability assessment
BAUXITEIsraeli critical infrastructureDual wiper variants deployedStage 2Full-stack ICS/OT assessment

Active OT Threat Groups

Three new OT threat groups emerged in 2025. Established groups expanded operations globally. Dragos now tracks 26 OT threat groups.³ KAMACITE conducted four months of sustained reconnaissance against US internet-exposed ICS assets, targeting specific device types in sequence. VOLTZITE compromised Sierra Wireless Airlink gateways across electric and oil-and-gas sectors, then pivoted to engineering workstations to extract configuration and alarm data. ELECTRUM deployed coordinated destructive wiper malware against eight Ukrainian ISPs and, in December 2025, Polish CHP facilities.³

Why Most Organizations Cannot See the Threat

The visibility problem is structural. Only 30% of OT networks have the monitoring capability to detect these threats before operational impact. 56% of organizations cannot see below the IT/OT boundary. 88% struggle with detection and response in OT environments.³

The Integrity Blind Spot Adversaries Exploit

IOActive’s research into OT security architecture has identified a persistent strategic blind spot. The standard AIC reordering (Availability-Integrity-Confidentiality) used in many OT environments prioritizes availability, which is precisely where the most capable adversaries operate. Stuxnet manipulated centrifuge speeds while feeding false readings to operators for months. Triton/TRISIS targeted Safety Instrumented Systems to remove the safeguard layer before causing process failure. Industroyer sent commands directly to substation equipment using native industrial protocols. All three targeted integrity, not availability, because integrity failures often go undetected, whereas availability failures trigger an immediate response.⁸

AI-Enabled Attacks: Separating Confirmed Risk From Speculation

AI’s role in offensive security requires more precision than most threat briefings provide. The meaningful 2026 risk is not the speculative scenario of fully autonomous AI attackers. It is the measurable deterioration in code security caused by AI-assisted development tools, and the accelerated pace at which phishing and social engineering campaigns now operate.

AI Attack VectorOperational MaturityDocumented Risk IndicatorDefender PriorityRecommended Assessment
AI-generated insecure code in productionHigh31.6% of samples fully exploitable⁴CriticalSecure code review, SDL
AI-accelerated phishing and spear-phishingHighVolume and personalization increase confirmedHighSocial engineering assessment
Deepfake-based social engineering and fraudMedium-HighActive in financial and executive targetingHighRed team exercise
AI-assisted vulnerability discovery by threat actorsMediumBeing used by advanced groupsMediumThreat modeling
Autonomous AI attack agentsLowDemonstration cases only; no confirmed deployment at scaleMonitor onlyNo immediate action required

AI-Generated Code Is Already a Security Liability

IOActive’s April 2026 whitepaper evaluated 27 leading AI models and AI-powered coding tools using 730 real-world programming prompts across 27 languages and 219 vulnerability categories. Security outcomes were measured against 72 automated vulnerability detectors, producing nearly 20,000 analyzed code samples. The results were direct: average security performance across all models was 59%, and 31.6% of AI-generated code samples were fully exploitable.⁴

No model achieved 100% secure output. Infrastructure and DevOps code (Dockerfiles, Terraform, CI/CD pipelines) produced the worst results, with vulnerability rates between 70% and 97%. Authentication, rate limiting, and cryptography consistently failed across nearly all models.⁴ According to IOActive’s research, GitHub Copilot is now generating nearly half of developers’ code.⁴ Organizations deploying AI coding tools without mandatory security review before production deployment are introducing exploitable risk at scale as a present, documented condition.

Where AI Is Accelerating Offensive Capabilities

The WEF Global Cybersecurity Outlook 2026 found that 87% of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk over 2025.⁹ AI is accelerating phishing volume, enabling more convincing social engineering, and lowering the technical barrier for credential-based attacks.

Critical Infrastructure: The Widening Gap Between Visibility and Exposure

64% of organizations now account for geopolitically motivated cyberattacks against critical infrastructure in their 2026 risk strategies.⁹ 91% of the world’s largest organizations have changed their cybersecurity strategies due to geopolitical volatility.⁹ Awareness has grown. Technical detection coverage has not kept pace with it.

Critical Infrastructure SectorPrimary 2026 Threat VectorCurrent Avg. VisibilityRecommended Assessment
Energy (grid and generation)OT compromise, wiper malwareLow (30% avg. OT visibility³)Full-stack ICS/OT assessment
Water and wastewaterICS manipulation, ransomwareVery lowOT network segmentation review
TelecommunicationsSupply chain implants, espionageMediumHardware and firmware audit
TransportationEmbedded system attacks, GPS manipulationLowEmbedded systems assessment
Defense industrial baseHardware supply chain, insider accessVariableSilicon-level security review

Active Campaigns Against Energy Infrastructure

The December 2025 coordinated attack on Polish CHP facilities and renewable energy management systems, attributed by Dragos to Russian state-linked actors consistent with ELECTRUM, confirmed that energy infrastructure in NATO-aligned countries is an active target.³ The same month, a new destructive wiper variant from ELECTRUM confirmed an active malware development pipeline. These are not isolated incidents: they reflect sustained, organized campaigns with documented capability to disrupt physical processes.

Where Conventional Monitoring Falls Short

IOActive’s critical infrastructure research spans SATCOM terminal vulnerabilities across aviation, maritime, and military systems; avionics security in DAL-A certified systems; and industrial control assessments across energy, chemical, and defense sectors. That body of work consistently surfaces the same pattern: the most consequential vulnerabilities reside in layers below where most monitoring tools operate. Software-layer monitoring does not detect the reconnaissance and lateral movement techniques being used by the most capable OT threat groups.

For organizations in these sectors, sophisticated adversaries have both the motive and the documented capability to access environments through the layers that receive the least security scrutiny. The more urgent question is whether that access is already established.

Which of these five threat categories should security teams prioritize first?

OT/ICS threats and software supply chain attacks warrant the highest priority for organizations that have not assessed them recently, because both operate below the visibility threshold of most existing monitoring tools. Ransomware remains the highest-volume threat. AI-enabled attacks require immediate attention in development pipelines. Specifically, autonomous-AI attack scenarios do not warrant the same urgency as the confirmed, active attack patterns documented above.

How should security teams distinguish real business risk from vendor-amplified hype?

Apply two tests. First: Does the threat have documented, confirmed use in real environments, not proof-of-concept demonstrations? Second: Does it target environments your organization depends on but under-monitors? Threats that pass both tests warrant defense investment. Threats that fail the first should be tracked, but should not displace attention from attack patterns already operating at scale.

IOActive’s assessments are grounded in research spanning hardware, firmware, embedded systems, industrial control systems, and live adversarial engagements across industries. Most threat intelligence derives from network-layer telemetry. IOActive’s research includes silicon-level attack techniques, OT protocol analysis, and hardware supply chain evaluation, which is where the most consequential vulnerabilities in 2026 are concentrated. Learn more about IOActive’s Full-Stack Security Assessment approach.

Attackers Target the Layers You Are Not Watching

The cyberattack trends in 2026 share one thing in common: they target the layers that most organizations aren’t watching. IOActive’s research spans silicon, firmware, OT, and live adversarial engagements, giving security teams a complete picture of where real exposure exists and what to do about it.

Schedule a Full-Stack Security Assessment with IOActive

Sources

1. Cybersecurity Ventures, via SLCyber (2026). The True Cost of a Ransomware Attack in 2026. https://slcyber.io/blog/the-true-cost-of-a-ransomware-attack-in-2026/

2. Vectra AI / Think Ahead Tech (2025–2026). Supply chain attack cost and third-party breach data. https://www.vectra.ai/topics/supply-chain-attack; https://think-ahead.tech/en/blog/software-supplychain-security

3. Dragos. 2026 OT Cybersecurity Year in Review. https://www.dragos.com/ot-cybersecurity-year-in-review

4. IOActive. The Security Gap in AI-Generated Code (April 2026). https://www.ioactive.com/the-security-gap-in-ai-generated-code/

5. IBM. Cost of a Data Breach Report 2025, via StationX. https://app.stationx.net/articles/ransomware-statistics

6. Industrial Cyber. Hacktivists and Cybercriminals Expand Attacks on ICS, OT, and AI Systems Across Critical Infrastructure. https://industrialcyber.co/reports/hacktivists-and-cybercriminals-expand-attacks-on-ics-ot-and-ai-systems-across-critical-infrastructure/

7. IOActive. Tales from the Call Gate: AMD Sinkclose Vulnerability (2024). https://ioactive.com/tales-from-the-call-gate-an-smm-supervisor-vulnerability/

8. IOActive. Rethinking the CIA Triad in Operational Technology Environments (2026). https://www.ioactive.com/rethinking-the-cia-triad-in-operational-technology-environments/

9. World Economic Forum. Global Cybersecurity Outlook 2026 (January 2026). https://reports.weforum.org/docs/WEF_Global_Cybersecurity_Outlook_2026.pdf

EDITORIAL | August 1, 2019

Eight Steps to Improving Your Supply Chain Security Program

By John Sheehy

In this second, of a two-part blog series on the supply chain, I’ll discuss how to improve your supply chain security.

Supply chain attacks aren’t anything new, but we’re hearing more about them lately, as threat actors continue to find new ways to breach networks. In fact, the most well-known supply chain attack dates back to 2013 when Target was breached through its HVAC supplier, exposing the credit card data of 110 million customers. In the last two years, NotPetya, Trisis and the more recent Wipro compromise have served as not-so-gentle reminders that supply chain attacks are damaging, costly and present many risks to both businesses and their suppliers.

The fact is: the more secure an organization itself is, the more attractive that organization’s supply chain becomes in the mind of the attacker. An attacker wants to find the easiest pathway to get into the network so oftentimes, it’s the supplier who has an exploitable vulnerability that can get them full access into the original target’s network.

The more secure an organization itself is, the more attractive that organization’s supply chain becomes in the mind of the attacker.

Most threat actors organizations face today are very smart. They know they don’t actually need to leverage a sophisticated, complex supply chain hack to wreak havoc on a network, steal data or intellectual property, or cause catastrophic damage. All they really need to do is look for unpatched servers and systems or send out a simple phishing email. Just look at the recent Wipro breach where dozens of employees’ emails were compromised through a phishing scam that gave the threat actors access to over 100 Wipro computer systems to mount attacks on a dozen Wipro customers.

Phishing and the use of stolen credentials are repeat offenders that keep coming up over and over again. In fact, the 2019 Verizon Data Breach Investigations Report cited that 32 percent of the breaches involved phishing scams and 29 percent involved the use of stolen credentials.

An unsophisticated cyberattack often yields a better outcome for an attacker — saving them time, money and resources while making attribution more difficult, so it’s in their best interest to take the easier path to their goal. We’ve seen many successful breaches where attackers penetrated systems through hardcoded credentials or just poorly patched systems.

That’s why, if you’re not protecting your own network against basic threat actors, doing your due diligence to properly patch, and holding your suppliers accountable for securing their own networks, you have no hope in protecting against nation-states or more capable threat actors. This is where third-party testing comes in handy to trust and verify your suppliers.

Here are a few key steps you can take today to build a supply chain security program:

  1. Know your suppliers and look upstream as well as downstream. Start with your tier-one suppliers and then identify tier twos and others. Take a full inventory of who you do business with so you can identify any weak links.
  2. Conduct a risk assessment. Once you’ve identified all your partners, you need to properly assess each one’s cybersecurity posture so you know the risks they may pose to your organization. You must consider where each device or component was built and who exactly built it. Is there a possible backdoor or counterfeit part? Or is it just the more likely software quality issues that can result in a breach?
  3. Utilize third-party testing. Hire a third-party firm to test your system, and that of your suppliers, to provide actionable results on what you need to fix first.
  4. Regularly scan and patch all vulnerable systems.
  5. Use strong passwords. Teach your employees about the importance of using strong passwords and not recycling them across accounts.
  6. Ensure your staff has set up multi-factor authentication everywhere possible.
  7. Conduct regular security awareness training to teach employees how to identify phishing scams, update software and become more security-conscious.
  8. Harden the security of the devices connected to your networks.

Make sure you’re not worrying about low-likelihood events like supply chain attacks if you’re not doing the basics of foundational security at your own organization. It’s really quite simple: you need to crawl before you walk, and walk before you run.