INSIGHTS, RESEARCH | November 12, 2026

Fifteen Years of Exposure: What Supermarket Refrigeration Attacks Reveal About Industrial Cybersecurity

By Colin Cassidy

Key Takeaways

Cyberattacks against supermarket refrigeration systems across Europe in October and November 2026 demonstrate how the compromise of internet-connected operational technology (OT) can result in physical disruption and significant financial losses.
Internet-exposed industrial control systems are not a new problem. Research published in 2011 and the subsequent Project SHINE initiative identified widespread exposure of industrial equipment more than a decade ago.
Removing direct internet exposure through firewalls and secure remote access is an important mitigation, but does not eliminate the underlying security risks.
The December 2025 attacks against Polish renewable energy facilities demonstrate the limitations of perimeter security when firewalls are themselves inadequately secured and industrial equipment remains vulnerable.
Effective OT cybersecurity requires a combination of asset visibility, secure configuration, vulnerability management, network segmentation and ongoing assessment of both perimeter and internal systems.

A New Target, a Familiar Problem

During October and early November 2026, a series of cyberattacks targeted commercial refrigeration systems across Europe, affecting supermarkets and other food retailers. [7]

The initial incidents in France reportedly affected approximately 700 supermarkets. Subsequent attacks were reported in several European countries, including Ireland, Sweden, Belgium and the United Kingdom.

In these incidents, attackers gained unauthorised access to refrigeration management systems and manipulated operating parameters, including temperature setpoints and defrost functions. Some retailers reported refrigeration temperatures reaching 50°C, resulting in food spoilage, operational disruption and significant financial losses.

Although the investigation into these incidents remains ongoing, the attacks have drawn attention to the security of internet-connected refrigeration management equipment.

Modern commercial refrigeration systems commonly incorporate centralised management capabilities, allowing operators and maintenance providers to monitor temperatures, configure operating parameters, manage alarms and diagnose faults remotely.

These capabilities deliver tangible operational benefits, particularly for retailers managing large numbers of refrigeration units across geographically distributed locations.

However, they also introduce cybersecurity risks when management interfaces are exposed directly to the Internet or protected by inadequate security controls.

Security researchers have previously identified vulnerabilities in refrigeration management systems, including authentication bypass and command injection vulnerabilities affecting Danfoss AK-SM 800A controllers. [3]

While manufacturers have released updates addressing identified vulnerabilities, internet-wide research continues to identify exposed systems running outdated firmware.

The recent attacks illustrate an important distinction between conventional IT security incidents and attacks against OT.

The attacker does not necessarily need to compromise the physical equipment or exploit vulnerabilities in its underlying control logic.

Access to legitimate management functionality may be sufficient to manipulate the physical process and cause operational disruption.

More significantly, the underlying security weaknesses are not new.

Industrial Internet Exposure: A Problem Documented Since 2011

In June 2011, Eireann Leverett published Quantitatively Assessing and Visualising Industrial System Attack Surfaces, research examining the exposure of industrial control systems to the public Internet. [1]

Using historical data collected through Shodan, the research identified more than 7,500 internet-accessible industrial devices, including building management systems, HVAC controllers, meters and SCADA systems.

The research demonstrated that industrial equipment, often assumed to be isolated from external networks, was accessible through publicly routable internet connections.

It also explored the correlation between exposed devices, identifiable software and publicly documented vulnerabilities.

The objective was not simply to identify exposed systems, but to provide organisations with better visibility of their external attack surfaces and support the prioritisation of security improvements.

This work anticipated a challenge that continues to affect industrial cybersecurity: organisations cannot effectively protect systems they do not know are exposed.

The following year, Project SHINE (SHodan INtelligence Extraction), established by Rob Radvanovsky and Jake Brodsky, expanded this research. [2]

Project SHINE used Shodan to identify and catalogue internet-accessible industrial control systems. By the conclusion of its data collection in January 2014, the project had identified more than two million unique IP addresses associated with potentially relevant industrial equipment.

These figures require careful interpretation. An internet-accessible system is not necessarily vulnerable, and search-engine results do not provide a reliable measure of the total number of individual industrial devices.

Nevertheless, the research established that internet exposure was a widespread issue affecting multiple industrial sectors.

More than a decade later, the circumstances surrounding the supermarket refrigeration attacks suggest that many of the same challenges remain unresolved.

Industrial connectivity has expanded considerably, driven by remote maintenance requirements, centralised monitoring, operational efficiency and the increasing integration of IT and OT environments.

However, increased connectivity has not always been accompanied by equivalent improvements in cybersecurity governance, asset management or vulnerability remediation.

The result is an expanding population of connected industrial devices whose security may depend on outdated software, insecure configurations or insufficiently controlled remote access.

The Obvious Response: Secure the Network Perimeter

The immediate recommendation for organisations operating internet-exposed industrial equipment is straightforward: remove unnecessary direct access from public networks.

Industrial controllers, management interfaces and engineering services should not normally be directly accessible from the Internet.

Where remote access is operationally necessary, organisations should implement appropriately configured security controls, including firewalls, network segmentation and secure remote access mechanisms.

These measures can significantly reduce the attack surface by limiting the systems and services available to an external attacker.

However, a firewall should not be considered the endpoint of an organisation’s industrial cybersecurity strategy.

A firewall is itself a network-connected computing platform, potentially incorporating an operating system, web-based management interface, VPN services and other externally accessible functionality.

Like other software-based systems, it requires secure configuration, vulnerability management, authentication controls and ongoing maintenance.

Furthermore, while a firewall can restrict access to an industrial network, it does not automatically address vulnerabilities in the devices operating within that network.

Once an attacker obtains authorised or unauthorised access through the perimeter, weaknesses such as default credentials, insecure services and outdated firmware may remain exploitable.

The consequences of these overlapping weaknesses were demonstrated in the December 2025 attacks against Polish energy infrastructure.

Poland’s Renewable Energy Attacks: When the Perimeter Becomes the Attack Surface

On 29 December 2025, coordinated cyberattacks targeted multiple organisations within Poland’s energy and manufacturing sectors. [4]

According to a detailed technical report published by CERT Polska on 30 January 2026, the attacks affected at least 30 wind and photovoltaic installations, a combined heat and power plant, and a manufacturing organisation. [5]

At the renewable energy facilities, the attackers targeted grid connection points (GCPs), which provide the interface between generating facilities and electricity distribution networks.

These locations typically contain industrial automation equipment, including remote terminal units (RTUs), human-machine interfaces (HMIs), protection relays and communications infrastructure.

The attackers damaged multiple industrial devices, resulting in the loss of communications between affected facilities and their distribution system operators.

Although electricity generation continued and the attacks did not affect the stability of Poland’s electricity system, CERT Polska assessed that the attackers had obtained sufficient access to potentially disrupt generation at the affected facilities.

The incident provides a valuable case study in the limitations of relying primarily on perimeter security.

The Firewalls Were Present

CERT Polska reported that every affected renewable energy facility had a FortiGate appliance operating as both a firewall and VPN concentrator.

These systems were intended to provide controlled remote connectivity while protecting the internal industrial networks.

However, investigators identified several weaknesses in their deployment and maintenance.

All affected installations had internet-accessible VPN interfaces that permitted authentication without multifactor authentication.

Furthermore, some appliances had previously remained vulnerable to serious security flaws, including remote code execution vulnerabilities, for extended periods.

The report also highlighted the potential risks associated with reusing administrative credentials across multiple facilities.

Importantly, CERT Polska could not conclusively determine the initial compromise mechanism.

The attackers factory-reset the compromised FortiGate appliances, destroying logs and other information that could have established precisely how access was obtained.

Consequently, it would be inaccurate to conclude that exploitation of an unpatched FortiGate vulnerability was definitively responsible for the initial compromise.

Nevertheless, the investigation established that the attackers had obtained administrative access to the security appliances.

This access significantly undermined the protection offered by the network perimeter.

Segmentation Depends on the Security of Its Enforcement Points

Some of the affected facilities implemented network segmentation through separate VLANs.

While segmentation is an important industrial security control, its effectiveness depends on the integrity of the systems enforcing communication restrictions between network segments.

CERT Polska reported that the attackers possessed administrative privileges on the FortiGate devices and could therefore potentially access credentials permitting connectivity to multiple network segments or modify the firewall configuration to establish equivalent access.

In this situation, compromising the perimeter device created opportunities to bypass or undermine the network boundaries it was responsible for enforcing.

This illustrates a broader challenge associated with consolidating security functionality within a single appliance.

Where remote access, firewall enforcement and inter-network routing are managed by the same device, its compromise may have consequences across multiple security functions.

Organisations must therefore assess the security of network enforcement points with the same rigour applied to the industrial systems they protect.

Vulnerabilities Behind the Firewall

The Polish investigation also demonstrated that successful perimeter compromise was only one component of the attack.

After accessing the industrial networks, the attackers exploited insecure configurations and weak authentication controls across several types of industrial equipment.

CERT Polska documented multiple examples:

Hitachi RTU560 controllers: The attackers used default credentials to access controller management interfaces and upload deliberately corrupted firmware. This caused the affected devices to enter repeated reboot cycles, disrupting communication and remote control capabilities.

The investigation also found that secure firmware verification functionality, available on some affected devices, had not been enabled. Separately, some firmware versions were affected by CVE-2024-2617, a vulnerability capable of bypassing firmware verification.

Mikronika RTUs: Default root credentials enabled access to Linux-based controllers through SSH. The attackers subsequently executed destructive commands against the devices’ filesystems.

Hitachi Relion protection relays: Default FTP credentials permitted access to system files, which the attackers deleted. CERT Polska noted that following the manufacturer’s recommended deployment configuration would have disabled these accounts.

Moxa NPort serial device servers: Default credentials allowed attackers to modify device configurations, perform factory resets and assign unusable network addresses.

Windows-based HMIs: Common administrative passwords enabled the compromise of several HMI systems and the deployment of destructive malware.

One particularly revealing observation concerned facilities that did not use the same administrator passwords.

Where unique credentials had been configured, the attackers’ password-breaking attempts were unsuccessful, and the corresponding HMI systems were not damaged.

This provides a practical demonstration of the effectiveness of fundamental security controls.

Even during a coordinated, destructive attack against industrial infrastructure, relatively straightforward measures such as eliminating default credentials and implementing unique administrative passwords were sufficient to prevent some of the observed compromises.

The incident demonstrates two distinct but related risks.

First, an inadequately secured perimeter appliance can become an effective entry point into an otherwise segmented industrial network. Second, vulnerabilities and insecure configurations within that network remain significant risks regardless of the presence of perimeter security.

Protecting the network boundary is necessary, but it does not remove the requirement to secure the systems operating behind it.

Similar Weaknesses Identified During Wind Farm Security Assessments

The security weaknesses documented by CERT Polska are consistent with issues identified during real-world industrial cybersecurity assessments.

Research presented in ACME Windpharm – It Can’t Be ‘Smart’ If You Lack Simple Security explored vulnerabilities identified during wind farm security assessments, including insecurely configured network equipment, inadequate patching and excessive reliance on perimeter security appliances. [6]

The assessments highlighted the risks associated with deploying sophisticated security technologies without maintaining fundamental security practices.

Industrial networks may incorporate dedicated firewalls, managed switches and remote access infrastructure, yet still contain devices running vulnerable firmware or configured with insecure management services.

Similarly, security appliances may be deployed to protect critical systems without sufficient consideration of their own vulnerability exposure or ongoing maintenance requirements.

These weaknesses are particularly significant in distributed renewable energy environments.

Wind and solar installations commonly rely on remote communications infrastructure for monitoring, maintenance and interaction with distribution network operators.

Individual facilities may be geographically isolated, unmanned and maintained by multiple suppliers or service providers.

This introduces additional challenges around asset ownership, vulnerability management, access control and the consistent application of security requirements.

The Polish incidents demonstrate how these weaknesses can be combined during a real-world attack.

An attacker who compromises remote access infrastructure may subsequently exploit weaknesses in industrial controllers, communications devices and management systems.

Importantly, the vulnerabilities required for such attacks are not necessarily sophisticated or previously unknown.

Many arise from insecure deployment practices, missing security updates and inadequate access controls.

Moving Beyond Perimeter Security

The lessons from the refrigeration incidents and Polish energy attacks are relevant to organisations operating connected industrial systems across multiple sectors.

Effective protection requires a defence-in-depth approach that addresses both external exposure and internal security weaknesses.

1. Establish Visibility of Internet-Accessible Assets

Organisations need an accurate understanding of which industrial systems and management services are accessible from external networks.

This should include equipment installed or maintained by third parties, remote maintenance connections, cellular routers and other communications infrastructure that may not be managed by central IT teams.

External attack surface assessments can help identify undocumented or unintended exposure.

Importantly, this should be an ongoing activity rather than a one-time exercise.

2. Secure Remote Access Infrastructure

Firewalls, VPN concentrators and other remote access technologies should be managed as security-critical assets.

Controls should include:

Timely security updates and vulnerability remediation.
Multifactor authentication for remote access.
Restricted management interfaces and administrative privileges.
Unique credentials across sites and systems.
Network access limited to specific operational requirements.
Centralised logging and monitoring, with records protected from deletion following appliance compromise.

Where feasible, remote maintenance access should be restricted to authorised users and activated only when operationally required.

3. Assess Security Beyond the Perimeter

Network segmentation reduces exposure but does not eliminate vulnerabilities within protected environments.

Organisations should assess industrial controllers, HMIs, engineering workstations, communications devices and other operational assets for insecure configurations and known vulnerabilities.

Particular attention should be given to default credentials, unnecessary services, outdated firmware and insecure management protocols.

Security assessments should also examine whether compromise of a remote access service would provide excessive access to otherwise separated systems.

4. Implement Risk-Based Vulnerability Management

Patching industrial systems presents operational challenges that differ from those encountered in conventional IT environments.

Updates may require testing, planned maintenance windows or coordination with equipment manufacturers.

Some industrial products may have limited support lifecycles or dependencies that prevent immediate remediation.

However, these constraints reinforce the need for structured vulnerability management rather than removing it.

Where vulnerabilities cannot be promptly remediated, organisations should implement appropriate compensating controls, document residual risks and establish clear ownership of the remediation process.

5. Validate Recovery and Operational Resilience

The Polish attacks demonstrate that attackers may deliberately destroy device configurations, firmware and local system data to complicate recovery.

Industrial incident response planning should therefore consider more than restoring conventional IT services.

Organisations should maintain protected backups of device configurations and firmware, verify their restoration procedures, and establish how critical industrial processes can be operated or recovered when remote management infrastructure is unavailable.

For refrigeration environments, additional consideration should be given to independent temperature monitoring, alarm systems and operational safeguards capable of detecting or limiting unauthorised changes to control parameters.

The objective is not only to prevent compromise, but also to reduce its potential physical consequences.

The Continuing Challenge of Industrial Cybersecurity

The recent supermarket refrigeration attacks illustrate how increasingly connected industrial systems can expose organisations to operational and financial risks.

However, the underlying security challenges have been understood for more than fifteen years.

Research in 2011 demonstrated that industrial equipment was accessible from the public Internet.

Project SHINE subsequently highlighted the scale of industrial internet exposure.

More recent industrial security assessments have continued to identify weaknesses involving vulnerable network appliances, insecure configurations and inadequate access controls.

The December 2025 attacks against Polish renewable energy infrastructure demonstrated the consequences when attackers successfully exploit combinations of these weaknesses.

The common theme is not simply that industrial devices are connected to the Internet.

Remote connectivity is often an essential operational requirement.

Rather, it is that connectivity must be accompanied by security controls appropriate to the criticality and operational characteristics of the systems involved.

Installing a firewall can significantly reduce exposure, but the firewall must itself be secured, and the systems behind it must not be assumed secure simply because external access is restricted.

The most effective approach combines asset visibility, secure remote access, vulnerability management, network segmentation, system hardening and validated recovery capabilities.

Fifteen years after researchers first demonstrated the scale of internet-exposed industrial infrastructure, the challenge is no longer establishing that the problem exists.

It is ensuring that organisations consistently implement and maintain the controls needed to address it.

References

[1] Eireann Leverett, Quantitatively Assessing and Visualising Industrial System Attack Surfaces, University of Cambridge, June 2011. https://www.cl.cam.ac.uk/~fms27/papers/2011-Leverett-industrial.pdf

[2] Project SHINE, Findings Report, Infracritical, 2014. https://infracritical.com/p/project-shine-findings-report-1oct2014.pdf

[3] Claroty Team82, Freeze the Controller, Defrost the Food: Uncovering Vulnerabilities in Danfoss Refrigeration Controllers, August 2026. https://claroty.com/team82/research/freeze-the-controller-defrost-the-food-uncovering-vulnerabilities-in-danfoss-refrigeration-controllers

[4] John O’Mahoney – IOActive Inc, Lessons from the Polish Energy Sector Incident, July 2026. https://www.ioactive.com/lessons-from-the-polish-energy-sector-incident/

[5] CERT Polska, Energy Sector Incident Report – 29 December 2025, published 30 January 2026. https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf

[6] CS3STHLM, ACME Windpharm – It Can’t Be ‘Smart’ If You Lack Simple Security, presentation by Colin Cassidy. https://4sics.se/program/presentations/colin-cassidy/

[7] Reuters, Associated Press and RTÉ, reporting on European supermarket refrigeration cyberattacks, October–November 2026. https://www.reuters.com/business/retail-consumer/temperature-soars-swedish-grocery-store-freezers-one-store-blames-hackers-2026-11-02/

INSIGHTS, RESEARCH | November 10, 2026

Two Oracles to Get One Key: A tale of recovering a symmetric key from an encrypt-only firmware update scheme

By Gabriel Gonzalez

Can an RSA public key be recovered if it’s never published? Yes, if the system leaks whether a submitted value exceeds the modulus. That yes/no signal allows a binary search that recovers the modulus in roughly one query per key bit, and with the standard exponent of 65537, the full public key follows.

Why does recovering the public key matter? It enables a Bleichenbacher padding oracle attack against PKCS#1 v1.5, which here recovered the AES key used to encrypt the firmware.

One of the most satisfying moments in vulnerability research is when you find a way around a show-stopper and manage to fully compromise a system. This post covers a specific situation I was investigating a few years ago: a device so well-secured that its only remaining remote attack vector was the firmware update mechanism. Yet within hours, I’d recovered the full AES key the system relied on. What follows is the technique I used to do it.

It was a kind of “weird” setup. The system shipped its firmware as an encrypted binary blob. Specifically, an RSA hybrid (envelope) encrypted blob that combined an AES-encrypted payload with the corresponding AES key encrypted via public-key crypto. It carried the magic Salted__, so I knew OpenSSL was being used somewhere in the toolchain.

The manufacturer had chosen to use public/private key cryptography in an unusual way: the private key was kept inside the device, and the public key was never published, they kept it to themselves. I guess they’d probably thought this design was secure because it behaves like one that has two secret keys: one to encrypt the AES key, and the other to decrypt it.

In practice, however, the system leaked some errors through its update API, which let me discover the padding it used. I was pretty happy to see that padding was PKCS#1 v1.5, the mode that is vulnerable to a padding oracle attack. The only problem: to actually mount that attack, you need the public key. Why? Because it holds both the exponent and the modulus, which are necessary to carry out the right calculations while mounting the padding attack. Except in this case, the public key was never published.

After submitting multiple modifications of the encrypted firmware looking for edge cases, I noticed the system returned a different error when I submitted some specific malformed messages. Reproducing a similar setup offline, I worked out that it was complaining about the submitted data being too large for the modulus. But wait, what does that actually mean?

The modulus, and why it matters

An RSA public key is really just two integers, written (n, e). The exponent e is almost always 65537 (0x10001), it’s OpenSSL’s default and is also, for practical purposes, fixed. The modulus n is the product of two secret primes, n = p · q, and its bit length is the key size. Encryption itself is a single modular exponentiation:

c = m^e mod n          # m = padded message, c = ciphertext

Because every operation is reduced modulo n, OpenSSL first checks that the number you submit is smaller than n. Anything equal to or larger than the modulus cannot be a valid RSA block, so it is rejected before the private-key operation with a specific error data too large for modulus error. In other words, for any value c I chose, the endpoint was telling me whether c >= n: a yes/no comparison against the one number the vendor was trying to keep secret.

Using this oracle on the update API, I came up with a simple method to recover the modulus of the key pair. And since the exponent that OpenSSL uses is known, solving for n meant I could fully reconstruct the public key.

Recovering the modulus with a binary search

The key observation is that the comparation “is c >= n?” is false for every value below the modulus, and true for everything at or above it. Therefore, the smallest value the oracle calls “too large” is the modulus itself. Using an implementation similar to the below pseudocode, I started quering the oracle with values. If the system returned an error, I would move to the lower half. If it passed the filter, I’d move to the upper half, get the middle value, and then query again. I did this until I could narrow it down to the exact byte that would return an error but the same value minus 1 would pass the filter.

lo = 2**(bits-1)          # a real modulus has its top bit set
hi = 2**bits - 1
while hi - lo > 1:
    mid = (lo + hi) / 2
    if too_large(mid):    # oracle: is mid >= n ?
        hi = mid
    else:
        lo = mid
n = hi                    # the smallest 'too large' value is n itself

Figure 1. Aa binary search over the k-bit range converges on n in about k queries, one per bit.

Figure 2. Flow Diagram of the queries used to recover the actual modulus. The flow begins with the most significant byte and then moves to the next one, continuing until we have fully recovered the modulus.

The second oracle: Bleichenbacher on the padding

In the final step, we’re essentially turning the padding check into a second oracle. You submit chosen multiples of the captured ciphertext, and for each one, the endpoint tells you whether the decrypted block begins with the valid 00 02 header of a well-formed v1.5 block. Every “valid” answer confines the unknown plaintext to a narrower numeric interval; iterating the construction shrinks that interval, multiple by multiple, until a single value is left.

Note that this attack doesn’t reveal the actual private key but the plaintext it’s trying to protect. In this specific scheme, the RSA block actually wraps the AES firmware key itself. So, the plaintext Bleichenbacher recovers is not some intermediate secret, it’s the exact symmetric key I’d been after from the start.

I did not reinvent the wheel here: I simply followed Dennis Yurichev’s clear reference write-up of the attack, then adapted my implementation to match this device’s padding oracle error.

INSIGHTS | November 5, 2026

Cybersecurity Trends 2027: Risks Reshaping Security

By Christian Powills

Key Takeaways

AI will expand security exposure through speed, scale, data access, and automated action. Its use requires clear operating boundaries.
Connected technologies will extend enterprise exposure through IoT, IIoT, OT, edge systems, cellular modems, and supplier-managed access.
Critical infrastructure security will be measured through continuity, safety, recovery time, and the ability to maintain trusted operations.
Offensive security will test whether controls perform across realistic attack paths, detection events, response decisions, and recovery actions.
Supply chain risk will require evidence across software, hardware, firmware, data, cloud services, and specialist providers.

Five shifts will define cybersecurity trends 2027: bounded AI, connected technologies, critical infrastructure exposure, offensive validation, and supply chain risk. Recent CISA alerts put those shifts in operational terms. In July 2026, CISA warned that threat actors were targeting internet-exposed programmable logic controllers in water systems. In August, a related advisory described actors using AI-generated exploitation scripts against exposed PLCs.

These incidents show why 2027 planning must connect emerging technology to evidence about real-world exposure. A joint Five Eyes statement warns that frontier AI is changing cyber risk on a timeline measured in months, not years. The following sections examine the five shifts most likely to affect enterprise exposure and the planning questions security leaders should use for 2027.

Cybersecurity Trends 2027 Risk Map

Trend	Where exposure is moving	Planning changes for 2027	Priority validation question
Bounded AI	Models, agents, data, tool access, and deployment pipelines	Define permitted actions, data boundaries, human review, and rollback paths	Can the system fail safely when inputs, permissions, or model behavior change?
Connected technologies	IoT, IIoT, OT, edge systems, cellular modems, and supplier-managed access	Maintain an accurate external exposure register and secure remote access	Which assets are reachable, who can reach them, and what can they change?
Critical infrastructure	Operational systems with safety, uptime, and public-service consequences	Link cyber risk to continuity plans, engineering constraints, and recovery time	What is the operational consequence of compromise, lost visibility, or lockout?
Offensive security	Identity, cloud, endpoints, applications, physical access, and response processes	Test realistic attack paths, detection, response, and recovery	Can defenders contain an intrusion before it reaches a critical business process?
Supply chain risk	Open-source software, firmware, silicon, cloud services, integrators, and data	Demand evidence across suppliers and lifecycle stages	Which dependency could change the trust boundary without internal approval?

This is a categorized risk map, not a ranked list. Its purpose is to show where enterprise exposure is moving and which validation question belongs to each trend. The first priority is AI, where adoption speed can exceed assurance.

Cybersecurity Trends 2027 Start With Bounded AI

AI will remain central to the cybersecurity trends shaping 2027. The useful question is where AI can act, what it can access, how its output is verified, and how quickly a human or system can stop it.

The World Economic Forum’s Global Cybersecurity Outlook 2026 found that 87% of respondents viewed AI-related vulnerabilities as the fastest-growing cyber risk during 2025. The report also found that 64% of organizations had a process to assess AI tools before deployment. Those figures point to a control gap between adoption and assurance. In 2027, that gap is likely to matter more as organizations connect AI to sensitive data, business workflows, and automated actions.

For 2027, AI security should be governed as an engineering discipline. Security teams need threat models for model inputs, training data, retrieval sources, plugins, APIs, identities, and automated actions. They also need operational tests for degraded performance, malicious instructions, data leakage, and unsafe tool use.

AI security lens: the 2027 shift

Authority: By 2027, define which actions require human approval and which actions can run automatically.
Data: By 2027, map sensitive data into prompts, context windows, training sets, logs, and model outputs.
Recovery: By 2027, maintain a tested rollback path for model, prompt, policy, and integration changes.

By 2027, bounded AI should distinguish durable security controls from product hype. Teams that can define authority, data boundaries, and recovery paths will be better positioned to deploy AI without turning speed into unmanaged exposure. That shift creates a bridge to the next priority: connected technologies and the paths they create into enterprise operations.

Connected Technologies Will Turn Asset Visibility Into Resilience

The attack surface in 2027 will extend to systems that many enterprise security teams do not directly own. Cellular modems, engineering workstations, cloud control planes, embedded devices, smart facilities, and supplier-managed connections can provide entry points to high-consequence environments.

CISA’s Internet Exposure Reduction Guidance states that internet-accessible IT, IIoT, SCADA, ICS, and remote access technologies continue to grow. The guidance recommends identifying accessible systems, removing unnecessary exposure, securing necessary remote access, and reviewing exposure on a routine basis.

The broader lesson applies across industries. Asset inventories need ownership, reachability, software and firmware status, remote-access paths, and operational consequences. A vulnerability register without exposure context will struggle to rank the paths that matter most.

Connected technology lens: the 2027 shift

Reachability: By 2027, identify every internet-facing asset, remote-access method, and supplier-managed connection.
Change authority: By 2027, record who can alter configuration, credentials, logic, firmware, or network paths.
Consequence: By 2027, map each asset to safety, uptime, revenue, regulatory, and recovery requirements.

By 2027, exposure management will need to move from periodic discovery to a continuous view of how technology connects to operations. That means tracking reachability, change authority, and consequence as conditions change—not only when an inventory is refreshed.

Critical Infrastructure Risk Will Be Measured in Operational Consequence

Critical infrastructure operators carry security requirements that extend beyond data protection. A compromised system can affect safety, public services, production, environmental controls, or the ability to operate manually during recovery.

CISA’s July 2026 alert reported that threat actors targeting exposed PLCs had modified passwords, changed IP addresses, and caused loss of monitoring and control functionality. The alert also warned that exposed OT assets can create risks involving operational disruption and physical damage. That pattern is expected to remain relevant in 2027 as exposed OT assets, remote access, and internet-connected control systems continue to create paths into operational environments.

For 2027, security planning should connect technical controls to engineering constraints and recovery time. Leaders need to know which systems can be isolated, which processes can run manually, which backups are trusted, and which suppliers can restore affected equipment.

Critical infrastructure lens

Continuity: Identify the essential process that must continue during a cyber incident.
Safety: Map how loss of control, visibility, or configuration integrity could affect people and equipment.
Recovery: Test restoration procedures against actual dependencies, access requirements, and operating conditions.

This perspective gives critical infrastructure risk a measurable business context. It also creates the basis for offensive testing that reflects real operational pressure.

Offensive Security Will Test Control Performance

Security programs increasingly need evidence that controls work under pressure. A tool deployment, policy document, or completed assessment provides limited assurance when teams have not tested a realistic attack sequence.

For 2027, mature programs will connect threat intelligence to threat emulation. The shift is from periodic, point-in-time testing to scenario-based validation of identity compromise, cloud privilege escalation, lateral movement, data access, physical entry, and recovery decisions in environments that reflect the organization’s technology and operating model.

Red and purple team exercises can reveal detection gaps, response delays, authority problems, and process constraints. In 2027, those exercises will need to connect more directly to business-critical outcomes, while penetration testing continues to examine technical weaknesses across applications, infrastructure, cloud, mobile, and embedded systems.

Offensive security lens: the 2027 shift

Path: Can an attacker move from an exposed service to a critical business process?
Signal: Which attacker actions create useful telemetry, and how long does triage take?
Decision: Who can isolate systems, suspend access, or accept operational impact during an incident?

By 2027, security testing should function as a management instrument, producing evidence for investment, prioritization, and risk acceptance—not simply a list of technical findings.

Supply Chain Risk Will Reach Below the Application Layer

Supply chain risk will continue to expand across software, hardware, firmware, cloud services, data, and specialist providers. The World Economic Forum’s 2026 report identifies supply chain opacity and concentration as core forces shaping cyber resilience.

For 2027, third-party risk programs will need to examine how dependencies are built, updated, configured, and retired. That includes open-source packages, CI/CD runners, model repositories, semiconductor components, device firmware, managed service accounts, and the people who maintain them.

The practical test is traceability. Security leaders should know which dependencies support critical processes, which parties can change them, what evidence supports their security, and how the organization will operate if a dependency becomes unavailable or untrustworthy.

Supply chain risk lens: the 2027 shift

Provenance: Can the organization verify where software, firmware, data, and components originated?
Privilege: Which suppliers, integrators, and service accounts can change production systems?
Continuity: What is the tested fallback if a provider is compromised, unavailable, or subject to geopolitical disruption?

By 2027, supply chain programs will need to move beyond point-in-time reviews toward evidence of provenance, privilege, and continuity across the dependency lifecycle. The resulting program connects procurement, architecture, engineering, incident response, and executive risk decisions.

What Security Leaders Should Prepare for in 2027

A strong 2027 security strategy will be built around validation. Set a short list of high-consequence scenarios, then test the assumptions behind them. Confirm that teams can see the relevant activity, make decisions quickly, and recover without relying on undocumented expertise.

2027 readiness check

Evidence: Can leaders see proof that priority controls work under realistic conditions?
Exposure: Can teams identify reachable assets, trust paths, and high-consequence dependencies?
Consequence: Can the organization contain disruption and recover within its operational limits?

How IOActive Can Help Prepare for 2027

IOActive’s analysis of the Five Eyes cyber risk statement identifies practical actions for organizations looking to minimize risk in 2027: reduce attack surface, accelerate patching, address legacy systems, strengthen identity and access controls, and prepare for incidents.

A research-led security partner can extend that work across AI, software, hardware, connected technologies, and critical infrastructure. IOActive’s AI/ML Security Services assess AI systems across architecture, code, applications, devices, and infrastructure. Its Red Team and Purple Team Services examine realistic attack paths and defensive response. Its penetration testing practice applies attacker perspective across cloud, mobile, embedded, infrastructure, and web services.

Build 2027 priorities around evidence, exposure, and operational consequence. To discuss an independent assessment of emerging risk, contact IOActive’s security experts and turn cybersecurity trends 2027 into a testable security plan.

Sources

INSIGHTS | November 2, 2026

Cybersecurity Assessment Methodology

By Christian Powills

“Cybersecurity assessment providers should be compared by the depth and relevance of their testing, not simply by the number of assessments they offer.” – IOActive Security Team

Not all security assessments are built the same, and neither are the providers that deliver them. For enterprise security teams evaluating external partners, it’s essential to examine each partners’ cybersecurity assessment methodology: what gets tested, how it is tested, and whether the approach reflects how real attackers actually operate. This piece covers the major assessment types available to enterprise organizations, the criteria that separate higher-capability providers from lower ones, and a structured framework for matching your environment to the right approach.

Types of Cybersecurity Assessments

Not every organization needs the same type of assessment. Understanding what each engagement involves, including what to look for in a provider’s approach to executing it, is the first step in evaluating whether a firm’s methodology fits your actual security needs.

Cybersecurity Assessment Types

Assessment Type	Primary Purpose	Best Fit For
Penetration Testing	Identify and exploit vulnerabilities within a defined scope	Compliance mandates, foundational control validation
Red Team Exercises	Simulate targeted adversaries pursuing real objectives	Organizations with mature controls and an active SOC
Full-Stack Assessments	Test the entire technology stack from silicon to cloud	Complex, multi-layer enterprise environments
AI Security Assessments	Target AI/ML-specific attack surfaces and infrastructure	Organizations integrating AI into critical systems
Product and Hardware Testing	Assess physical devices, firmware, and silicon	Device manufacturers, IoT and OT deployments
Code Review and Reverse Engineering	Surface vulnerabilities at source-code and binary levels	Software development lifecycle, acquired or legacy code
Critical Infrastructure / OT Testing	Assess ICS/SCADA and OT environments safely	Energy, utilities, manufacturing, industrial sectors
Purple Team Exercises	Collaborative red/blue testing for detection improvement	Teams ready to operationalize red team findings

The sections below define each assessment type and explain what to look for in a provider’s methodology when executing each one.

Penetration Testing

What it is: A time-boxed, authorized engagement in which ethical hackers identify and exploit vulnerabilities across a defined set of systems, applications, or networks.

What it does: Finds exploitable weaknesses, demonstrates real-world impact, and delivers remediation guidance tied to specific findings.

When to use: Most valuable for meeting compliance mandates (PCI DSS, HIPAA, SOC 2 Type II) or validating foundational security controls.

What to look for in a provider: Manual exploitation performed alongside automated scanning, not in place of it. Consultants capable of chaining multi-step attack sequences, not just cataloging isolated findings. Remediation guidance sequenced by exploitability and business impact, not solely by CVSS score.

Red Team Exercises

What it is: A covert engagement that simulates targeted adversaries pursuing specific objectives, using the same tactics, techniques, and procedures (TTPs) as real-world threat actors.

What it does: Generates realistic data on detection timelines and incident response effectiveness, testing people, processes, and technology together rather than in isolation.

When to use: Most valuable when foundational controls are already in place and an organization needs to know whether its security operations can detect and contain a sophisticated, motivated attacker.

What to look for in a provider: Defined engagement objectives tied to your organization’s actual crown jewels. Threat actor TTPs specific to your industry and threat landscape, not generic attack playbooks. Documented experience conducting covert operations against mature security teams.

Full-Stack Assessments

What it is: An engagement extending beyond application and network layers to examine the entire technology stack, from silicon, firmware, and embedded systems through software, cloud environments, and organizational processes.

What it does: Surfaces vulnerabilities that exist across layer boundaries and cannot be found when components are tested in isolation.

When to use: Most valuable for organizations whose risk environment spans hardware, software, and cloud infrastructure, or where a single compromise could cascade across multiple layers.

What to look for in a provider: Verifiable technical expertise at every layer of the stack. Dedicated physical labs for hardware and embedded device testing. A methodology that integrates silicon, firmware, application, and cloud assessment into a unified risk picture rather than a series of disconnected engagements.

AI Security Assessments

What it is: An engagement targeting the attack surfaces introduced by AI and machine learning systems, including adversarial inputs, prompt injection, model extraction, data poisoning, and compromised training pipelines.

What it does: Identifies vulnerabilities in AI/ML infrastructure that standard penetration testing frameworks do not address.

When to use: Most valuable for organizations integrating AI into critical systems, customer-facing products, or consequential decision-making workflows.

What to look for in a provider: Specific technical familiarity with ML architecture, LLM systems, and AI infrastructure, not general offensive security experience reapplied to an AI context. Testing that reaches the model layer, not only the surrounding application interface.

Product and Hardware Security Testing

What it is: An examination of the physical and logical security of connected devices, embedded systems, firmware, and silicon, including side-channel analysis, fault injection, reverse engineering of proprietary protocols, and cryptographic implementation review at the hardware level.

What it does: Identifies vulnerabilities below the software layer that application and network testing cannot detect.

When to use: Critical for device manufacturers, industrial equipment providers, and organizations deploying connected hardware at scale.

What to look for in a provider: A dedicated physical hardware lab. Documented experience with embedded system analysis and silicon-level techniques, including fault injection and side-channel attacks. A testing methodology covering hardware, firmware, and protocol layers together, rather than firmware in isolation.

Code Review and Reverse Engineering

What it is: A deep examination of software security at the source-code and binary levels, surfacing business logic flaws, implementation errors, and vulnerabilities in proprietary or legacy code that automated tools miss.

What it does: Provides visibility into software defects invisible to dynamic testing approaches.

When to use: Most valuable during software development lifecycles, before major product releases, or when evaluating acquired or third-party code.

What to look for in a provider: Reviewers with development backgrounds capable of identifying logic flaws alongside security vulnerabilities. Language and platform coverage relevant to your codebase. A methodology combining automated analysis with intensive manual review rather than relying on either alone.

Critical Infrastructure / OT Testing

What it is: Security assessment of industrial control systems (ICS), SCADA environments, and operational technology (OT) networks. These environments operate under constraints that standard IT security methodology cannot accommodate: proprietary protocols, extreme availability requirements, and physical safety implications.

What it does: Identifies vulnerabilities in OT/ICS environments without disrupting live operations.

When to use: Essential for organizations in energy, utilities, manufacturing, water systems, and other sectors where digital and physical systems converge.

What to look for in a provider: Sector-specific OT/ICS expertise, not IT security methodology adapted to an OT context. A testing approach designed for operational continuity constraints. Documented experience conducting assessments in live environments where testing itself carries operational risk. A 2024 CISA red team assessment of a U.S. critical infrastructure organization found simulated attackers went undetected for months, underscoring the gap between generic assessment methodology and the specialized expertise these environments require.

Purple Team Exercises

What it is: A collaborative engagement pairing red team offensive expertise with an organization’s own security team, focused on real-time detection rule tuning, playbook validation, and skills transfer between attacker and defender.

What it does: Improves detection and response capability directly, rather than documenting gaps for a team to address independently.

When to use: Most valuable for security teams that have completed initial red team engagements and want to operationalize findings in a collaborative format.

What to look for in a provider: Consultants capable of operating in both attacker and advisor roles simultaneously. A structured methodology for real-time feedback and control validation, not a loosely coordinated simulation.

Key Criteria for Evaluating Cybersecurity Assessment Methodology

The assessment type defines what gets tested. The methodology defines how, and this is where provider capability differences become most consequential. These six criteria help distinguish providers whose testing delivers genuine security insight from those whose engagements produce reports without materially improving security posture.

Assessment Scope and Technical Specialization

Most security firms assess network and application layers. Far fewer can credibly test hardware, silicon, embedded firmware, AI systems, or OT environments. A provider may list broad services without maintaining the specialized expertise to execute them.

Look for:

A dedicated physical lab for embedded device and hardware testing
Documented capability for silicon-level testing, including side-channel analysis and fault injection
AI security testing that reaches the model layer, not just the application interface
Sector-specific references for OT/ICS environments

Provider Scope Coverage by Capability Level

Scope Layer	Standard Provider	High-Capability Provider
Application and Network	Yes	Yes
Cloud Environments	Sometimes	Yes
Embedded / IoT Devices	Rarely	Yes
Hardware / Silicon	Rarely	Yes: dedicated physical lab required
AI/ML Systems	Rarely	Yes: with dedicated AI expertise
OT / ICS	Rarely	Yes: specialized sector knowledge required

The gap between standard and high-capability providers widens significantly below the application layer. For organizations whose risk environment includes hardware, AI, or OT systems, scope coverage and technical specialization are the threshold criteria, not price or brand recognition.

Testing Methodology: Attacker-Driven vs. Checklist-Driven

There is a meaningful difference between providers who work through a checklist of known vulnerability categories and providers who approach testing with the mindset of an actual adversary. The latter requires consultants who can chain vulnerabilities across layers, reason about attacker objectives, and adapt in real time.

Look for:

Manual exploitation is performed alongside automated tooling, not replaced by it
Demonstrated ability to chain multi-step vulnerabilities across components
Threat actor TTPs specific to your industry, not generic attack frameworks
Engagement objectives tied to your organization’s actual crown jewels

Vulnerability Research Capability

The highest-capability providers generate original vulnerability research rather than relying exclusively on public CVE databases and commercial tooling. Firms with active research programs bring a more current understanding of attack surfaces, including weaknesses not yet publicly disclosed.

Look for:

Published CVEs attributed directly to the provider’s research team
Peer-reviewed technical research or presentations at Black Hat, DEF CON, or IEEE S&P
Publicly documented discoveries in hardware, AI, automotive, industrial, or other specialized domains
A research function that feeds directly into assessment methodology

Reporting Quality and Risk Translation

A rigorous assessment methodology produces findings that drive decisions, not simply findings that document vulnerabilities. Enterprise security teams and executive stakeholders need reports that prioritize risk in business terms.

Look for:

Findings mapped to business impact, not only to technical severity scores
Remediation guidance that is specific, practical, and sequenced by risk priority
Findings contextualized to the organization’s actual environment, not offered generically
Metrics supporting ongoing measurement: detection timelines, mean-time-to-compromise, and control coverage gaps

Environment Complexity Fit

For organizations running conventional enterprise IT, environment fit is rarely the differentiating factor. For organizations in regulated industries, manufacturing, energy, defense, or sectors where physical and digital systems converge, it is often the deciding one.

Look for:

References from engagements in your sector
A stated methodology for testing within operational continuity constraints
Documented experience in environments where the testing itself introduces operational risk

All six criteria above feed directly into the selection framework below: assessment scope, testing methodology, technical specialization, vulnerability research capability, reporting quality, and environment complexity fit.

A Framework for Selecting the Right Cybersecurity Assessment Provider

Provider Selection Framework: Seven Steps to the Right Fit

Step	Question to Answer	What to Look For
1. Define what you’re protecting	What are your organization’s crown jewels, and where do they live?	Environments may span IT, OT, hardware, cloud, and AI
2. Identify the assessment type	What question does this engagement need to answer?	Compliance gap? Detection readiness? Hardware risk? AI exposure?
3. Evaluate scope coverage	Can the provider credibly assess every relevant layer?	Documented capability, not listed services
4. Assess testing methodology	Does the provider test with genuine attacker perspective?	Manual exploitation, TTPs, multi-vector attack chains
5. Check vulnerability research credentials	Does the provider generate original research?	Published CVEs, conference presentations, specialized domain expertise
6. Review reporting examples	Does the report drive decisions, not just list findings?	Business-impact framing, prioritized remediation, and executive readability
7. Evaluate environment complexity fit	Has the provider operated in environments like yours?	Sector-specific references, OT/hardware/AI-specific experience

Matching Provider Capability to Organizational Maturity

Organizational maturity also shapes which type of engagement makes sense. Security programs early in their development benefit most from penetration testing and code review. Programs with mature controls and functioning SOCs get more from red team exercises, purple team exercises, and adversarial simulation. Providers capable of operating across that full maturity range, and advising on which engagement fits the current stage, offer more strategic value than specialists limited to a single methodology.

When Standard IT Methodology Is Not Enough

For organizations whose environments extend to hardware, AI systems, embedded devices, or critical infrastructure, Steps 3, 5, and 7 carry the most weight. The provider pool narrows significantly once the risk environment extends beyond conventional IT. The right partner combines offensive testing expertise with active vulnerability research, physical lab capability, and documented experience in complex environments.

Evaluate a Provider’s Cybersecurity Assessment Methodology Before Signing a Statement of Work

Understanding the depth and rigor of a provider’s cybersecurity assessment methodology is a more reliable guide than reviewing their service catalog.

IOActive has spent over 25 years conducting assessments across the full technology stack, from silicon and embedded hardware to software, AI systems, and critical infrastructure, backed by a research team with a documented record of original vulnerability discovery. If your organization’s environment extends beyond conventional IT, contact IOActive to discuss an assessment approach matched to your actual attack surface.

Contact IOActive to Discuss Your Assessment Needs

INSIGHTS | October 29, 2026

Vendor Risk Assessment Template: Free Guide

By Christian Powills

“A vendor risk assessment should help organizations identify where third-party access, technology, and dependencies could introduce meaningful security exposure.” – IOActive Security Team

Vendors may have security policies in place, but those policies do not always show how much risk their access and technology create for your organization. A useful assessment looks beyond the policy document to the attack paths a compromised vendor could open.

Use this vendor risk assessment template free of charge to establish scope, test evidence quality, and determine when a vendor relationship warrants technical validation. This framework aligns with NIST SP 800-161 Rev. 1, which addresses the identification, assessment, and mitigation of cybersecurity supply chain risk, and the NIST Cybersecurity Framework 2.0 C-SCRM guidance, which prioritizes vendors by criticality and expects vendor risk to be monitored throughout the relationship.

Vendor Risk Assessment Template

The matrix below is the core template. Add an owner, a due date, and a progress update for each follow-up item.

Core Vendor Risk Assessment Template

Assessment domain	Questions to ask	Evidence to request	Escalate when
Data access and handling	What data is collected, stored, transmitted, or generated?	Data-flow diagram, retention policy, subprocessors	Sensitive data leaves approved regions or lacks deletion controls
Authentication and access	How are workforce, customer, privileged, and service accounts protected?	Multi-factor authentication (MFA) standard, access review record, privileged access design	Shared accounts, unmanaged service accounts, or weak recovery paths appear
Security controls	Which preventive, detective, and corrective controls protect the service?	SOC 2 report, ISO 27001 certificate, control summary	Evidence is expired, narrow in scope, or vague
Vulnerability management	How are flaws found, triaged, fixed, and communicated?	Vulnerability policy, scan summary, remediation targets	Critical issues lack owners, deadlines, or customer notification rules
Incident response	How will the vendor detect, contain, investigate, and report an incident?	Incident plan, notification terms, exercise summary	No tested process or clear customer communication path exists
Software and product security	How are code, dependencies, builds, updates, and releases secured?	Secure development lifecycle (SDL) overview, Software Bill of Materials (SBOM), secure release controls	The vendor cannot explain update integrity or dependency risk
Infrastructure dependencies	Which cloud, hosting, identity, network, and fourth-party providers support delivery?	Architecture diagram, resilience plan, dependency list	A hidden dependency can interrupt a critical service
Regulatory considerations	Which contractual, privacy, sector, or geographic requirements apply?	Compliance mapping, data-processing terms, audit rights	Requirements are treated as badges rather than operating controls
Ongoing monitoring	What changes trigger reassessment, notification, or approval?	Review cadence, change process, service metrics	Risk is reviewed only at onboarding or renewal

The escalation column is the operational center of the template. It converts a completed questionnaire into decisions about access, evidence, remediation, and technical validation.

1. Data Access, Handling, and Authentication

Start with the path to impact. Determine what a compromised vendor account, integration, administrator, service account, or update process could reach from the relationship. Do not accept “the vendor encrypts data” as a complete control description. Identify where encryption begins and ends, who can decrypt the data, how keys are governed, and whether support personnel can access production records.

Apply the same discipline to authentication. “Multi-factor authentication enabled” is incomplete if privileged access, API keys, recovery flows, and non-human accounts follow different rules.

Access and Authentication Signals

Signal	What it may indicate	Useful follow-up
Broad network connectivity	A vendor compromise could become a pivot into internal systems	Request segmentation and least-privilege diagrams
Production access for support personnel	Human or credential abuse could affect live data	Review just-in-time access, approvals, and session logging
Long-lived API keys	Stolen credentials may remain useful after personnel changes	Ask about rotation, scope, expiration, and detection
Unclear data deletion	Data may persist after the contract ends	Confirm deletion timelines, backups, and verification

These signals distinguish a limited data-processing role from a viable route into higher-value assets. The next step is to test whether the stated controls cover that route.

2. Security Controls and Vulnerability Management

Assess whether controls operate in the systems that support your relationship. Request enough detail to establish ownership, coverage, operating frequency, exceptions, and evidence retention.

For vulnerability management, ask how the vendor handles flaws in proprietary code, open-source components, cloud configuration, and externally exposed services. The relevant question is whether it can discover, prioritize, remediate, and communicate weaknesses before they create downstream exposure.

Control Evidence Matrix

Control area	Evidence that helps	Warning sign
Asset inventory	Scope statement and inventory ownership	The vendor cannot define what is in scope
Vulnerability management	Remediation policy and recent summary	Severity is tracked without business impact
Configuration security	Baselines, review records, or cloud controls	Defaults remain in production without justification
Logging and detection	Coverage map and retention details	Critical actions are not attributable to a user or service
Backup and recovery	Recovery objectives and exercise results	Recovery claims are not tested
Exceptions	Risk acceptance records and expiry dates	Exceptions have no owner or end date

A SOC 2 report, an ISO 27001 certificate, a penetration test summary, or a similar document can support an answer. It does not establish that every system relevant to your relationship is secure today. Check the assessment period, scope, exclusions, testing method, and unresolved findings.

Once control coverage and evidence quality are understood, the assessment should address the vendor’s ability to coordinate in the event of a compromise or service disruption.

3. Incident Response and Operational Resilience

A vendor incident can become a major problem when its systems process your data, connect to your network, or support a critical business function. The assessment should therefore examine coordination, evidence preservation, notification, and recovery, not only the existence of an internal response plan.

Ask who contacts your organization, how quickly the vendor must notify you, what evidence will be preserved, and how your teams will participate in containment. Confirm whether the vendor has exercised scenarios involving credential theft, ransomware, cloud compromise, data exposure, and loss of a key subprocessor.

Incident Readiness Matrix

Question	Stronger answer	Deeper investigation trigger
Who declares an incident?	Named decision-makers and an escalation tree	Responsibility depends on an unnamed team
How are customers notified?	Contract terms and tested communication channels	Notification is “as soon as practical” with no process
What evidence is preserved?	Defined logs, timestamps, and retention rules	Forensic support is not addressed
How does service recover?	Recovery objectives supported by exercises	Recovery depends on an untested assumption
How are lessons tracked?	Post-incident actions have owners and deadlines	Reports close without corrective action

These answers determine whether your organization can make informed decisions during an incident. Because NIST treats supply chain risk as a lifecycle concern, resilience and incident coordination belong in vendor governance, not only in the security team’s incident plan. The assessment can then move below the policy layer to examine the software, products, and infrastructure that create the vendor’s attack surface.

4. Software, Product Security, and Infrastructure Dependencies

Questionnaires provide limited assurance when the relationship depends on complex technology. If a vendor ships software, manages infrastructure, or embeds components in a product, assess how it engineers and maintains security across the lifecycle.

For SaaS applications, review tenant isolation, identity integration, logging, administrative access, and customer-data boundaries. For software, review the development lifecycle, code review, dependency management, build pipeline, release signing, update process, and vulnerability disclosure path. For hardware or embedded products, include firmware, debug interfaces, default credentials, update mechanisms, and manufacturing or support channels.

For infrastructure, map the services beneath the vendor’s service. A cloud provider, identity platform, managed service provider, hosting region, or fourth-party dependency may become a constraint that the vendor cannot quickly replace.

Technology Relationship Review

Technology relationship	Examine	Validate when
SaaS application	Tenant isolation, identity, logging, integrations	The service connects to privileged systems or sensitive data
Software component	Build pipeline, dependencies, release integrity, Software Bill of Materials (SBOM)	The component runs in production or handles trusted input
Hardware or embedded product	Firmware, update path, debug access, support channels	The product controls physical processes or safety functions
Managed infrastructure	Segmentation, administrator access, resilience, fourth-party providers	Outage or compromise would interrupt critical operations

An attacker-oriented assessment can expose assumptions that documentation leaves untested. Ask which trust boundary an attacker would target first, which control would be bypassed, and which asset would be exposed if that control failed.

For example, a vendor may require remote support access, expose an administrative API, and rely on a fourth-party identity provider. Those dependencies can combine into an attack path that is not visible in any single questionnaire response. The answers inform the regulatory and monitoring requirements that govern the relationship.

5. Regulatory Considerations and Ongoing Monitoring

Regulatory requirements should shape the assessment, but they should not substitute for it. Identify the laws, sector rules, contractual duties, data-location limits, breach obligations, retention requirements, and audit rights that apply to the relationship.

Then convert each requirement into an operating question.

Who owns the control?
Which system enforces it?
What record proves it operated?
What happens when the vendor changes a subprocessor, moves data, introduces a new integration, or experiences a material incident?

The NIST CSF 2.0 C-SCRM guidance calls for due diligence before a relationship begins. NIST CSF 2.0 also calls for understanding, recording, prioritizing, assessing, addressing, and monitoring vendor risks over time.

Lifecycle Monitoring Matrix

Change event	Reassess this area	Minimum action
New data type or use	Data handling and privacy	Update the data flow and contract terms
New integration	Access, authentication, and segmentation	Review permissions and test the connection
Acquisition or ownership change	Governance, personnel, and dependencies	Request an updated risk profile
New subprocessor	Fourth-party dependency and geographic exposure	Review the subprocessor before approval
Material incident	Detection, response, and residual risk	Track corrective actions to closure
Major product release	Software, product, and update security	Review release and change controls

An annual review may be appropriate for a low-impact vendor. It is not a universal control. Continuous monitoring should track material changes, while formal reassessment should occur according to access, criticality, change rate, and plausible business impact.

These triggers identify when a questionnaire requires technical validation. A vendor’s risk profile changes with its architecture, ownership, software, or data flows.

6. When a Questionnaire Is Not Enough

A questionnaire is insufficient when the answer depends on technical behavior that the vendor cannot demonstrate with policy documents. This does not mean every vendor requires a penetration test. It means the assurance method must correspond to the consequence of being wrong.

Use targeted technical validation when the vendor has privileged access, handles sensitive or regulated data, supports a critical process, ships software or hardware, exposes internet-facing services, relies on opaque fourth-party providers, or provides evidence that is incomplete, stale, or outside the relevant scope.

These scenarios are illustrative, not a severity ranking. Use the vendor’s access, criticality, evidence quality, and business impact to determine the escalation path.

Evidence Sufficiency and Escalation Matrix

Questionnaire result	What does it tell you	Better next step
Complete answers, low-impact service	Basic risk is understood	Record the decision and monitor material changes
Strong documents, high-impact access	Control design may be credible	Validate scope, access paths, and technical assumptions
Vague answers, critical dependency	Risk is not measurable	Require evidence before onboarding or restrict access
Product with update or build authority	The vendor can influence trusted code	Review product security, release integrity, and dependencies
Repeated exceptions or delayed remediation	Risk may be systemic	Conduct targeted testing or an independent assessment
Major incident with unclear lessons	Residual risk is unknown	Require root-cause evidence and corrective-action tracking

Possible validation methods include architecture review, configuration review, attack-surface analysis, secure code review, product security testing, cloud control validation, adversary simulation, and targeted penetration testing. Select the method according to the attack path, not the vendor’s preferred deliverable, and record the rationale for the escalation decision.

7. Scoring and Prioritizing Findings

Avoid a single score that conceals the reason for the risk. Record business criticality, access level, data sensitivity, and confidence in the evidence. A high-impact vendor with strong evidence may be acceptable, while a lower-impact vendor with privileged access and weak evidence may warrant faster intervention. The score should support a decision, not create false precision.

Vendor Risk Decision Matrix

Priority	Typical condition	Decision
Low	Limited access, low-impact service, clear evidence	Approve with routine monitoring
Moderate	Sensitive data or meaningful integration, controls mostly supported	Approve with tracked remediation
High	Privileged access, critical dependency, or major evidence gaps	Escalate to security and business owners
Critical	Plausible path to material compromise with no timely mitigation	Delay, restrict, or reject the relationship

For every finding, record the affected asset, attack path, business consequence, evidence, owner, due date, and acceptance authority. A finding without an owner is a future repeat finding.

This structure distinguishes inherent risk, control effectiveness, residual risk, and management acceptance before approval or renewal.

IOActive helps organizations assess vendor and supply chain risk from an attacker’s perspective, identifying technical exposure across third-party products, software, infrastructure, and access pathways.

Contact IOActive to discuss a vendor risk assessment

INSIGHTS | October 27, 2026

How to Evaluate a Cybersecurity Provider

By Christian Powills

Security leaders reviewing an assessment dashboard to evaluate a cybersecurity provider’s skills and test coverage.)

“The right cybersecurity provider should be evaluated on the depth of problems they can uncover, the environments they can test, and the expertise behind their findings.” – IOActive Security Team

When you evaluate a cybersecurity provider, the right partner should help you answer a specific security question with evidence you can act on. A long service list is not enough. The provider should also be able to test the systems, attack paths, and business risks that matter to your company.

This article focuses on providers that run independent security tests and attack-led work. That includes penetration testing, red teaming, product and hardware security testing, AI/ML security testing, and full-stack assessments. If you are choosing an MDR, SOC, or managed security provider, also review monitoring, response, and service levels. Those managed-service needs are outside this guide.

Start with the decision that the engagement must support. Then compare the method, team skill, proof, reporting, and ability to test beyond compliance.

The Five-Step Evaluation Path

Define the security question. State what decision the assessment must support.
Choose the assessment method. Match the method to the asset, threat, and desired outcome.
Match the provider to the engagement. Look for experience at the technology layer and risk level involved.
Test the quality of the findings. Confirm that the report explains evidence, impact, root cause, and priorities.
Validate research and independence. Look for current skills, clear briefings, and work beyond compliance.

Use the table below as a quick screen during the buying process. Good signs show a strong lead. Warning signs show what to resolve before you shortlist a provider.

Cybersecurity Provider Evaluation Checklist

Step	What to check	Question to ask	Good signs	Warning signs
1	Scope fit	What decision will the test support?	Clear assets, attack paths, limits, and goals	A generic scope with no clear outcome
2	Technical depth	Can the team work beyond tools?	Manual work, custom tests, and proven attack paths	A scan report presented as the full test
3	Engagement fit	Has the team handled these systems and threats?	Work on similar systems and risks	Generic case studies or one method for all clients
4	Finding quality	Can our teams check and rank the results?	Steps to repeat, impact, cause, and fix guidance	Long issue lists with little detail
5	Provider depth	Does the team research and explain clearly?	Relevant research, clear briefings, and stated limits	Broad claims backed only by logos or badges

Step 1: Define the Security Question Your Assessment Must Answer

“We need a penetration test” is not a clear need. It may mean a public app, a cloud system, a product before launch, or a path to a key asset.

Write the decision first. You may need to launch a product, fund a fix, test response, accept a risk, or meet a customer need.

Give each provider the same facts:

The assets and systems in scope.
The likely attackers or abuse cases.
The attack paths or trust boundaries that matter.
The testing limits, dependencies, and rules of the test.
The business decision must support the results.

A strong provider should restate your question in its scope. If the scope lists tasks but not the decisions they inform, ask for a rewrite.

If your decision is…	Your scope should clarify…
Launch a product	Which product layers, interfaces, and abuse cases could affect release risk
Reduce attack surface	Which assets, entry points, and chained attack paths need testing
Improve detection and response	Which realistic attacker actions must defenders detect and contain
Prioritize remediation	How results will be ranked by ease of attack, impact, and business cost
Support risk acceptance	Which residual risks remain after testing and what evidence supports acceptance

Step 2: Choose an Assessment Method That Fits the Goal

Once the question is clear, pick the method that can answer it. Do not ask every provider for the same output. Ask what each method does and what proof it should produce.

Assessment element	Use it for	What to look for
Threat modeling (method)	Finding likely attack paths before testing	Named assets, actors, entry points, trust boundaries, and goals
Manual review (method)	Finding design, code, setup, and logic flaws that tools may miss	Analyst notes, test steps, and custom test examples
Attack-path testing (method)	Showing how flaws can combine into real impact	A chained attack example with limits and key facts
Technical evidence (output)	Letting teams check that a finding is real	Steps to repeat, affected parts, logs, images, or code notes
Risk ranking (decision aid)	Helping leaders decide what to fix first	Business impact, ease of attack, links, and a clear work order
Retesting (follow-up)	Checking whether fixes reduce the risk	Clear close rules, retest scope, and open issue steps

The label matters less than the proof. A good plan explains why the method fits, what it will not cover, and how the result will guide the next choice.

Step 3: Match the Provider to the Engagement

A provider that fits one engagement may not fit another. Use the goal, likely attacker, system layer, and cost of failure to choose the right team.

Goal	Best-fit provider type	Skills to value	Evidence to review
Test an application or network	Penetration testing provider	Manual attacks, path tests, and real impact checks	Sample finding, test scope, and work on similar systems
Test detection and response	Red team or purple team provider	Threat-led exercises for prevention, detection, response, and recovery	Test rules, goals, and report sample
Review a product before launch	Product security provider	Design review, code checks, interface tests, misuse cases, and fix guidance	Product method and related past work
Test hardware or firmware	Embedded, hardware, or silicon security provider	Firmware analysis, protocol tests, reverse engineering, lab work, and low-layer tests	Lab skills and examples with similar parts
Test an AI system	AI/ML security provider	Model, data, prompt, API, pipeline, system, and access-rule tests	AI test cases, threat model, and test plan
Find systemic risk	Full-stack assessment provider	Coverage across systems, people, process, supply chain, and business impact	Full-stack plan, team skills, and joint results

These provider types can overlap. A product review may include penetration testing, code review, hardware testing, and AI testing. Ask who will do each part and who will combine the results into one risk view.

Step 4: Test the Quality of the Findings and Delivery

A strong assessment helps only when your teams can understand, check, and rank the results. Before signing, request a sample report with sensitive data removed. Use these four questions to judge the provider’s work.

Can we verify what was tested and found?

The report should name the asset, test condition, behavior, and proof. A severity label is not enough. Ask if an engineer could repeat the issue from the report alone.

Do we understand the impact and root cause?

A useful finding links the weakness to a business result. It also explains the cause, such as a design choice, a missing control, an unsafe default, or a process gap. This helps stop repeat issues.

Do we know what to fix first?

The provider should separate urgent exposure from lower-priority hardening. Look for rankings based on ease of attack, affected assets, path position, business impact, and links. Ask how moderate issues combine into a serious path.

Can leaders and engineers use the result?

Executives need a short view of risk, impact, and choices. Engineers need enough detail to check and fix each issue. Ask who presents the results, whether work sessions are included, and how disputes about severity are handled.

Step 5: Validate Research, Independence, and Work Beyond Compliance

After reviewing the sample report, assess the provider itself. Research can show how a team studies new systems. It should relate to your setup and be clear, not hyped.

Look for:

Research related to your systems, threats, or industry.
Examples that show how the team found an issue.
Clear rules for disclosure and client data.
Direct answers about methods, limits, and staff.
Evidence that hard findings are reported clearly.

Certifications and compliance work can help. They should support, not replace, proof of deep skill. Compliance checks a stated rule. Security testing asks if an attacker can bypass it or reach something important.

Ask Four Questions Beyond Compliance

Use compliance testing as a base, then ask these four paired questions. Each one connects an audit check to the security outcome an enterprise buyer actually needs.

1. Did the control meet the stated rule, and can an attacker bypass it?

A control can satisfy a written requirement and still fail under attack. Ask the provider to test bypasses, abuse cases, and paths around the control, not only whether the control is present.

2. Was the approved setting present, and does it work under attack?

A configuration review confirms what was set. Security testing checks whether the setting holds when an attacker probes, misuses, or tries to evade it.

3. Was the component included in scope, and can it create a path to a critical asset?

Scope coverage does not show how a component connects to the rest of the environment. Ask the provider to assess trust boundaries, dependencies, and attack paths into high-value systems.

4. Did the test produce audit evidence, and did it reveal meaningful business impact?

Audit evidence can show that a test occurred. A security assessment should also explain what an attacker could do, which business processes could be affected, and what to fix first.

How IOActive Fits This Evaluation Framework

IOActive’s public service pages show examples across these provider types:

Penetration testing: Mobile apps, infrastructure, wireless, cloud, embedded devices, and web services.
Red and purple teaming: Realistic attack exercises and defense testing.
AI/ML security: Models, data, prompts, apps, systems, and pipelines.
Silicon security: Hardware and lower-level research.

These skills matter when you need more than a scan or compliance review. The same rules still apply: define the decision, confirm the method, review the proof, and check that your team can act on the result.

Choose a Provider That Can Answer Your Security Question

To evaluate a cybersecurity provider, start with the decision you need to make. Then compare methods, team skill, provider fit, proof, communication, research, and work beyond compliance. The right partner can test your real risk and turn the result into a clear next step.

Talk with IOActive about the right cybersecurity assessment for your environment

INSIGHTS | October 23, 2026

Below the Threshold: Why Britain’s Smallest Power Generators Face a Four-Year Cyber Security Gap

By IOActive

Key Takeaways

A small-scale gas generator was taken offline for four days in July 2026. The UK Government confirmed the incident but has not formally attributed it. [1]
Under the Network and Information Systems Regulations 2018, electricity generation is captured only at 2GW cumulative capacity, and the threshold expressly excludes generators that are not connected to a transmission system. [2]
On 5 August 2026 the Department for Energy Security and Net Zero and Ofgem confirmed that baseline cyber resilience requirements for all Ofgem licensees will be built on Cyber Essentials Plus, consulted on during 2027 and in place across the sector by the end of 2030. [3]
The same government response acknowledges that Cyber Essentials Plus excludes operational technology and lacks controls covering governance, incident response, risk management and supply chain. Its Plus tier applies the same five technical controls as Cyber Essentials with independent testing, rather than extending them. [3] [9]
IT and OT segregation was the single most requested additional control among consultation respondents, raised by 18 of the 49 organisations and individuals who replied. [3]

Why This Matters Now

In July 2026 a small-scale British generating asset stopped producing power for four days following a cyber incident. Michael Shanks, Minister of State at the Department for Energy Security and Net Zero, confirmed that the incident had affected a small-scale energy generator, and the Department stated that at no point was the wider energy system at risk. [1] Press reporting linked the intrusion to Iranian-aligned actors, though the UK Government has made no formal attribution.

The detail that matters for security leaders is not the attribution. It is the position of the asset. A four-day outage at a small distribution-connected generator is an outage at something well below the regulatory perimeter drawn in 2018, which means the operator was almost certainly under no statutory cyber resilience obligation at all.

That perimeter is not a historical accident. The Government’s own Energy Sector Cyber Security Strategy states that the NIS Regulations were only ever intended to apply to the most critical operators and therefore do not provide holistic coverage of the energy system. [4] The strategy also commits Government to encourage more reporting of cyber incidents that fall below NIS thresholds, which is a plain acknowledgement that the sub-threshold estate is a blind spot.

The threat is not theoretical. In December 2025 a threat actor targeted around 30 distributed renewable assets in Poland, including wind and solar farms and a combined heat and power plant. Generation and heat supply held, and the plant involved served nearly 500,000 heat customers. What matters is how the attacker got in: internet-exposed firewall appliances without multi-factor authentication, unpatched devices and reused credentials. Most of those routes could have been closed by basic cyber hygiene. A parallel attack the same day on a smaller plant serving 50,000 residents did interrupt cogeneration, shutting down a steam turbine and the water treatment system. [5] [6]

Meanwhile the estate is growing. Government projections cited in the March 2026 consultation put battery storage capacity on a six-fold increase and wind and solar capacity almost tripling by 2030. [5] Ofgem currently regulates just over 1,400 licensed operators, and Government has described the absence of cyber resilience requirements across a large proportion of them as one of two fundamental reform needs. [3]

What the Regulatory Position Actually Is

Schedule 2 of the NIS Regulations 2018 sets the thresholds at which an operator becomes an Operator of Essential Services. For downstream gas and electricity these are as follows.

Essential Service	Electricity	Gas (Downstream)
Generation	2GW or more (cumulative)	N/A
Transmission	More than 250,000 final customers	More than 250,000 final customers
Offshore Transmission	2GW or more (cumulative)	N/A
Distribution	More than 250,000 final customers	More than 250,000 final customers
Interconnectors	1GW or more	More than 20M m3 gas per day
Supply	More than 250,000 final customers	More than 250,000 final customers
Load Control	300MW or more	N/A

Source: DESNZ and Ofgem consultation documents, drawn from NIS Regulations 2018 Schedule 2. Generation excludes nuclear generators and generators not connected to a transmission system. Capacity is cumulated across affiliated undertakings. Load control is not yet in force and will be commenced through the Cyber Security and Resilience Bill. [2] [3]

Two features of that table deserve attention. First, generation capacity is cumulated across a corporate group, so a modest site inside a large portfolio can sit above the line while a standalone site of identical rating sits below it. Second, generators not connected to a transmission system are carved out regardless of size, which removes most distribution-connected embedded generation from scope entirely.

Government consulted on this between 27 March and 22 May 2026 and published its response on 5 August 2026. Nineteen respondents told Government that the electricity generation threshold should change. Twenty-one argued that thresholds should be driven by risk or impact rather than by supply or generation volume, and 19 said the sector has become distributed to the point where current thresholds no longer reflect where risk arises. Six respondents proposed specific replacement figures, including 200MW and 500MW for generation. [3]

Government has not adopted a new number. It has commissioned the National Energy System Operator to advise on which services and thresholds should apply, and intends to consult on any revisions during 2027, subject to the Cyber Security and Resilience Bill receiving Royal Assent. The response states that Royal Assent is expected in early 2027, though secondary coverage consistently reports an expectation of late 2026. The Bill completed Lords Second Reading on 14 July 2026 and entered Lords Committee Stage on 1 September 2026. [3] [8]

Alongside that review, Government confirmed it will introduce baseline cyber resilience requirements for all Ofgem licensees, delivered through licence conditions and founded on Cyber Essentials Plus. Ofgem will consult on the detail during 2027. The public commitment is that a baseline level of cyber resilience will be in place across the whole downstream gas and electricity system by the end of 2030. Any intermediate tier between baseline and NIS is expected to be considered only after 2030. [3]

Who is Affected by the Sub-Threshold Gap?

Sub-threshold generators and distributed energy operators. Operators of embedded gas plant, solar, onshore wind, battery storage and long duration storage that fall below 2GW, or that are not transmission-connected, carry no statutory cyber resilience obligation today and will carry none until baseline requirements are implemented through licence conditions. Many of these sites are unmanned and dependent on remote access.

NIS-designated operators. Designation does not insulate a large operator from the gap. NIS requirements apply only to the network and information systems on which the essential service relies, which Government acknowledges leaves ancillary, supporting and back-end systems outside scope. [5] Large operators also depend on smaller counterparties for flexibility, balancing and aggregation.

Aggregators, flexibility platforms and remote service providers. Consultation respondents identified flexibility services, aggregators and orchestration platforms as the most commonly proposed additions to the essential services list, alongside digital and data platforms and remote monitoring and management providers. [3] Some of these organisations will be captured as large load controllers at 300MW of aggregate controllable load. Many will not.

Boards and investors in generation assets. The regulatory floor is now dated and public. A board that waits for 2030 is accepting four years of exposure on an asset class that has already been taken offline once.

What Are the Challenges the 2030 Baseline Does Not Solve?

The most significant issue is that the announced remedy is shaped for information technology, not for the control systems that took the plant offline.

Government has been candid about this. The consultation observed that Cyber Essentials is primarily suitable for IT, that many downstream gas and electricity operators rely on SCADA systems, programmable logic controllers, human machine interfaces and remote telemetry units, and that applying Cyber Essentials controls to those environments can be challenging and in certain circumstances unsuitable. [5] The government response goes further, recognising that Cyber Essentials Plus has limitations for the energy sector in relation to the exclusion of operational technology and the absence of controls for governance, incident response, risk management and supply chain. [3]

Respondents said the same thing with numbers behind it. IT and OT integration or network segmentation was the leading requested addition at 18 respondents, followed by incident response and exercising at 17, remote access management at 13, supply chain visibility at 12 and governance at 10. When asked for alternative frameworks, respondents most often named the NCSC Cyber Assessment Framework at 16 and IEC 62443 at 15, ahead of ISO 27001 at 14. [3] The sector asked for an OT-aware standard. What has been confirmed so far is an IT scheme that Government intends to build on, with the additional controls still to be designed. It is worth being precise about what the Plus tier adds: Cyber Essentials Plus applies the same five technical controls as Cyber Essentials and subjects them to independent technical testing rather than extending them. [9] Choosing Plus over the base scheme raises the assurance level, not the scope.

Three further constraints compound this. Government intends that, where possible, baseline requirements should apply only to systems not already covered by existing cyber resilience obligations, which creates scope boundaries that operators will need to evidence rather than assume. [3] Consultation respondents reported that the prescriptiveness of Cyber Essentials controls and the inability to use compensating controls were common drivers of cost in OT-heavy and legacy environments. [3] And the assurance route for complex estates is still under exploration, with Government committing only to examine the potential of NCSC Cyber Essentials Pathways. [3]

The practical conclusion for a security leader is that compliance and resilience are not the same programme here, and neither of them arrives before 2030.

How IOActive Can Help

The gap this post describes is not a compliance problem yet, which is precisely why it is an assessment problem now. An operator below the 2GW line has no licence condition to evidence against and no NIS designation to scope, so the only reliable way to establish its position is to test the estate against a framework the eventual baseline will have to catch up to.

IOActive has operated in industrial control environments since building the first proof-of-concept worm against the smart grid in 2009 [10], and has helped define standards and best practices including NIST 800-53 and 800-37. The services below map to the specific gaps the 2030 baseline leaves open.

Full Stack Security Assessments

Government has confirmed that Cyber Essentials Plus excludes operational technology and that applying its controls to SCADA systems, programmable logic controllers, human machine interfaces and remote telemetry units can be unsuitable. Our Full Stack assessments examine the whole environment rather than a single layer, covering the controllers and HMIs at distribution-connected sites, the OT/IT boundary, and the cellular and vendor paths that commonly provide unmanned generation assets with connectivity nobody has inventoried. Where the baseline will eventually ask for evidence, an assessment produces it rather than assuming it.

Hardware and Firmware Security Research

The assets in question are largely unmanned and remotely operated, which places the security of the controller and telemetry unit itself in scope rather than only the network around it. Our hardware and firmware research examines the devices deployed at these sites directly, at a depth that network-layer testing cannot reach and that no IT-derived certification scheme currently asks for.

Supply Chain Integrity

Consultation respondents named supply chain visibility among the leading controls missing from Cyber Essentials Plus, and identified aggregators, flexibility platforms and remote monitoring providers as the additions most often proposed to the essential services list. Our Supply Chain Integrity work assesses the posture of technology providers and critical third parties, covering firmware, embedded systems, remote access arrangements and procurement, so that inherited risk is identified before it becomes a shared incident. For operators contracting with aggregators and remote service providers, this is the exposure that sits outside their own perimeter and inside their own outage.

Red Team and Purple Team Services

Incident response and exercising was the second most requested addition to the baseline, at 17 respondents. Adversary simulation is how an operator establishes whether an intrusion at a small asset would be detected and contained before it interrupts generation, rather than assuming the segmentation on the network diagram holds under test.

Advisory Services

The 2027 consultations will ask operators to state which systems fall inside a future baseline, which already sit inside NIS scope, and where residual OT exposure lies. That is a scoping determination an operator has to be able to defend, not describe. Our Advisory Services cover programmatic security review, security programme development and management, and Virtual CISO support, and the output is a documented scope position for each asset, a remediation sequence with named owners and dates, and the evidence pack a board or regulator will ask for.

If you would like to discuss where your generation or distributed energy assets sit against the thresholds described in this post, and what the residual OT exposure looks like, we welcome the conversation.

What are the Recommended Next Steps for Operators?

Establish the regulatory position of every generating asset in the portfolio, including cumulative group capacity and whether the connection is to a transmission or a distribution system, and record the basis for each determination.
Treat the 2030 baseline as a floor rather than a target, and assess the estate against an OT-aware framework such as IEC 62443 or the NCSC Cyber Assessment Framework rather than waiting for licence conditions to be drafted.
Inventory remote access into unmanned sites, including vendor and maintenance pathways, and verify that segmentation between corporate IT and control networks holds under test rather than on the network diagram.
Extend incident response plans to cover loss of generation at a sub-threshold asset, and exercise them, given that incident response and exercising was the second most requested control in the consultation.
Review contractual cyber security obligations with aggregators, flexibility platforms and remote monitoring providers, several of which may be brought into NIS scope during the 2027 review.
Engage with the Ofgem consultation expected during 2027, since the additional controls that sit above Cyber Essentials Plus are still being designed and sector evidence will shape them.

Conclusion

The regulatory perimeter for British electricity generation was drawn around a small number of very large assets in 2018, for an energy system that no longer exists. Government has recognised this, commissioned advice on where the line should move, and committed to a baseline for every Ofgem licensee by the end of 2030. That work is welcome and it is also four years away, and the scheme chosen as its foundation does not currently reach operational technology.

Operators that have already been targeted do not have four years, and press analysis published a month after the incident concluded that Britain’s small power plants face continued cyber risk. [7] The organisations that come through the next phase in good order will be those that treat the 2030 baseline as the minimum they will eventually be asked to evidence, and build OT security ahead of it on their own timetable.

References

The Register, “Iran-linked cyberattack shut down a UK power plant”, 24 August 2026, carrying the Department for Energy Security and Net Zero statement on the small-scale energy generator incident. https://www.theregister.com/security/2026/08/24/iran-linked-cyberattack-shut-down-a-uk-power-plant/ First reported by The Sunday Telegraph, 22 August 2026 (paywalled).
The Network and Information Systems Regulations 2018, Schedule 2, U.K. Essential Services and Threshold Requirements. https://www.legislation.gov.uk/uksi/2018/506/schedule/2 (revised text as in force at 2 September 2026).
Department for Energy Security and Net Zero and Ofgem, “Reshaping cyber regulation in downstream gas and electricity: government response”, 5 August 2026. https://www.gov.uk/government/consultations/whole-energy-cyber-resilience-requirements-reshaping-cyber-regulation-in-downstream-gas-and-electricity
Department for Energy Security and Net Zero, Ofgem, NCSC and NESO, “Energy Sector Cyber Security Strategy”, 28 May 2026. https://www.gov.uk/government/publications/energy-sector-cyber-security-strategy/energy-sector-cyber-security-strategy
Department for Energy Security and Net Zero and Ofgem, “Reshaping cyber regulation in downstream gas and electricity: consultation document”, 27 March 2026. https://assets.publishing.service.gov.uk/media/69c51142471d520038d0f68d/whole-energy-resilience-consultation-document.pdf
CERT Polska, “Energy Sector Incident Report – 29 December”, published January 2026. https://cert.pl/en/posts/2026/01/incident-report-energy-sector-2025/ (full report: https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf). See also CERT Polska, “Follow-Up Report of the December 2025 Energy Sector Incident”, August 2026. https://cert.pl/en/posts/2026/08/incident-follow-up-report-energy-sector-2025/
The Guardian, “UK’s small power plants face continued cyber risk after Iran-linked hack”, 27 August 2026. https://www.theguardian.com/business/2026/aug/27/uk-small-power-plants-risk-cyber-attacks-iran-hack
Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32, introduced to Parliament 12 November 2025. Lords Second Reading 14 July 2026, Lords Committee Stage from 1 September 2026. https://bills.parliament.uk/bills/4035
National Cyber Security Centre, Cyber Essentials. https://www.ncsc.gov.uk/cyberessentials/overview
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 | October 20, 2026

Cyber Risk Management Strategies for Enterprises

By Christian Powills

“The most effective cyber risk management strategies prioritize business impact alongside technical risk.” – IOActive Security Team

The strongest cyber risk management strategies begin with a business question. Which failures could stop a critical business service, harm people, cut revenue, or damage trust? A list of flaws cannot answer that question. Leaders need to see how weaknesses combine, which services they threaten, and what action will cut the risk.

This framework focuses on five decisions:

Link technical risk to business impact.
Test real attack paths through offensive security assessments.
Treat third parties and Operational Technology (OT) as business dependencies.
Set risk rules for each AI use case.
Make continuous validation part of governance.

Use this framework during annual planning, major technology changes, supplier reviews, and new AI approvals. It gives executives a shared way to rank risk. It provides technical teams with a testable set of assumptions and service owners with a clear role. The result is a shorter path from a security finding to a funded business decision. It also helps separate risks that need immediate action from risks that can be tracked.

Start With Business Impact, Not a Finding Count

The NIST Cybersecurity Framework (CSF) 2.0 organizes security work into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Together, these functions help a company set priorities, reduce risk, spot failures, respond to incidents, and restore key services. They become most useful when the organization applies them to the services it must keep running.

Start with the services the business must protect. A factory may depend on production uptime, safe machine control, maintenance access, and a safe stop. A bank may depend on payments, administrative access, market links, and customer login. The same flaw can demand a different response based on its place in that service chain.

Business Impact Risk Prioritization Matrix

Decision factor	Low	Medium	High
Business impact	Local inconvenience	Service degradation	Safety, revenue, or regulated-service interruption
Attack path	Rare conditions required	Several prerequisites	Direct or demonstrated path
Control confidence	Tested and reliable	Partly validated	Unknown, bypassed, or contradicted by evidence
Dependency exposure	Isolated asset	Shared service	Single point of failure
Time to consequence	Weeks or months	Days	Hours or less
Executive action	Track and review	Fund targeted reduction	Escalate, assign an owner, and set a deadline

Use the matrix to direct resources toward paths that could interrupt a critical business service. A demonstrated path to that service deserves faster action than an isolated flaw on a test system.

Test the Risk Model Through Offensive Security Assessments

A risk model contains assumptions. It assumes that a control will block an attack, a team will spot it, and a restore process will work under pressure. An offensive security assessment tests those assumptions. It checks whether an attacker can connect separate weaknesses into a path to a critical business service.

A flaw scan may find an exposed system, but it does not show what an attacker can do with that access. An offensive assessment goes further: Which account or network boundary does the access bypass? What can the attacker reach? Could the result affect the business?

This distinction also clarifies the roles of Red Team and Purple Team engagements. Red Team work simulates adversary behavior, while Purple Team work brings offensive and defensive teams together to test controls, improve detection, and close response gaps.

A well-scoped assessment should answer four questions:

Can an intruder reach a critical business service? Map the route from first access to the service. Look for account escalation, weak network limits, admin rights, exposed admin tools, and third-party access.
Which controls should stop or flag the path? Name each expected prevention and detection point. Then name its owner and the proof that it worked.
How quickly would the company know? Compare alert and triage time with the time an attacker would need to cause harm. Look for blind spots and unclear response paths.
What action would limit harm? Define the contain, restore, or safe-stop action that protects the service under attack conditions.

IOActive’s research covers embedded devices, industrial control systems, aviation systems, vehicles, hardware, and connected products. That research can expose gaps where software, hardware, physical access, and safety meet.

Treat Third Parties and Operational Technology (OT) as Business Dependencies

Third-party risk should not stop at a questionnaire or contract clause. Cloud platforms, managed service firms, software suppliers, industrial integrators, and logistics partners may hold access, support a critical business service, or affect restoration if the company cannot replace them quickly.

For each third-party dependency, document what the party can see, change, or stop. Then assess its access path, data exposure, restore role, single points of failure, and exit options. The 2025 Verizon Data Breach Investigations Report found that third parties were involved in 30% of the breaches analyzed. That was twice the prior year’s share.

Operational technology (OT) needs the same business lens, with extra attention to safety, uptime, physical processes, and change control. Review asset lists and network separation with operators and engineers, not only with IT staff. CISA links accurate OT asset knowledge with security, maintenance, and uptime. CISA and its partners also recommend limiting OT access to what each user needs.

Third-Party and OT Evidence Matrix

Dependency	Evidence to request	Decision it should support
Cloud or SaaS provider	Recovery evidence, access review, and logging coverage	Whether the service can support a critical process
Managed service provider	Privilege map, access approvals, and logging test	Whether provider access is limited and observable
Software supplier	Update checks and vulnerability handling	Whether updates create unacceptable exposure
Industrial integrator	OT attack-path review and remote-access controls	Whether maintenance access could affect safe operations
Logistics partner	Alternate-process test and dependency map	Whether the business can continue during supplier failure

Use the evidence to set a fix, name the risk owner, and test the restore plan where needed.

Govern AI Adoption by Use Case

AI is not a single risk category. A public chatbot, coding assistant, customer-facing model, and plant-support application have different users, data, permissions, failure modes, and business impact. Treating them as one program can hide the controls each use case needs.

NIST’s AI Risk Management Framework supports managing AI risks during development and use. Before approval, the owner should state the purpose, users, and data access. The owner should also define decision power, likely misuse, human checks, logs, and a rollback plan. IOActive’s AI security services describe support from concept through deployment. That lifecycle view helps teams test risk during buying, data preparation, model use, integrations, and live operations.

AI Use-Case Risk Gate

AI gate	Evidence to request	Approval question
Purpose	Business outcome and affected users	Is the use case necessary and bounded?
Data	Permissions, retention, and sensitive content	Can the system access only needed data?
Behavior	Abuse cases, output tests, and failure modes	What could it produce or recommend incorrectly?
Authority	Actions the system can recommend or initiate	Which actions require human approval?
Resilience	Monitoring, rollback, and incident playbook	How will the team stop or restore it?

Approved systems still need checks after launch. A change in the model, data, integration, user group, or authority can change the risk.

Make Continuous Validation Part of Cyber Risk Management Strategies

A risk plan loses value when its proof becomes old. Systems change. Third parties gain access. Cloud accounts grow. AI goes live. New research changes a threat model. A control that worked during a test may not protect the same critical business service after a design or process change.

Continuous checks do not mean scanning every system at all times. They mean checking the controls that protect critical business services. NIST CSF 2.0 treats security risk management as an ongoing practice. It includes continuous monitoring within the Detect function.

Continuous Validation Trigger Matrix

Trigger	Validation action	Owner or participant
Major design change	Update attack paths and control assumptions	Security architecture and service owner
New third-party access	Review privileges, logs, and restore dependency	Vendor owner and security
AI system enters production	Test abuse cases, permissions, logs, and rollback	AI owner, privacy, and security
OT process or firmware change	Review safety limits, network separation, and remote access	Engineering, operations, and security
Completed fix	Retest the original attack path and remaining access	Control owner and assessor

For board and executive reports, track the share of critical business services with tested attack paths and overdue high-priority fixes. Also track time to detect and contain a tested path and the share of restore exercises that meet their goals.

Put Cyber Risk Management Strategies Into Practice

The most effective cyber risk management strategies connect technical evidence to business consequences. IOActive combines threat research, adversarial testing, and security advice to help organizations test the assumptions behind their plans.

Explore IOActive’s Red Team services for enterprise attack-path validation

Sources

INSIGHTS | October 16, 2026

Signal Messenger Security: A Research Case Study

By IOActive

SetWindowDisplayAffinity code on signal to receive no display error.

Signal Messenger is widely recognized for protecting private communications, but secure messaging depends on controls beyond encryption. This Signal Messenger security case study examines how IOActive tested Signal Desktop’s Windows screen-capture protection and what the results reveal about evaluating application controls against realistic attacker capabilities.

Signal Messenger Security: At a glance

Problem

Signal Desktop’s Windows content-protection feature prevents the application window from appearing in screenshots and screen recordings. However, the control relies on the assumption that only Signal’s own process will change the window’s display-affinity setting.

Solution

IOActive traced the feature from Signal’s open-source code through Electron and the Windows graphics stack, then tested whether the protection could be removed from outside the application. The team also analyzed the Windows ownership check that enforced the control.

Results

Direct calls from another process failed, including calls from an administrator process. IOActive successfully removed the protection by executing the relevant API call within Signal’s process using CreateRemoteThread, demonstrating that local code execution can undermine this type of defense-in-depth control.

“Security controls should be tested against the conditions attackers can create, not only the conditions they were designed to handle.”

The security control under review

The investigation began when IOActive Senior Security Consultant Taha Draidia noticed that Signal Desktop was missing from a screen-sharing session. Signal Desktop is built with Electron, and its publicly available source code exposed the relevant contentProtection setting. A search of the code identified the call to window.setContentProtection(contentProtection), which enables or disables the feature.

According to the Electron BrowserWindow documentation, enabling content protection on Windows maps to the Windows API SetWindowDisplayAffinity, using the WDA_EXCLUDEFROMCAPTURE flag. On supported Windows versions, this excludes the application window from screen captures. On older versions, the behavior falls back to displaying a black rectangle.

The control is implemented below the application interface, in the Windows desktop and graphics stack. That makes it more difficult to defeat through ordinary application settings, but it does not make the control independent of the endpoint’s security state.

How IOActive tested the protection

The research team first identified Signal’s top-level window and obtained its window handle. The Windows APIs EnumWindows, GetWindowTextW, and GetWindowThreadProcessId can be combined to locate a window by its title and associated process.

The relevant function accepts a window handle and an affinity value:

WDA_NONE, which removes the capture restriction
WDA_MONITOR, which limits content to a monitor
WDA_EXCLUDEFROMCAPTURE, which excludes the window from capture

IOActive evaluated three ways to remove the restriction.

Research phase	Method tested	Result	Security lesson
1	Call SetWindowDisplayAffinity(hwnd, WDA_NONE) from another process	Rejected with ERROR_ACCESS_DENIED	A valid window handle does not automatically grant permission to change every property associated with that window.
2	Repeat the call from an elevated administrator process	Rejected with the same error	The control is based on process ownership, not simply administrator privilege.
3	Execute the API call within Signal’s process using CreateRemoteThread	Successful	Legitimate APIs can be combined with process injection to satisfy an ownership check that blocks cross-process calls.

Sources for the table: IOActive’s original research, Microsoft’s SetWindowDisplayAffinity documentation, and Microsoft’s CreateRemoteThread documentation.

Why the first attempts failed

The first attempt was straightforward: identify Signal’s window and call SetWindowDisplayAffinity from a separate process. Windows rejected the request with ERROR_ACCESS_DENIED.

IOActive repeated the test from a process running with administrator privileges. The result did not change. Elevation was not enough because the check was not primarily evaluating whether the caller was an administrator. It was evaluating whether the caller belonged to the process that owned the target window.

The test exposed an important assumption behind the control. A security control may correctly enforce its documented API contract while still depending on a broader assumption about the endpoint. In this case, the control expected the API call to originate from Signal’s own process. It did not establish a stronger boundary against an attacker who could execute code in that process.

The successful bypass

The third approach used CreateRemoteThread to execute the display-affinity call inside Signal’s process context. The proof of concept is available in our public GitHub repository.

Because the call originated within Signal’s process, the process-ownership check was satisfied. The protection was then removed without requiring the API call to come from an administrator process.

This result does not mean Signal’s end-to-end encryption was broken. The research evaluated a Windows desktop presentation control, not Signal Messenger’s cryptographic design. The finding demonstrates that screen-capture protection is a defense-in-depth measure whose effectiveness depends on the integrity of the local endpoint.

Confirming the assumption through kernel analysis

IOActive did not stop after demonstrating the behavior. The team reverse-engineered the Windows implementation to understand why the first two approaches failed.

The user-mode call chain leads from user32!SetWindowDisplayAffinity to the NtUserSetWindowDisplayAffinity system call. The ownership enforcement occurs deeper in the Windows graphics subsystem. The kernel compares the process associated with the target window against the process associated with the calling thread. If those values differ, Windows returns ERROR_ACCESS_DENIED.

A remote thread changes that condition by causing the API call to execute inside the target process. The bypass does not defeat the ownership comparison directly. It satisfies the comparison by moving execution into the process that owns the window.

IOActive also examined research into the Desktop Window Manager, including the DWMShield proof of concept, which reaches the internal graphics routine responsible for applying the capture-exclusion state. Together, these paths illustrate that a control enforced in the graphics stack can still be affected by code execution elsewhere in the operating system.

What this case study means for product security

This Signal Messenger security investigation offers several lessons for software and product teams:

First, application security controls should be evaluated against the actions available to a local attacker, not only ordinary user behavior. If an attacker can execute code within a trusted process, controls that rely on process identity may no longer provide the intended protection.

Second, API-level correctness is not the same as system-level resilience. SetWindowDisplayAffinity correctly rejects unauthorized cross-process calls. The weakness lies in combining that control with another legitimate capability: process injection.

Third, security testing should follow a control through its complete implementation path. IOActive combined source-code review, API analysis, Windows internals research, reverse engineering, and offensive testing. That combination exposed an assumption that would have been difficult to identify through surface-level functional testing alone.

Finally, screen-capture protection should be treated as one layer in a larger endpoint security strategy. It can reduce casual or routine capture, but it cannot replace endpoint protection, application hardening, monitoring, and defenses against local code execution.

Signal Messenger Security: Major takeaways

IOActive’s research into Signal Desktop shows why product security requires more than verifying that a security setting works under normal conditions. The screen-capture control performed as designed against ordinary capture attempts and rejected direct calls from standard and elevated external processes. However, deeper testing showed that code executing within Signal’s own process could remove the restriction.

The case study positions Signal Messenger security within a broader engineering principle: security controls must be tested against the conditions an attacker can create. IOActive’s work across application security, reverse engineering, Windows internals, and offensive testing shows how research-led testing can reveal the difference between a control that works as documented and a control that remains effective under realistic attack conditions. It also demonstrates how IOActive goes above and beyond to find the root cause of important cybersecurity threats, with a research-led workflow that makes them one-of-a-kind in the industry.

Need to evaluate your own application security controls against realistic attacker capabilities? Contact IOActive to discuss Signal Messenger security, product security research, and advanced offensive testing.

INSIGHTS | October 13, 2026

From 30 Systems to Over 100: What CISA’s Revised Water Sector Figures Reveal About the OT Detection Gap

By IOActive

Key Takeaways

CISA has revised the scale of the July 2026 water sector campaign from the roughly 30 systems described by federal law enforcement at the time to more than 100 internet-exposed systems across at least 12 US states [1] [3].
The revised figure originated with CISA’s own observation, published on 21 August 2026 in exposure reduction guidance, rather than with incident reports submitted by the affected utilities [1] [3].
CISA has warned that the cellular modems involved may have been installed by operators, vendors or system integrators, and may not be documented or included in routine attack surface scans [4].
The UK position is structurally similar. The Drinking Water Inspectorate received five cyber incident reports from water suppliers between January 2024 and October 2025, all concerning systems outside NIS scope and all submitted voluntarily rather than under a legal duty [5].
Reporting obligations under the UK NIS Regulations, the Cyber Security and Resilience Bill and EU NIS2 are all triggered by the operator becoming aware of an incident. Lowering a reporting threshold does not close a detection gap.

Why Do the Revised Figures Matter Now?

Malicious activity against US water and wastewater systems began on 26 July 2026 [2]. In the weeks that followed, federal law enforcement described a campaign affecting approximately 30 water systems in Minnesota and a small number of other states [2].

On 21 August 2026, CISA published internet exposure reduction guidance stating that during July 2026 it had observed malicious cyber activity targeting over 100 internet-exposed systems in the Water and Wastewater Systems (WWS) Sector, commonly via programmable logic controllers connected directly to a cellular modem [1] [6]. Until that publication, federal agencies had not publicly quantified the number of systems affected [3].

The figure moved by a factor of more than three, roughly four weeks after the activity began, and it moved on the strength of an agency observation rather than a sector disclosure.

Reporting has linked the campaign to Iranian threat actors, and federal law enforcement indicated at the time that the activity was consistent with previous Iranian state-sponsored operations [2] [3]. CISA’s exposure reduction guidance describes the activity without naming an actor [1]. Attribution in this case remains contested rather than settled, and the analysis that follows does not depend on it.

The geographic picture is similarly incomplete. The US government has not stated how many states were affected, although at least 12 appears to be the working figure, with Minnesota, Michigan, South Dakota, Georgia, New Jersey and Alabama confirmed publicly [3]. Illinois does not appear on the list, but Illinois also has no regulation requiring water systems to notify law enforcement or the public of a computer intrusion [2]. Absence from a published list is not evidence of absence where no duty to report exists.

What Does the Revision Actually Show?

The number did not change because the campaign grew. It changed because the observer’s picture improved. Three features of the revision are worth separating.

The figure came from the observer, not the observed.

CISA stated that it observed the activity. That language points to agency telemetry, scanning and partner reporting rather than to aggregated victim notifications. A figure derived from what the observer could see is a measure of the observer’s reach, and it sets a floor rather than a ceiling.

The assets were not in the inventory.

In its 30 July 2026 alert, CISA advised that even water organisations with mature cyber security processes should validate their external connections, because the targeting included cellular modems installed by operators, vendors or system integrators that may not be documented or included in routine attack surface scans [4]. This is the mechanism behind the revision. A controller connected directly to a cellular modem has no route through the corporate network. It is internet-facing without being enterprise-facing, so an external attack surface management tool working from the organisation’s registered domains and IP ranges will not enumerate it.

Detection depended on process behaviour rather than security monitoring.

In the Minnesota incidents, utilities appear to have avoided serious consequences largely because staff noticed abnormal control behaviour and reverted to manual operation [7]. That is a real outcome and it reflects operational competence, but it is a thin margin, and it is not a security control in any repeatable sense. It also flatters the failure mode. Abnormal automation is an availability signal, and availability signals announce themselves. As we argued in Rethinking the CIA Triad in Operational Technology Environments, integrity failures behave differently, persisting undetected precisely because nothing stops working. An actor who had altered controller logic without disturbing the process would not have been found by the mechanism that found this one.

The structural explanation sits in the shape of the sector. Nearly 49,500 US community water systems fall under the Safe Drinking Water Act, and the EPA classifies around 81 per cent of them as small, meaning they serve 3,300 people or fewer [14]. The statutory duty to conduct a risk and resilience assessment under Section 1433 applies only to systems serving more than 3,300 people, which leaves roughly four in five community water systems outside the requirement altogether [14]. Reporting on the campaign indicates it fell mainly on small and rural utilities [6]. A sector composed predominantly of organisations with no assessment duty and no security function is a sector that will be counted by somebody else.

Who is Affected by the OT Detection Gap?

Water and wastewater operators.

Small and rural US utilities are the most acutely exposed, but the underlying condition is not specific to the United States. UK and EU water companies operate large estates of remote, unstaffed assets including pumping stations, reservoirs and treatment works, many of which report telemetry over cellular links precisely because a fixed connection is impractical. The asset class that CISA describes is the same asset class deployed across British and European water networks.

CNI operators outside the water sector.

Energy, transport and other operators of essential services run comparable distributed estates on comparable connectivity. Joint advisory AA26-097A named Government Services, Water and Wastewater Systems and Energy as directly affected sectors, and expanded the vendor scope from Rockwell Automation to Schneider Electric and Siemens [8]. The inventory blind spot travels with the architecture, not with the sector. Our analysis of the Polish energy sector incident documented the same dynamic through a different exposure route, where a single repeated configuration weakness across more than 30 facilities turned a site-level problem into a fleet-level one, and the full extent only became clear after the fact.

Boards and risk functions.

A sector risk figure that changes by a factor of three within four weeks is not a stable basis for board reporting, insurance placement or investment prioritisation. Anyone who briefed a board in early August on the basis of the initial figure understated the scale of the campaign by more than 70 systems, through no fault of their own. The relevant board question is not what the number is, but how much confidence attaches to it and what would have to be true for it to move again.

Suppliers, system integrators and equipment manufacturers.

CISA specifically identified connectivity installed by vendors and integrators as a category that may not be documented [4]. Remote access introduced during commissioning, or added to support a maintenance contract, can persist long past project handover without appearing in any register the asset owner maintains.

What Challenges Does This Create for Operators and Regulators?

Asset inventories do not contain the assets.

Cellular-connected controllers are frequently procured operationally, by engineering or maintenance functions and against an operational budget, rather than through an IT asset management process. They may never reach a configuration management database. In some estates they exist only in a project file or in an integrator’s records.

External attack surface management does not reach them.

Commercial attack surface tooling starts from an organisation’s known domains and address ranges. A controller sitting behind a mobile network operator’s address space is not in any of them, which means an operator can hold a clean external exposure report and still be internet-reachable. The NCSC made the same point in its alert of 27 August 2026, advising that organisations should not assume their OT is inaccessible from the internet without verifying it, because unintended exposure can arise through misconfigurations, legacy connections or unmanaged assets [13].

Reporting thresholds exclude the activity.

The UK NIS Regulations 2018 limit formally reportable cyber incidents to those that actually result in disruption to an essential service [5]. The July 2026 US campaign did not cause significant service disruption [3]. An equivalent UK campaign would, in many cases, generate no mandatory report at all. The Drinking Water Inspectorate’s experience illustrates this directly. Of 15 reports received from suppliers between January 2024 and October 2025, five concerned cyber security incidents affecting what the Inspectorate described as out-of-NIS-scope systems, and were shared for information because they were considered related to water supply resilience risks rather than because a duty required it [5].

Reform addresses the threshold but not the trigger.

The Cyber Security and Resilience Bill widens the definition of a reportable incident beyond significant disruption to capture incidents capable of significant impact, including pre-positioning, and introduces a two-stage process of initial notification within 24 hours and a full report within 72 hours to the competent authority and the NCSC [9] [10]. EU NIS2 already imposes a 24-hour early warning, a 72-hour notification and a final report within one month on essential entities, a category that includes drinking water and wastewater [11]. Both regimes start the clock when the entity becomes aware of the incident. Where the affected asset is undocumented and unmonitored, awareness may never arrive, and a widened threshold produces no report.

How IOActive Can Help

The revision from roughly 30 systems to more than 100 describes a measurement failure rather than a control failure. Nobody in the sector could state the scale of the campaign while it was running, and the figure that eventually emerged came from an agency looking in rather than from operators looking at themselves. Closing that gap means answering two questions with evidence rather than with documentation. What is actually connected, and would anyone notice if it were used.

IOActive has worked in industrial control environments since publishing the first proof-of-concept worm against the smart grid in 2009. The services below map onto the two questions this campaign leaves open.

Full Stack Security Assessments

The assets at the centre of this campaign were not hidden. They were undocumented, which is a different problem and a harder one, because no amount of scanning an organisation’s own address ranges will surface a controller that reaches the internet through a mobile network. Our Full Stack assessments examine an environment across its layers rather than at a single tier, covering internet-facing controllers and HMIs, the OT and IT boundary, the cellular modem paths that often give a field site its only route out, and the firmware and silicon of the devices themselves. The output is an inventory that has been verified rather than asserted, which is the precondition for every other step recommended below.

Red Team and Purple Team Services

The more uncomfortable question this campaign raises is not whether operators were exposed but whether they would have known. In Minnesota, detection came from control room staff noticing that automation was behaving abnormally [7]. That is a credit to the operators involved and it is not a control any organisation should expect to rely on twice. Adversarial testing answers the question directly, by establishing whether an intrusion at an unstaffed remote site produces a signal that anyone acts on. It is particularly suited to integrity attacks such as altered controller logic, which availability-focused monitoring is not built to catch. Purple team work then converts those findings into detection that the operator’s own staff can maintain, which matters more in operational environments than in enterprise ones because the meaningful signal is frequently a process anomaly rather than a network event. We set out the distinction between the two approaches in Red vs Purple Team, what’s the difference?.

Supply Chain Integrity

CISA was explicit that the cellular modems involved may have been installed by operators, vendors or system integrators, and may never have been documented [4]. That places part of the inventory problem outside the operator’s own records entirely. 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 connectivity introduced during commissioning or under a maintenance contract is identified before it becomes someone else’s route in. For UK operators this maps onto the designated critical supplier powers in the Cyber Security and Resilience Bill [9].

If you would like to discuss how your organisation’s remote OT connectivity and detection coverage measure up against the activity described here, we welcome the conversation.

What Are the Recommended Next Steps for Water and CNI Operators?

Enumerate cellular and out-of-band connectivity as a separate exercise from the IT asset inventory. Network discovery will not find these assets, so the exercise has to be conducted through engineering teams, maintenance schedules and site records.
Interrogate procurement and project documentation for purchases of modems, industrial routers and remote telemetry units, including those made under capital projects and maintenance contracts rather than IT budgets.
Ask every OEM, system integrator and maintenance supplier directly whether connectivity was installed to support their own access, and whether that connectivity remains active.
Apply CISA’s exposure reduction measures to whatever the exercise finds. Disconnect controllers from direct internet exposure, route remote access through a VPN or gateway rather than to the controller itself, enable and change default passwords, allowlist permitted source addresses, and hold a known clean controller image in case an actor changes the device password [1] [4].
Treat process anomalies as a security signal. Define in advance which operational deviations trigger a security escalation rather than only an engineering response, and make sure control room staff know that route exists.
Rehearse the 24-hour notification decision against a scenario involving unauthorised access with no service disruption. Establish who holds the decision that such an event is reportable, and how quickly that decision can be reached out of hours.
Re-baseline the board risk picture once the inventory work is complete, and state explicitly what confidence attaches to the new figure and what would cause it to change.

Conclusion

The revision from roughly 30 systems to more than 100 is the most useful finding to come out of the July 2026 campaign, and it has little to do with the actors involved. It demonstrates that a sector could be targeted at scale, across at least a dozen jurisdictions, without the targeted organisations being the ones to establish how widely it had happened.

Regulatory reform on both sides of the Atlantic is moving in the right direction, widening what must be reported and shortening the time in which it must be reported. None of it changes the fact that a reporting obligation begins with an operator knowing something has occurred. For operators running remote assets on connectivity that nobody has catalogued, the work that closes the gap is inventory work, and it is available to be started now. As we set out in Cyber Attack Trends 2026, the environments an organisation depends on most are routinely the ones it monitors least, and that ordering is a choice rather than a constraint.

References

[1] CISA. Internet Exposure Reduction Guidance. https://www.cisa.gov/resources-tools/resources/exposure-reduction

[2] Goudie, C., Capitanini, L. and Halder, N. Government admits water system cyberattacks were worse than first reported. NBC Chicago, 26 August 2026. https://www.nbcchicago.com/investigations/government-admits-water-system-cyberattacks-were-worse-than-first-reported/3980961/

[3] Kovacs, E. CISA: Over 100 Internet-Exposed Water Systems Targeted in July Cyberattacks. SecurityWeek, 26 August 2026. https://www.securityweek.com/cisa-over-100-internet-exposed-water-systems-targeted-in-july-cyberattacks/

[4] CISA. CISA Urges Water and Wastewater Systems Sector to Protect OT Against Activity Targeting PLCs, 30 July 2026. https://www.cisa.gov/news-events/alerts/2026/07/30/cisa-urges-water-and-wastewater-systems-sector-protect-ot-against-activity-targeting-plcs

[5] Martin, A. Hackers are attacking Britain’s drinking water suppliers. The Record, 3 November 2025. https://therecord.media/britain-water-supply-cybersecurity-incident-reports-dwi-nis

[6] More than 100 water systems were hit in July cyberattacks. The Register, 26 August 2026. https://www.theregister.com/cyber-crime/2026/08/26/more-than-100-water-systems-were-hit-in-july-cyberattacks/

[7] IOActive. When the Advisory Arrives First: Minnesota’s Water Utilities and the Limits of Warning. https://www.ioactive.com/when-the-advisory-arrives-first-minnesotas-water-utilities-and-the-limits-of-warning/

[8] CISA, FBI, NSA and partner agencies. Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure (AA26-097A), originally published 7 April 2026, updated 22 July 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-097a

[9] House of Commons Library. Cyber Security and Resilience (Network and Information Systems) Bill 2024-26, 2026-27, research briefing CBP-10442. https://commonslibrary.parliament.uk/research-briefings/cbp-10442/

[10] Department for Science, Innovation and Technology. Cyber Security and Resilience (Network and Information Systems) Bill factsheets: Summary of the Bill. https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/summary-of-the-bill

[11] Directive (EU) 2022/2555 (NIS2), Article 23. Incident reporting obligations for essential and important entities.

[12] Federal News Network. CIRCIA, other big cyber rules expected to get finalized this fall, 10 July 2026. https://federalnewsnetwork.com/cybersecurity/2026/07/circia-other-big-cyber-rules-expected-to-get-finalized-this-fall/

[13] NCSC. Disruptive cyber activity highlights risk from internet-exposed systems and edge devices, 27 August 2026. https://www.ncsc.gov.uk/news/disruptive-cyber-activity-highlights-risk-from-internet-exposed-systems-and-edge-devices

[14] Congressional Research Service. Cybersecurity of the Municipal Water Sector: Background and Issues for Congress, report R48556. https://www.congress.gov/crs-product/R48556