INSIGHTS | September 17, 2026

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

By IOActive

Key Takeaways

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

Why Does Internet-Exposed OT Matter Now?

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

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

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

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

What Is Known About the UK Generator Incident?

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

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

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

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

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

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

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

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

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

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

What Do UK Guidance and Regulation Already Require?

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

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

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

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

Who Is Affected by Internet-Exposed OT Risk?

Electricity generation and distribution operators

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

Water and wastewater utilities

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

Manufacturers and process industries

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

Suppliers, integrators and maintenance providers

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

Boards and audit committees

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

What Are the Challenges for Operators?

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

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

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

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

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

How Can IOActive Help?

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

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

Full Stack Security Assessments

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

Supply Chain Integrity

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

Advisory Services

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

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

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

Connect With a Security Expert

What Are the Recommended Next Steps?

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

Conclusion

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

References

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

Cybersecurity Testing Methodologies Compared

By IOActive

Cyber defenses blocking attacks from organizations and infrastructure.

The global average cost of a data breach reached $4.44 million in 2025, the first decline in five years. IBM attributes this largely to faster detection and containment, driven by AI-assisted security tooling and more mature incident response programs.¹ That decline is meaningful, but it does not erase the underlying question that keeps security leaders up at night: if an attacker came for your organization today, would your security program catch it in time?

For buyers comparing cybersecurity testing methodologies, the answer depends entirely on whether the testing approach they have chosen is aligned with the questions they most need to answer. This article compares cybersecurity testing methodologies so security leaders can build testing programs that reflect their risk profile.

Cybersecurity Testing Methodologies Compared

Methodology	Primary Question Answered	Scope	Engagement Duration	Stakeholder Awareness	Best Suited For
Vulnerability Assessment	What weaknesses exist across our systems?	Broad, automated	Hours to days	High	Baseline hygiene, compliance inventory
Penetration Testing	Which weaknesses are actually exploitable?	Targeted, manual	Days to weeks	High	Targeted risk reduction, audit requirements
Red Team Exercise	How would a real attack on our organization play out?	Full-scope, adversarial	Weeks to months	Low (exec only)	Mature programs; resilience validation
Purple Team Exercise	How can offensive findings improve our detection?	Collaborative, controlled	Days to weeks	High	Detection engineering; SOC capability building
Adversary Simulation	Can a specific known threat actor breach our defenses?	Threat-actor specific	Weeks	Low to medium	High-risk sectors; critical asset protection
Security Validation	Are our controls still working the way we think?	Continuous, platform-driven	Ongoing	High	Control drift detection; continuous assurance
Full-Stack Security Assessment	How does our entire attack surface connect?	Comprehensive: hardware, firmware, software, AI	Weeks to months	Medium	Complex environments; hardware and embedded systems

Choosing the Right Cybersecurity Testing Methodology

The decision framework below matches organizational characteristics to the testing methodology most likely to answer the most pressing security questions. In practice, mature security programs combine multiple methodologies: vulnerability assessments for continuous hygiene, penetration testing for targeted risk validation, Red Team or adversary simulation for resilience measurement, and full-stack assessment where the attack surface extends into hardware and embedded systems.

If Your Organization…	Start With	Then Add
Has no formal testing program yet	Vulnerability Assessment	Penetration Testing
Needs to meet a compliance requirement	Penetration Testing	Vulnerability Assessment
Has a functioning security team and wants to test detection	Red Team Exercise	Purple Team Exercise
Wants to improve SOC detection engineering	Purple Team Exercise	Adversary Simulation
Operates in critical infrastructure or OT/ICS environments	Full-Stack Assessment	Red Team Exercise
Has hardware, embedded systems, or AI in production	Full-Stack Assessment	Penetration Testing (firmware/AI)
Needs to test against a specific known threat actor	Adversary Simulation	Red Team Exercise
Needs continuous visibility into control effectiveness	Security Validation	Penetration Testing (periodic)
Is building a multi-year security testing roadmap	Penetration Testing	Red Team, then Adversary Simulation

Vulnerability Assessments

A vulnerability assessment is the foundational layer of any security testing program. Automated scanning tools cross-reference an organization’s systems and software against public databases of known vulnerabilities, producing a ranked list of unaddressed weaknesses. The output is fast and broad: an organization can scan thousands of assets within hours.

What a Vulnerability Assessment Actually Measures

The key limitation is that a vulnerability assessment identifies weaknesses without confirming whether they are exploitable in your specific environment. A critical-severity CVE may be present on a system protected by compensating controls, making its real-world impact far lower than its CVSS score implies. Conversely, a medium-severity finding on a system with elevated privileges may represent a far more serious risk than any automated tool will flag.

When a Vulnerability Assessment Is the Right Choice

Vulnerability assessments are most valuable as a continuous hygiene practice and as a pre-engagement baseline before any manual testing. Organizations pursuing compliance frameworks, including SOC 2, ISO 27001, PCI-DSS, and FedRAMP, typically require documented vulnerability assessments at defined intervals. They are also useful after infrastructure changes for quickly identifying new exposures.

Where It Falls Short

A vulnerability assessment cannot confirm whether your security controls would stop a determined attacker. It produces a list of targets, not a realistic picture of how those targets could be chained into a damaging attack path. Organizations that rely on vulnerability assessments as their primary testing methodology have identified their weaknesses without knowing which ones matter most under adversarial conditions.

Attribute	Vulnerability Assessment
Primary output	Ranked list of CVEs and misconfigurations
Human expertise required	Low to medium
Detection and response testing	None
Compliance value	High
Organizational maturity required	Low
IOActive equivalent	Pre-assessment scanning embedded in full-scope engagements

Penetration Testing: Proving Exploitability

Penetration testing takes vulnerability assessment to the next level by adding the expert human element. A qualified ethical hacker is authorized to discover and exploit vulnerabilities within a defined scope, demonstrating how a real adversary might compromise systems, access sensitive data, or disrupt operations. The objective is not simply to find weaknesses but to confirm which ones carry genuine damage potential.

What Penetration Testing Measures

IOActive’s penetration testing methodology includes vulnerability scanning, brute-force testing, web application exploitation, and social engineering within the stated scope. Because exploitation is included, results show which vulnerabilities pose the most immediate risk, helping security teams prioritize remediation where it matters most. Unlike vulnerability assessments, penetration testing distinguishes confirmed risk from theoretical exposure.

When Penetration Testing Is the Right Choice

Penetration testing is the right methodology when your organization needs to address specific known risk areas, validate controls before or after a major deployment, satisfy a compliance requirement, or build an internal case for remediation investment. It is also the appropriate entry point for organizations that want to move beyond automated scanning but are not yet mature enough to benefit fully from Red Team exercises.

Where It Falls Short

Because internal stakeholders are generally aware that the test is occurring, penetration testing provides limited insight into detection and response capabilities. Security operations teams may respond differently during a known engagement than during an unannounced real-world attack. Penetration testing is also constrained by its defined scope, meaning attack paths that cross into hardware, embedded firmware, AI pipelines, or physical access controls are typically not evaluated unless the engagement is scoped to include them.

Attribute	Penetration Testing
Primary output	Exploitability-confirmed vulnerability list with remediation guidance
Human expertise required	High
Detection and response testing	Limited (scope-dependent)
Compliance value	Very high
Organizational maturity required	Low to medium
IOActive equivalent	Application, network, hardware, AI, and embedded systems penetration testing

Red Teaming: Testing Resilience, Not Just Vulnerabilities

A Red Team exercise is a full-scope adversarial simulation in which a group of expert ethical hackers emulates a real-world threat actor, attempting to compromise the organization’s most critical assets without detection. Unlike penetration testing, the Red Team operates covertly, its existence known only to select executives. It is not constrained by a predefined list of targets or a scoped attack surface.

What Red Team Exercises Measure

IOActive’s Red Team exercises use threat intelligence and threat modeling to create representative attack scenarios aligned to the organization’s industry, assets, and actual adversary landscape. The exercise tests not just whether vulnerabilities exist but whether your people, processes, and technologies work together to prevent, detect, and respond to a sophisticated, persistent attacker. The output is a realistic resilience scorecard, not a vulnerability inventory.

When Red Teaming Is the Right Choice

Red Team exercises deliver their highest value for organizations with mature security programs: those that already have a functioning vulnerability management process, a dedicated security operations function, and defined incident response procedures. Without this foundation, a Red Team exercise will surface the same basic issues that a penetration test would have identified at lower cost and in less time.

Where It Falls Short

Red Team exercises require significant time and investment, spanning weeks to months. They are also less effective at producing a comprehensive vulnerability inventory: the Red Team’s objective is adversarial impact, not exhaustive coverage. Organizations in earlier stages of security maturity often extract more value from a penetration test before committing to a full Red Team engagement.

Attribute	Red Team Exercise
Primary output	Attack narrative, detection gap analysis, resilience scorecard
Human expertise required	Very high
Detection and response testing	Comprehensive
Compliance value	Medium
Organizational maturity required	High
IOActive equivalent	Full-scope Red Team with threat intelligence, physical access, and social engineering

Purple Teaming: Turning Offense Into Defensive Improvement

Purple Teaming combines the offensive capabilities of a Red Team with the defensive knowledge of the organization’s security operations function in a structured, collaborative exercise. Rather than attacking covertly, the exercise operates transparently: the Red Team executes techniques, the Blue Team observes its own detection capability in real time, and both sides work together to improve visibility and response. The goal is to build detection capability directly from the findings.

What Purple Team Exercises Measure

Purple Team exercises answer the question: “Are our detection controls catching the techniques attackers are actually using against organizations like ours?” The output includes confirmed detections, confirmed gaps, SIEM tuning recommendations, alerting threshold adjustments, and an empirical measurement of SOC capability against specific attack techniques mapped to MITRE ATT&CK.

When Purple Teaming Is the Right Choice

Purple Teaming is the right methodology when your organization wants to improve its security operations capability, validate that new security tooling is correctly configured, or build internal detection engineering skills. It is particularly valuable as a structured follow-up after a Red Team engagement surfaces detection gaps, or as a more cost-efficient approach to testing specific threat scenarios without conducting a full covert Red Team exercise.

Where It Falls Short

Because the exercise is collaborative and transparent, it cannot test true detection capability under realistic conditions where defenders don’t know an attack is in progress. It also requires a sufficiently capable internal security team to be meaningful: organizations without a functioning SOC or detection engineering practice will find Purple Team exercises difficult to execute and difficult to learn from.

Attribute	Purple Team Exercise
Primary output	Detection gap analysis, control tuning recommendations, SOC capability benchmarks
Human expertise required	High (both offensive and defensive)
Detection and response testing	Focused and empirical
Compliance value	Medium
Organizational maturity required	Medium to high
IOActive equivalent	Collaborative red/blue exercises aligned to MITRE ATT&CK

Adversary Simulation: Testing Against the Threats That Target You Specifically

Adversary simulation is a targeted form of Red Teaming in which the testing team emulates the specific tactics, techniques, and procedures (TTPs) of a known threat actor relevant to the organization’s industry or threat landscape. Rather than operating as a generic attacker, the simulation team behaves as a specific threat group would: using the same initial access methods, persistence mechanisms, lateral movement techniques, and exfiltration approaches documented in real-world intelligence reporting.

What Adversary Simulation Measures

Adversary simulation answers the question: “Could the threat actors most likely to target our industry actually succeed against our defenses?” It is grounded in threat intelligence rather than generic attacker methodology, which makes the findings more directly actionable for security operations teams building detections and defenses against specific actor profiles.

When Adversary Simulation Is the Right Choice

Adversary simulation is the right methodology for organizations in high-risk sectors, including financial services, critical infrastructure, government, healthcare, and defense, where the threat actor landscape is well-defined, and the consequences of a successful targeted attack are severe. It is also appropriate for organizations that have completed multiple Red Team exercises and want to test against increasingly specific and sophisticated threat profiles.

Where It Falls Short

Adversary simulation requires high-quality, current threat intelligence to be effective. Simulations built on outdated or generic actor profiles may not reflect the organization’s actual threat landscape. Organizations operating in sectors where actor TTPs evolve rapidly need to ensure simulation frameworks are continuously refreshed to remain accurate.

Attribute	Adversary Simulation
Primary output	Threat-actor-specific attack narrative and detection coverage assessment
Human expertise required	Very high
Detection and response testing	Comprehensive and threat-specific
Compliance value	Medium to high (sector-specific frameworks)
Organizational maturity required	High
IOActive equivalent	Threat-intelligence-led emulation aligned to MITRE ATLAS and ATT&CK

Security Validation: Continuous Testing for Mature Programs

Security validation, often delivered through breach and attack simulation (BAS) platforms, is a continuous or high-frequency testing approach that regularly executes simulated attack techniques against an organization’s controls to confirm they are functioning correctly. Unlike periodic point-in-time assessments, security validation creates an ongoing signal about control effectiveness as the environment changes.

What Security Validation Measures

Security validation answers the question: “Are the controls we deployed still working the way we think they are?” Environments change constantly: new systems are added, configurations drift, patches create unexpected side effects, and threat actor techniques evolve. A control that was effective six months ago may have degraded without anyone noticing. Security validation surfaces that drift before an attacker exploits it.

When Security Validation Is the Right Choice

Security validation is the right methodology for organizations with mature, complex environments where control drift is a real operational risk, particularly those with large distributed infrastructure. It is most valuable as a complement to periodic manual testing, not as a replacement. Point-in-time penetration tests and Red Team exercises provide the depth and creative adversarial thinking that automated platforms cannot replicate; continuous validation fills the coverage gap between those engagements.

Where It Falls Short

Security validation platforms execute known, documented attack techniques. They cannot discover novel attack paths, evaluate physical access controls, test the human element, or assess the creative chained attack scenarios that skilled adversarial testers consistently identify. Treating security validation as a substitute for manual testing creates a significant and predictable coverage gap.

Attribute	Security Validation
Primary output	Control effectiveness dashboard, drift alerts, trend benchmarks
Human expertise required	Low to medium
Detection and response testing	Continuous, technique-specific
Compliance value	High for continuous monitoring requirements
Organizational maturity required	Medium to high
IOActive equivalent	Baseline reference tool within broader assessment programs

Full-Stack Security Assessment: When Surface-Level Testing Isn’t Enough

Most cybersecurity testing engagements operate within a defined layer: application security, network infrastructure, or cloud environments. Full-stack security assessment examines how vulnerabilities and attack paths span multiple layers simultaneously, including hardware, firmware, embedded systems, AI and machine learning pipelines, physical infrastructure, and enterprise applications. It is the methodology appropriate for organizations whose risk surface extends beyond the software-defined perimeter.

Why the Full Stack Matters

Modern enterprise environments are not purely software-defined. Connected devices, industrial control systems, SATCOM terminals, autonomous vehicles, medical equipment, AI-enabled workflows, and physical access infrastructure all create attack paths that single-layer testing does not examine. When an attacker who compromises a network edge device can pivot into an operational technology environment, or when a manipulated AI model can influence production decisions, a network-only penetration test leaves the most consequential attack paths untested.

IOActive’s Full-Stack Advantage

This is where IOActive’s approach diverges from most security testing providers. With physical hardware labs in Seattle, Madrid, and Cheltenham, and 25-plus years of research spanning cloud stacks, connected vehicles, integrated circuits, SATCOM terminals, embedded firmware, and AI systems, IOActive provides full-stack assessments that few firms globally can replicate.² The AMD Sinkclose vulnerability, the Tesla Model Y NFC relay attack, the Raspberry Pi RP2350 challenge win, and the Reviver digital license plate jailbreak are examples of research that reflects this depth across hardware, firmware, and software layers simultaneously.²

When Full-Stack Assessment Is the Right Choice

Full-stack assessment is the right methodology for organizations in manufacturing, automotive, aerospace, critical infrastructure, healthcare, and financial services, where the attack surface includes physical systems, proprietary hardware, embedded software, and operational technology alongside enterprise infrastructure. It is also appropriate for any organization whose AI-enabled applications interact with production systems, financial workflows, or sensitive data at scale.

Attribute	Full-Stack Security Assessment
Primary output	Cross-layer attack path analysis, hardware and firmware findings, remediation roadmap
Human expertise required	Exceptional, cross-disciplinary
Detection and response testing	Comprehensive across all tested layers
Compliance value	High for regulated industries
Organizational maturity required	Medium to very high
IOActive equivalent	Hardware, firmware, AI, embedded, network, application, and physical testing

With 25-plus years of independent security research and physical testing labs on three continents, IOActive brings the adversarial expertise and full-stack depth that complex security programs demand.

Schedule a Security Assessment Consultation with IOActive

Frequently Asked Questions

How often should organizations conduct penetration tests?

Most security frameworks recommend annual penetration testing at a minimum. Organizations with active development pipelines, frequent infrastructure changes, or strict compliance requirements may need semi-annual or continuous testing. IBM’s 2025 breach cost data confirms that faster detection and containment produce measurable cost reduction, which makes regular, rigorous testing a direct financial risk management investment.¹

Is a Red Team exercise always more valuable than a penetration test?

No. A Red Team exercise answers different questions, not better ones. For organizations in early security maturity stages, a Red Team engagement will surface the same basic issues a penetration test would have identified at a fraction of the cost and duration. Red Team exercises deliver their highest value when an organization already has a functioning security operations capability and needs to validate it under realistic, sustained adversarial pressure.

Can a single engagement combine multiple methodologies?

Yes. A well-scoped full-program assessment from a firm like IOActive can combine penetration testing, adversary simulation, hardware assessment, and elements of Red Teaming within a single engagement. The key is scoping around the organization’s most important security questions, not selecting a methodology and fitting the questions to it afterward.

What distinguishes a full-stack security assessment from a standard penetration test?

A standard penetration test evaluates exploitability within a defined scope, typically application code, network infrastructure, or cloud configuration. Full-stack assessment examines how vulnerabilities and attack paths connect across hardware, firmware, embedded software, AI pipelines, physical infrastructure, and enterprise applications simultaneously. It is appropriate for any organization whose risk surface extends beyond software-defined boundaries, which now describes most Global 1000 enterprises with connected devices, operational technology, or AI-enabled business processes.

Sources

IBM. “Cost of a Data Breach Report 2025.” ibm.com/reports/data-breach
IOActive. “IOActive Research Timeline.” ioactive.com/ioactive-research-timeline/

INSIGHTS | September 11, 2026

Worse Than First Reported: What CISA’s Revised Water Sector Numbers Mean for Every Utility

By IOActive

Key Takeaways

CISA has confirmed that the July 2026 campaign against US water utilities targeted more than 100 internet-exposed systems across at least 12 states — over three times the roughly 30 Minnesota systems disclosed when the story first broke ^[2][4].
Georgia, Michigan, South Dakota and New Jersey have since confirmed their own incidents, including a precautionary boil-water advisory at a Georgia utility that was lifted after testing showed no water quality impact^[5].
A second, separate joint advisory (AA26-231A), published August 19, describes threat actors using AI-generated exploitation scripts, disguised as legitimate monitoring tools, to probe internet-exposed Siemens S7 PLCs across six critical infrastructure sectors — reconnaissance and capability development, not yet confirmed disruption ^[6].
CISA followed up on August 21 with exposure-reduction guidance repeating, in near-identical language to April’s advisory, that PLCs should never be reachable directly from the internet through a cellular modem ^[3].
The revised numbers surfaced in a reporting vacuum: the federal CIRCIA rule that would mandate incident reporting for water utilities is still not final, with CISA now targeting September 2026, and at least one major state (Illinois) has no requirement at all for a utility to disclose a hack to the public or to law enforcement ^[9][2].

Why This Update Matters Now

Our first analysis of this campaign treated the Minnesota incidents as a measurement problem: how much distance sits between a federal advisory being issued and a utility being able to act on it. A month later, CISA has revealed that the measurement itself was wrong. The number of affected systems was not roughly 30. It was more than 100, spread across a dozen states, and the agency is only now saying so publicly ^[2][4].

That is not a minor correction. It means that for a month, water sector leaders, state regulators and the public were making risk decisions — about disclosure, about board briefings, about whether “this happened in Minnesota, not here” was a safe assumption — based on a picture that undercounted the actual campaign by a factor of three or more. Officials in the other 11 states now confirmed as targets did not get a warning proportional to what was actually happening in their sector, because no one outside the investigation knew the true scope yet.

Layered on top of that, a second, unrelated advisory has emerged describing attackers using AI-assisted tooling to build exploitation scripts against a specific, widely deployed PLC family. Whether or not that activity is connected to the July campaign, it confirms something water sector leaders should plan around regardless of attribution: the tooling gap between a nation-state operator and a lower-skilled one is narrowing, and it is narrowing fastest against exactly the kind of internet-exposed OT this campaign has repeatedly exploited.

What CISA Actually Confirmed on August 26

Reporting by NBC Chicago’s investigative team surfaced a line from CISA’s own guidance that had not previously drawn attention: “In July 2026, CISA observed malicious cyber activity targeting over 100 internet-exposed systems in the Water and Wastewater Systems (WWS) Sector, commonly via programmable logic controllers (PLCs) connected directly to a cellular modem” ^[2][3]. The Register independently confirmed the same figure and noted it is the first time federal officials have put a specific number on the intrusions, though the campaign still has not been attributed to a named actor or group ^[4].

The 12 states are still not fully identified in public reporting, but Minnesota, Michigan, Georgia, South Dakota and New Jersey have each had incidents confirmed through state or utility disclosures ^[4][5]. In Georgia, Clayton County Water Authority reported a temporary disruption to a portion of its operational systems and water service, and issued a precautionary boil-water advisory that was lifted once testing confirmed water quality was unaffected; a nearby utility, Columbus Water Works, reported a separate cyber incident days later ^[5]. In South Dakota, a utility serving Rapid City reported an incident consistent with the same pattern ^[5]. The FBI, in a joint public service announcement, described the operational effects bluntly: loss of pressure and flooding, with pressure loss creating the potential for untreated groundwater to seep into distribution pipes ^[5].

Illinois has not been named among the 12 affected states. NBC Chicago’s reporting draws out why that distinction may be less reassuring than it sounds: the state has no law requiring a water utility to notify law enforcement or the public after a cyber incident. As the report put it, “the bitter reality is, even if they know, we might not” ^[2]. Illinois is not unusual in this respect. It is a reminder that the 12-state figure reflects what has been detected and voluntarily disclosed, not necessarily the outer bound of what occurred.

Three Federal Advisories in Five Weeks

Operators tracking this campaign have now had to absorb three substantive federal releases in a five-week window, on top of the original April advisory:

July 22 — the update to AA26-097A widened observed Iranian-affiliated PLC targeting from Rockwell to include Schneider Electric and Siemens devices, and added detection guidance for tampered logic modules ^[1].
August 19 — the new joint advisory AA26-231A, authored by NSA, CISA, the FBI, the Department of Energy and the EPA, describes threat actors using AI-generated exploitation scripts disguised as legitimate OT monitoring tools to conduct reconnaissance against internet-exposed Siemens S7 Series PLCs (the S7-200 through S7-1500 families) over the S7comm protocol on TCP port 102 ^[6]. The activity spans Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture and Commercial Facilities ^[7]. CISA’s own advisory text is careful to frame this as reconnaissance and capability development, not confirmed operational disruption, and notes explicitly that the underlying exposure problem is broader than Siemens equipment alone ^[6]. No CVE and no indicator set accompany the advisory; the actionable finding, as several outlets have observed, is unglamorous and predates the AI framing entirely — an unauthenticated industrial protocol reachable from the open internet ^[8].
August 21 — CISA’s Internet Exposure Reduction Guidance restated the same core instruction that has now appeared in every release since April: route remote access through a secure gateway, firewall or VPN, never connect a PLC, HMI or RTU directly to the internet, and require unique credentials and phishing-resistant MFA for anything that must remain remotely reachable ^[3].

None of these three releases describes a new class of vulnerability. Each restates a known architectural failure — direct internet exposure of OT — and observes it being exploited at a scale that keeps expanding. For a sector already short on cybersecurity staff, three federal releases in five weeks is not a cadence that most utilities are resourced to fully absorb, verify against their own asset inventory and act on before the next one arrives.

What This Means for Operators Outside the Named States

Water and Wastewater Operators, Regardless of State

If your state has not been named among the 12, that is evidence about what has been disclosed, not evidence about your exposure. The campaign’s access method — internet-reachable PLCs, frequently connected through cellular modems installed by an integrator or vendor rather than the utility itself — is a function of how a given asset was deployed, not of which state it sits in ^[2][3].

Critical Manufacturing, Energy, Chemical, and Food and Agriculture Operators

AA26-231A extends the named target list beyond water and wastewater to five additional sectors, all sharing the same underlying pattern: Siemens S7 controllers reachable from the internet, with reconnaissance activity that could evolve into the same operational effects seen in the water sector campaign ^[6][7].

State Regulators and Legislators

The gap in Illinois — no requirement for a utility to disclose an incident to the public or to law enforcement — is not an isolated gap. It is a preview of what a September 2026 CIRCIA final rule is meant to close nationally, and a reminder that until it takes effect, disclosure in most states remains voluntary ^[9][2]. Officials weighing state-level reporting requirements now have a concrete, recent example of how much of a real campaign’s scope can remain unknown for a month under the status quo.

System Integrators and OT Suppliers

Cellular modems installed for remote telemetry, and engineering software used for legitimate configuration, both continue to be the access points described across every advisory in this campaign. Where an integrator made the connectivity decision, the resulting exposure is frequently outside the asset owner’s own visibility, and it is the integrator’s documentation, not the utility’s network diagram, that will show it ^[1][3].

What Are the Practical Challenges for Operators?

A Threefold Undercount Changes the Board Conversation

A leadership team or governing board that was briefed on “a Minnesota incident” in late July is now working from materially different facts. Whatever risk posture, budget request or public statement was built on the original scope should be revisited against the confirmed 100-plus systems and 12-state footprint, not left as originally briefed ^[2][4].

AI Lowers the Barrier to Building Working OT Exploitation Tooling

AA26-231A’s most consequential detail is not the Siemens targeting itself but the method: publicly available device documentation, combined with an AI coding assistant and open-source libraries, was reportedly sufficient to produce functional scripts capable of reading and writing PLC memory over a known protocol ^[6][7]. That is a capability that previously required specialized ICS tradecraft. It does not change what the correct mitigation is — the same segmentation and exposure-reduction controls apply — but it does mean the population of actors capable of acting on an exposed asset is larger than it was when the April advisory was written.

Disclosure Remains Voluntary in Most Places, Which Means Scope Estimates Should Be Treated as Floors

With CIRCIA’s mandatory reporting rule still pending and state-level requirements inconsistent, the 12-state, 100-system figure should be read as the confirmed floor of the campaign’s scope, not its ceiling. Operators and officials should plan on the assumption that additional incidents have occurred and gone unreported, rather than treating the absence of their state’s name as reassurance ^[9][2].

Advisory Fatigue Is Now a Documented Pattern, Not a Hypothesis

Our first analysis raised advisory fatigue as a risk. It is no longer speculative. Three federal releases inside five weeks, each restating the same architectural fix, is direct evidence that the constraint is not awareness — it is the engineering and coordination capacity to act on what has already been published.

How IOActive Can Help

The revised scope of this campaign does not change the underlying gaps our first analysis identified — assessment boundaries that stop short of remote, cellular-connected assets, and the absence of a validated baseline for controller logic. It does change the urgency, the number of sectors in scope, and the case for treating “we weren’t named” as insufficient reassurance. The services below map directly to what this update reveals.

Full Stack Security Assessments

With six sectors now named across two advisories, and internet-reachable PLCs confirmed as the common access point regardless of state or industry, the priority is establishing ground truth about your own estate — not relying on the absence of your name from a news story. Our Full Stack Security Assessments scope beyond the network and application layer to the facility and silicon level, verifying every internet-facing PLC, HMI and RTU against the live environment, including the cellular-connected remote assets that integrator-built architectures routinely place outside an asset owner’s visibility.

This is not a hypothetical exercise for our team. In a recent security advisory, IOActive researcher Ethan Shackelford identified and disclosed multiple vulnerabilities in the KUNBUS Revolution Pi, a DIN-rail industrial PC widely deployed for automation and process control — the same category of device implicated in this campaign, just from a different vendor ^[12]. The findings included an authenticated command injection in the device’s web management interface that led to arbitrary code execution (CVE-2024-8684), a directory traversal exposing system files (CVE-2024-8685), and a years-out-of-date sudo binary that allowed local privilege escalation to root (CVE-2021-3156). It is the same underlying pattern the CISA advisories describe: a web-exposed administrative interface on an industrial controller, reachable further than intended, with unsanitized input standing between an authenticated session and full device compromise. KUNBUS fixed all three findings following coordinated disclosure. This kind of assessment — treating the PLC’s own management interface as an attack surface, not just its network position — is exactly what a Full Stack engagement is built to find before an adversary does.

Red Team and Purple Team Services

AA26-231A describes reconnaissance and capability-building against a named protocol (S7comm) using AI-assisted tooling built from public documentation ^[6]. Our Red Team engagements can emulate that exact tradecraft against your environment — including AI-assisted script generation aimed at your specific controller inventory — while our Purple Team work confirms whether your team would detect it before it progresses from reconnaissance to the disruption pattern already documented at Minnesota, Georgia and South Dakota utilities.

Supply Chain Integrity

The access method across every advisory in this campaign is a cellular modem or remote-access path installed by a vendor or system integrator. Our Supply Chain Integrity service reviews the security posture and connectivity decisions of the third parties who built your control system architecture, closing the visibility gap before it becomes the next disclosed incident.

Advisory Services

With CIRCIA’s final rule now targeted for September 2026 and state disclosure requirements inconsistent in the interim, utilities and their counsel need a clear-eyed view of what reporting obligations already apply and what is coming. Our Advisory Services — programmatic security review, security program development, and Virtual CISO support — help translate this campaign’s revised scope into a board-ready risk picture and a prioritized remediation plan, rather than a reactive response to the next news story.

AI/ML Security Services

As attackers increasingly use AI coding assistants to generate reconnaissance and exploitation tooling, defenders benefit from the same fluency in how that tooling behaves. Our AI/ML Security threat-modeling work extends to evaluating your exposure to AI-assisted attack techniques, complementing the OT-specific assessments above rather than replacing them.

Training

Many of the utilities affected in this campaign are small systems without dedicated cybersecurity staff. Our staff augmentation and Virtual CISO offerings let a resource-constrained utility or municipal IT department bring in the OT security expertise needed to act on these advisories without a multi-year hiring cycle.

What Are the Recommended Next Steps for Operators?

1. Re-brief leadership using the confirmed scope, not the original one. If your board or council was told this was a Minnesota-only event, correct the record before the next report cycle.

2. Treat your state’s absence from the 12 as unconfirmed, not clean. Verify your own internet-facing PLC, HMI and RTU inventory directly rather than inferring safety from news coverage.

3. Extend hunting to AA26-231A’s specific indicators. Look for engineering software or S7comm traffic (TCP port 102) originating from unexpected hosts, particularly if you operate Siemens S7-series controllers ^[6].

4. Confirm your remote-access architecture routes through a managed gateway. Direct PLC-to-internet paths via cellular modem remain the confirmed access method across every release in this campaign ^[2][3].

5. Check your state’s disclosure requirements now, before an incident forces the question. Do not assume CIRCIA’s federal rule already applies; it is not yet final ^[9].

6. Document what you would report and to whom, under both current voluntary norms and CIRCIA’s proposed 72-hour and 24-hour timelines, so the mechanics are already in place before September’s rule finalization.

7. Rehearse detection of the manipulation scenario, not just the outage scenario, as our first analysis recommended — this campaign’s revised scope makes that exercise more urgent, not less.

Conclusion

The story a month ago was that a warning arrived first and a sector-wide incident followed four days later. The story now is that the incident itself was three times larger than anyone said publicly for the following month. Both facts point at the same underlying constraint: the water sector’s capacity to detect, verify, and disclose is not keeping pace with either the scale of what is being attempted against it or the speed at which the tooling to attempt it is becoming available. A federal reporting mandate is coming, but it is not here yet, and in its absence, the confirmed numbers in any advisory should be read as a floor.

If you would like to discuss how your organization’s controller exposure measures up against the activity described here — across water, energy, manufacturing, chemical or food and agriculture — or how IOActive can support your OT/ICS resilience program, we welcome the conversation.

References

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

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

[3] CISA. Internet Exposure Reduction Guidance, published August 21, 2026. https://www.cisa.gov/resources-tools/resources/exposure-reduction

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

[5] J. Greig. Cyberattacks on water systems expand to 12 states as South Dakota, Georgia announce incidents, The Record (Recorded Future News), August 5, 2026. https://therecord.media/iran-cyberattacks-water-treatment

[6] NSA, CISA, FBI, DOE and EPA. Defending Against an Active Threat to Siemens S7 Series PLCs (AA26-231A), August 19, 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-231a

[7] AI-Generated Exploit Scripts Target Siemens S7 PLCs in U.S. Critical Infrastructure, The Hacker News, August 2026. https://thehackernews.com/2026/08/ai-generated-exploit-scripts-target.html

[8] CISA, NSA, FBI warn of Siemens S7 PLC exploitation using AI-generated scripts to disrupt critical industrial processes, Industrial Cyber, August 2026. https://industrialcyber.co/industrial-cyber-attacks/cisa-nsa-fbi-warn-of-siemens-s7-plc-exploitation-using-ai-generated-scripts-to-disrupt-critical-industrial-processes/

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

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

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

[12] IOActive Security Advisory. KUNBUS Revolution Pi – Multiple Vulnerabilities (CVE-2024-8684, CVE-2024-8685), discovered by Ethan Shackelford, published March 28, 2024, CVE IDs added February 11, 2025. https://www.ioactive.com/wp-content/uploads/2025/05/IOA-SecAdvisory-KUNBUS-Revolution-Pi.pdf

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

INSIGHTS | September 9, 2026

Secure Software Development Lifecycle Practices

By IOActive

IBM’s 2026 Cost of a Data Breach Report found the global average breach cost reached USD $4.99 million, a record high driven by AI-powered attacks up 56% year over year.¹ Supply chain attacks compound the exposure: ReversingLabs research confirmed software supply chain attacks grew 1,300% over three years.² The Log4j vulnerability alone generated over 10 million attack attempts per hour at peak exploitation.³ Organizations that treat security as a final-stage gate accumulate deferred risk with every release.

Secure software development lifecycle practices embed security controls at every phase of the software development process, reducing remediation costs and organizational risk.

“The most effective secure software development lifecycle practices address security before software is deployed, not after vulnerabilities are discovered.”
– IOActive Security Team

Secure SDLC Best Practices: Controls, Outputs, and Metrics

Best Practice	What It Does	Key Output	Success Metrics	Risk If Skipped
Security Requirements Mapping	Translates compliance and business requirements into testable acceptance criteria before development begins	Documented security requirements and acceptance criteria	% requirements with security acceptance criteria; compliance gap rate	Missing controls, regulatory gaps, late-stage rework
Threat Modeling (STRIDE/DREAD)	Identifies attack paths in planned architecture using structured frameworks before a line of code is written	Threat register, attack surface map	# threats identified per review; % mitigated before development starts	Architectural flaws reach production with costly remediation
Static Code Analysis (SAST)	Scans source code for insecure patterns at commit or build time	Clean code reports, flagged findings	# high/critical findings per 1,000 lines of code; mean time to remediate	Injection flaws, hardcoded secrets, insecure patterns shipped
Dynamic Application Security Testing (DAST)	Tests running applications against real attack patterns pre-release	Validated vulnerability findings	# runtime vulnerabilities found; % of API endpoints tested	Runtime and authentication flaws missed before release
Software Composition Analysis (SCA) + SBOM	Inventories open-source dependencies and tracks known CVEs; SBOM documents every component in the build	CVE inventory, Software Bill of Materials	% dependencies on a supported version; # libraries no longer actively maintained	Vulnerable third-party libraries deployed; supply chain exposure
Artifact Signing and Configuration Hardening	Signs build artifacts cryptographically and audits deployment configurations to prevent tampering	Signed artifacts, hardened deployment configurations	% of artifacts signed; # misconfigurations resolved at deploy gate	Supply chain tampering, misconfigured production environments
Vulnerability Management and SLA Enforcement	Prioritizes and remediates vulnerabilities by CVSS score, production reachability, and CISA KEV status	Remediated CVE backlog, SLA compliance metrics	Mean time to remediate (MTTR) by severity tier; % SLA compliance	Unpatched known-exploited vulnerabilities accumulate and expand breach risk
Security Governance and Program Maturity	Establishes named ownership, enforceable security gates, and maturity benchmarks aligned to NIST SP 800-218 or OWASP SAMM	Maturity score, named control owners, audit evidence	# controls with named owners; % security gates enforced in CI/CD; maturity level progression	Controls exist on paper only; programs consistently underperform without governance infrastructure

Gaps at any single phase propagate forward. A vulnerability introduced at requirements and missed through design, development, and testing arrives in production fully formed and significantly more expensive to remediate.

Run Threat Modeling Before Writing Code

The highest-leverage security activity happens before a single line of code is written. Threat modeling, using frameworks such as STRIDE or DREAD, gives teams a structured method for identifying attack paths in planned architecture and building in controls before architectural decisions become costly to reverse. A research-fueled Secure Development Lifecycle engagement brings genuine adversarial thinking to this process, applying real-world offensive experience to surface the systemic risks that automated tools routinely overlook.

Threat Modeling Method Comparison

Method	What It Does	Who Runs It	What It Provides	Effort Level	Best Fit
STRIDE	Categorizes threats by class: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege	Security architects, senior developers	Comprehensive attack class mapping across trust boundaries	Medium — 1 to 2 days per system review	Application architecture and trust boundary analysis
DREAD	Scores threats on Damage, Reproducibility, Exploitability, Affected users, and Discoverability to produce a ranked risk list	Security engineers, risk teams	Prioritized threat list by exploitability and business impact	Low to medium — hours per threat register	Risk-ranking identified threats for remediation sequencing
Attack Trees	Decomposes the path to a specific high-value target into branches of possible attack methods	Penetration testers, security researchers	Targeted attack path analysis for critical or high-value components	High — days to weeks for complex targets	Component-level analysis of specific high-value targets

Method selection depends on the question the team needs to answer. STRIDE maps attack classes broadly across a system; DREAD narrows findings to prioritized risk; Attack Trees decompose the path to a specific high-value target. Most mature programs apply more than one method, selecting based on the architecture under review and the risk questions at hand.

Integrate Code Analysis and Supply Chain Controls Into Every Pipeline Stage

Static analysis (SAST) catches insecure code patterns during development, while dynamic testing (DAST) validates a running application against real attacker behavior. Supply chain exposure requires its own layer of controls. Sonatype’s research found open-source supply chain attacks growing at 742% annually.⁴ A dedicated Supply Chain Integrity assessment applies attacker-mindset analysis from silicon through the application layer. A 2025 third-party assessment of Microsoft’s Signing Transparency service confirmed strong implementation security and identified defense-in-depth improvements.⁵ Core controls include SBOM management, SCA in CI/CD pipelines, dependency pinning, and artifact signing.

Code Analysis and Supply Chain Controls

Control	What It Does	Who Runs It	Integration Point	Risk Addressed
SAST in CI/CD	Scans source code for insecure patterns automatically at commit or merge	Developer pipelines, security champions	Git pre-commit hook or CI pipeline	Insecure patterns caught before code reaches the main branch
DAST pre-release	Sends attack traffic to a running application to surface runtime flaws	QA teams, security engineers	Staging environment or pre-release gate	Runtime and authentication flaws not visible to static analysis
SCA in build pipeline	Scans open-source dependencies against CVE databases with each build	DevOps, security teams	Build pipeline or dependency resolution step	Known CVEs in third-party libraries before they reach production
SBOM + artifact signing	Generates a complete bill of materials and cryptographically signs build outputs for every release	DevSecOps, release engineering	Release pipeline or deployment gate	Supply chain tampering and untracked third-party components

Layering all four controls closes distinct gaps at different pipeline stages. SAST and DAST address first-party code at different points in the lifecycle. SCA and SBOM management address third-party and supply chain risk at the build and release stages. Each layer reinforces the others: SAST catches what code review misses, DAST catches what SAST cannot see at runtime, and SCA flags risks that originate entirely outside the team’s codebase.

Prioritize Vulnerabilities With Contextualized SLA Frameworks

Datadog’s 2025 DevSecOps research found that the median software dependency is 215 days behind its latest major version, with one in two services running libraries no longer actively maintained.⁶ Effective vulnerability management requires contextualized prioritization based on CVSS score and production reachability, SLA-based ownership, and regression testing to confirm fixes hold. Listings on the CISA Known Exploited Vulnerabilities catalog indicate confirmed real-world exploitation and warrant accelerated remediation timelines regardless of the base CVSS score.

Vulnerability Remediation SLA Framework

Priority Tier	Criteria	Target SLA
Critical	CVSS 9.0+, internet-exposed, CISA KEV listed	24–72 hours
High	CVSS 7.0–8.9, production reachable	7–14 days
Medium	CVSS 4.0–6.9, limited exposure	30–60 days
Low	Below 4.0 or non-production	90 days

SLAs paired with named ownership and enforced timelines convert a priority framework into a functioning remediation program. Without that operational infrastructure, vulnerability backlogs expand faster than teams can close them.

Establish Named Ownership and Track Security Program Maturity

Governance gaps are the most common point of failure in secure SDLC programs. Controls require named ownership and enforceable gates; programs without both consistently underperform regardless of tooling investment. The NIST Secure Software Development Framework (SP 800-218) and OWASP SAMM provide structured maturity models for building and measuring program progress.⁷ Red Team and Purple Team exercises close the feedback loop, testing whether development-phase controls hold under real adversarial simulation and informing the next cycle of program improvement.

Assess Your Current Maturity Level and Close the Gaps Systematically

Maturity Level	Characteristics	Next Steps to Advance
Ad Hoc	Reactive, no formal process, incident-driven patching	Assign one control owner per business unit; document current state versus target state; implement a vulnerability tracking system
Defined	Basic security gates, SAST in CI/CD, vulnerability tracking	Add threat modeling at the design phase; adopt SLA-based remediation; integrate SCA into the build pipeline
Managed	Threat modeling, SCA, SLA-driven remediation, metrics reporting	Automate artifact signing; run quarterly adversarial simulations; establish an SBOM management program
Optimized	Automated supply chain controls, adversarial simulation, SBOM management	Integrate continuous Red Team feedback into the SDLC; benchmark the program annually against NIST SP 800-218 or OWASP SAMM

Most organizations enter at Ad Hoc or Defined. Identifying the gaps between the current state and the next level, then addressing them incrementally, produces durable outcomes. Each level builds on the controls established in the previous one, making systematic progression the most reliable path to program improvement.

Build Security Into Your Development Process With IOActive

Secure software development lifecycle practices address vulnerabilities at the phase where remediation is most efficient: before the code ships. Organizations that build security into design, development, and deployment produce software that holds up under real-world adversarial pressure and satisfies the compliance obligations regulators and insurers continue to tighten. IOActive’s 25+ years of research-driven assessments, landmark vulnerability disclosures, and straight-talk approach give clients an honest picture of where their program creates risk.

Schedule Your Secure Software Development Lifecycle Assessment with IOActive

Sources

IBM Security. Cost of a Data Breach Report 2026. https://www.ibm.com/reports/data-breach
ReversingLabs. The State of Software Supply Chain Security 2024. https://www.reversinglabs.com/sscs-report-2024
IOActive. Supply Chain Integrity. https://www.ioactive.com/service/supply-chain-integrity/
Sonatype. State of the Software Supply Chain, 10-Year Look. 2024. https://www.sonatype.com/state-of-the-software-supply-chain/2024/10-year-look
IOActive. Security Assessment of Microsoft’s Signing Transparency. 2025. https://www.ioactive.com/wp-content/uploads/2025/10/Microsoft-Signing-Transparency-Service-Security-Assessment-IOActive-Public-Facing-Report.pdf
Datadog. State of DevSecOps 2025. April 2025. https://www.datadoghq.com/state-of-devsecops-2025/
NIST. Secure Software Development Framework (SSDF) SP 800-218. https://csrc.nist.gov/projects/ssdf

INSIGHTS | September 3, 2026

The DRM Flag That Isn’t DRM

By Elvin Gentiles

SetWindowDisplayAffinity makes a window disappear from screenshots, screen shares, and Recall snapshots. Vendors sell that as “screenshot protection,” and procurement checklists tick it off as data-exfiltration risk mitigated. Microsoft’s own documentation for the API says otherwise. This post breaks down what the flag actually guarantees, who can route around it and how, and why a black screenshot is the beginning of a threat model rather than the end of one.

The Pitch, and the Problem with It

Open a modern secure-messaging app, password manager, or exam browser on Windows 11, hit PrtSc, and paste. The result is a black rectangle, or nothing at all. Vendor marketing calls it “screenshot protection.” Privacy blogs call it “blocks Recall.” The procurement checklist gets a tick next to data exfiltration: mitigated.

Microsoft’s own documentation for the API doing the work says otherwise:

Unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity … will strictly protect window content.

The feature that makes a window disappear from screenshots is explicitly not a security feature, according to the people who built it. Yet vendors build a whole category of “privacy” and “DLP” features on top of it.

Microsoft is not consistent about this either. The Recall management documentation, aimed at developers whose remote desktop clients lack screen capture protection, calls adding it “an easy feature,” labels it “This DRM flag,” and points them to the very same SetWindowDisplayAffinity API whose own reference page insists it is not DRM. Two documents, one API, opposite claims.

That gap, between what the control implies and what it guarantees, is what this post takes apart. Attackers route around it without much thought. Defenders keep inheriting it as a checkbox someone else already ticked.

How the Flag Works

The Win32 function doing the work:

BOOL SetWindowDisplayAffinity(
  [in] HWND  hWnd,      // top-level window, must belong to the calling process
  [in] DWORD dwAffinity // the exclusion mode
);

Three values for the dwAffinity parameter matter:

Constant	Value	Behavior in a capture
WDA_NONE	0x00000000	No restriction. Normal capture.
WDA_MONITOR	0x00000001	Window shows only on a physical monitor; captures render it black.
WDA_EXCLUDEFROMCAPTURE	0x00000011	Window shows only on a physical monitor; captures omit it entirely (no suspicious black box).

WDA_EXCLUDEFROMCAPTURE is the newer, “better” flag. It arrived in Windows 10 Version 2004 (build 19041). Before that, WDA_MONITOR was the only option, and it left a tell-tale black rectangle. The upgrade is cosmetic from a defense standpoint: black box versus empty space. The security boundary is identical.

The difference is in what the capture comes back with. Under WDA_MONITOR, a screenshot or a screen share contains a black rectangle sitting exactly where the window is, and whatever the window overlaps is hidden along with it. Anyone looking at that capture learns that something was being withheld, how big it was, where it sat, and, in the case of a recording, how long it stayed open and when it closed. Under WDA_EXCLUDEFROMCAPTURE, the window is not in the frame and the desktop behind it shows through, so the capture looks like the application was not running at all. The user sharing their screen has no black box to explain, and the people watching get no cue that anything was hidden.

The Desktop Window Manager (DWM) enforces the exclusion. It is the compositor that assembles every window into the final image on screen. When a capture tool asks DWM for a frame of the desktop, DWM builds that frame and leaves the flagged window out of it. The pixels still reach the physical display; they never reach the composited frame handed to the capture tool. The flag embeds nothing in the window’s content and blocks no capture tool from running. Every bypass later in this post is a version of the same idea: get the image from somewhere other than DWM’s composited output, and the exclusion never applies.

Why Developers Reach for It Anyway

It’s an attractive control because:

It’s one line of code. No kernel driver, no service, no secure enclave.
It’s OS-native. No third-party dependency to vet.
It defeats the lazy attacker. PrtSc, Snipping Tool, Zoom/Teams/Meet screen share, OBS via the standard desktop-duplication path: all come up empty. Against a casual insider or an over-eager AI screenshotter, that’s a win.

The Signal case is the honest version of the story. When Microsoft shipped Recall, a background feature that silently snapshots the screen every few seconds into a searchable database, Signal had no developer-facing opt-out to keep chats out of the index. So, Signal set the display-affinity flag on its window. Signal’s own engineers described it, more or less, as a “one weird trick”: abusing a media-protection flag because Microsoft gave privacy apps no proper API. That’s a defensible decision against that specific threat, an OS feature capturing through the normal compositor path. It is not a general-purpose confidentiality control, and Signal never claimed it was.

The failure mode is the marketing leap: a product that “defeats normal screenshots” gets sold as one that “protects sensitive data,” with no threat model in between.

Who This Does Not Stop

Every control ever shipped can be bypassed, so the useful question is who can bypass this one, holding what access. Three capability tiers cover it.

Tier 0: The User Who Avoids the Blocked Path

Even with zero special access, plenty of capture paths never touch the DWM-composited surface the flag protects.

The analog hole: a phone camera pointed at the monitor. The pixels that reach a retina reach a camera sensor the same way. No API closes this, and Microsoft’s docs concede as much.
Context that breaks DWM: the protection only works while DWM is composing the desktop, a limit Microsoft states in its documentation. Remote Desktop sessions disable DWM, so a window invisible to a local screenshot can render perfectly over RDP. Certain remote-assistance and mirroring stacks, and some virtual-display configurations, land in the same bucket. The control silently fails open, which is the worst way for a control to fail.
VM quirks: in basic VMs without GPU acceleration, the compositor path can differ enough that the exclusion doesn’t behave as advertised.

None of these require privilege escalation. They require not using the one capture method the flag was designed to block. Tier 0 is where most real-world leakage happens, and it leaves almost nothing behind on the host.

Tier 1: The Local User Willing to Run Code

The window belongs to a process, and processes on a user’s own machine are not a trust boundary against that user. IOActive consultant Taha Draidia recently published the concrete version of this in Signal Windows Desktop: contentProtection Bypass, which takes apart Signal Desktop’s screen-capture protection. Signal reaches this same Win32 call through Electron’s setContentProtection() wrapper, so the write-up doubles as a case study in what the flag is worth.

Flip the flag back from inside the process. Draidia tested the obvious approach first: call SetWindowDisplayAffinity(hwnd, WDA_NONE) on Signal’s window from another process. That fails with ERROR_ACCESS_DENIED, and running elevated fails the same way, because the kernel check compares the caller’s process identity against the window’s owner rather than its privilege level. Administrator rights do nothing here. CreateRemoteThread into Signal’s own process satisfies the check, and the protection turns off with no error, no prompt, and nothing on screen to mark the change.

Capture below the compositor. DWM removes the window while assembling the desktop image, so the removal exists only in the copy DWM hands out. Capture that reads frames lower in the stack and closer to the hardware never receives that copy, and may see the window intact. The flag protects one rendering path rather than the content.

This explains where the protection breaks down, not how to build something that breaks it. Anyone who can run code in the user’s session can neutralize the flag, and the barrier is measured in API calls rather than in exploit development. The control is therefore exactly as strong as whatever stops code execution in that session.

Tier 2: Kernel, Driver, or Physical Access

The flag does not apply here at all. DWM checks the exclusion while it builds the desktop image, so code running at or below the display driver gets the pixels without that check ever happening. Independent kernel-mode research makes the point from the other direction: the proof-of-concept driver DWMShield skips the public API entirely and calls the undocumented internal routine GreProtectSpriteContent directly, passing a target window handle over an IOCTL from a non-elevated client. It reaches the same DWM enforcement point Draidia’s work identified, but from underneath the ownership check rather than by satisfying it — the mirror image of the CreateRemoteThread approach in Tier 1, and a separate piece of research rather than an extension of it.

The Actual DRM, for Comparison

The irony in the title is that real DRM exists on the same platform and works on a different principle.

Hardware-backed protected media paths (Widevine L1, PlayReady SL3000, FairPlay) decrypt and composite content inside a Trusted Execution Environment, a secure media path that user-mode and often kernel-mode capture cannot reach. That’s why screen-recording a premium streaming-video service yields a black frame even with admin rights: the pixels never exist in a framebuffer the OS will hand out.

The flag that isn’t DRM, side by side with the DRM that is:

	SetWindowDisplayAffinity	Hardware DRM (protected media path)
Enforced by	DWM composition, kernel-side owner check on the flag	Secure hardware / TEE
Where the viewable image lives	Normal framebuffer; omitted only from the copy handed to capture	Inside the TEE; never in a framebuffer the OS can hand out
What it covers	One top-level window at a time, per HWND, re-applied for every new window	The content stream itself, wherever it plays
Stops normal screenshots	Yes	Yes
Kept out of Recall snapshots	Yes	Yes (Microsoft: Recall won’t store DRM content)
Stops a local user with admin	No (admin enables injection)	Yes
Survives process injection	No	Yes
Survives RDP / DWM-off contexts	No (fails open)	Yes
Stops a phone camera	No	No
Who can disable it	Any code running inside the owning process	No software path; requires defeating the hardware
How it fails	Open and silent: no error, no log, no visual change	Closed: the license refuses to bind, playback stops or drops quality
Cost to adopt	One API call per window, no licensing	Device certification, license server, key management; SL3000 is device-only
Microsoft’s own classification	“Not a security feature or DRM”	Actual content protection

SetWindowDisplayAffinity is a hardening measure against opportunistic capture. Hardware DRM is a confidentiality control. Treating the flag as a confidentiality control is where the false sense of security begins.

What Developers Should Do

Using SetWindowDisplayAffinity is reasonable. Products go wrong when they treat that one API call as the finished control.

Set it on every top-level window, not just the main one. Affinity is a per-HWND property and every new window starts at WDA_NONE. Dialogs, tooltips, context menus, toasts, and the separate windows that WPF popups and Electron render into each get their own HWND. Flag the main window but not the dialog, and the screenshot catches the secret in full while the ordinary window behind it is the part that gets hidden.

Check the return value. The call returns FALSE on a window that isn’t top level or doesn’t belong to the calling process, and a silent failure still looks protected in code review. Treat it as a security event. On builds older than 19041, WDA_EXCLUDEFROMCAPTURE succeeds and behaves as WDA_MONITOR, so the window turns black instead of vanishing and the API never mentions the difference.

Re-read the flag. GetWindowDisplayAffinity reads the current value from any process, so the app or a monitoring agent can poll it. A change to WDA_NONE the app didn’t make means something else is writing to its process: log it, alert on it, and consider blanking the view until the app can verify its own state.

Use the supported control when one exists. Recall now has real policy: Allow Recall to be enabled (AllowRecallEnablement) and Turn off saving snapshots for Recall (DisableAIDataAnalysis), and managed devices have it removed by default. The flag was a workaround for consumer machines with no opt-out, which is still where it earns its keep.

Document the threat model. Name what the feature stops: screenshot tools, screen sharing, OS-level snapshotting. Name what it doesn’t: cameras, remote sessions, code running in the user’s session, anything at kernel level. Microsoft’s Azure Virtual Desktop documentation is the model to copy: it states plainly that the feature isn’t DRM-level protection and isn’t a substitute for one, and recommends pairing it with other controls.

Pair it with content-level controls. Reveal-on-tap for secrets, short display timeouts, redaction by default, per-session watermarking.

What Defenders Should Monitor

You cannot stop capture on a machine the user controls. You can often catch the attempt.

Injection into the protected app: the Tier 1 bypass is a common and ordinary injection, and the Signal bypass used CreateRemoteThread, the loudest option available. Watch Sysmon Event ID 10 (ProcessAccess) against that target with PROCESS_VM_WRITE, PROCESS_VM_OPERATION, or PROCESS_CREATE_THREAD; Event ID 8 (CreateRemoteThread); Event ID 25 (ProcessTampering); and Event ID 7 (ImageLoad) for unsigned modules or anything from a user-writable path.

Tamper events the app reports about itself: this depends on developers implementing the affinity re-read above, so ask whether they did. An app reporting “my window affinity changed and I didn’t change it” is a detection with almost no false-positive surface.

Capture and remote-control tooling on regulated hosts: OBS, ShareX, Snagit, ffmpeg with a screen-grab input, and support stacks such as AnyDesk, TeamViewer, and ScreenConnect. Inventory and policy rather than alerting, since none are malicious by default. The question is why a capture stack is installed on a host whose security depends on capture being hard.

Policy drift: if Recall is disabled by policy, verify it stayed disabled on the endpoint rather than trusting that the GPO exists. BYOD is the harder case, because Recall is available by default there and the user decides.

Everything a camera sees: out of reach of host telemetry. That leaves physical controls and per-session watermarking that survives a photograph. “We can’t stop the screenshot, but we can tell whose session it came from” is a more defensible promise than “the screenshot came out black.”

Conclusion

Read the flag as what it is and Microsoft’s two pages stop contradicting each other: it keeps sensitive windows out of casual captures and out of Recall on machines where the user is not the adversary, and it does nothing about the three tiers above. When a datasheet or a control matrix claims more than that, the difference is data with nothing protecting it, and another control has to cover the gap. A design that depends on a screenshot-proof window for confidentiality is a finding rather than a control.

References

Microsoft Learn — SetWindowDisplayAffinity function (winuser.h)
Microsoft Learn — Manage Recall for Windows clients
Microsoft Learn — Screen capture protection in Azure Virtual Desktop
IOActive — Signal Windows Desktop: contentProtection Bypass
GitHub — ahossu/DWMShield

INSIGHTS | September 1, 2026

Offensive Security Best Practices for Modern Enterprises

By IOActive

Security professional reviewing server infrastructure in a data center as part of offensive security best practices.)

Annual assessments are not enough. A strong security program tests its defenses against realistic attack scenarios throughout the year. Can an attacker reach a critical service? Will the security team see the activity? Can the organization contain it before the business feels the impact?

The answers depend on people, processes, and technology working together. These offensive security best practices help security leaders build an ongoing, threat-informed capability.

Offensive Security Best Practices at a Glance

Best practice	What it does	What to do	Business value
Threat-informed objectives	Prioritizes relevant threats, assets, and risks	Select two test objectives: one high-value asset path and one critical service path	Better use of security resources
Adversary emulation	Recreates realistic attacker behavior and objectives	Map one chained attack path and define evidence for each step	More accurate risk insight
Red and Purple Team exercises	Challenges defenses, then improves them collaboratively	Run an independent Red Team exercise, then retest the highest-risk gap with the Blue Team	Measurable defensive learning
Continuous validation	Retests controls after change, remediation, and new threats	Define retest triggers and compare the original result with the new result	Ongoing assurance
Full-stack coverage	Evaluates people, processes, technology, and dependencies	Map one business-critical service and test an attack across at least two layers	Fewer blind spots
Enterprise risk integration	Connects findings to business priorities and decisions	Assign an owner, a treatment decision, and a 90-day remediation path	Better governance and investment

Use the table to plan the work. The sections below show how to implement each practice and choose reporting measures.

Set Threat-Informed Objectives

Effective testing starts with the threats and assets that matter most. Before choosing an assessment, identify critical services and sensitive data. Also identify privileged identities and operational systems, and map the dependencies that support them.

Mandiant’s 2025 data shows why this prioritization matters. Exploits were the most common initial infection vector in its investigations, accounting for 33%. Stolen credentials accounted for another 16%. Prioritize the attack paths most likely to affect the business.

Create a risk register using four fields: business service, high-value asset, likely threat scenario, and security question. Rank each scenario by business impact, then assess its exposure and the ability to detect and contain it. Turn the highest-ranked scenarios into test objectives.

What to do

Choose two objectives: test one path to a high-value asset and one path that could disrupt a critical business service.
Write the security question: for example, “Can an attacker with a compromised identity reach the payment environment without triggering a response?”

These objectives set a clear destination and make the result easier to measure. Next, model how an attacker might reach it.

Use Adversary Emulation to Test Real Attack Paths

Adversary emulation recreates realistic attacker behavior and objectives. Moving well beyond isolated weaknesses, it tests whether an attacker can join techniques, move through the environment, and reach a clear target.

A scenario may include initial access and privilege escalation. It may include lateral movement and persistence. It may end with access to a high-value asset. A Red Team approach uses threat intelligence to shape the scenario. It also uses attacker tactics, techniques, and procedures to model a real attack chain.

Turn each step into a control-validation action. Record the failed control and the evidence available, then record the owner, remediation action, and retest date. This keeps the exercise focused on reducing risk and assigning follow-up work.

Mandiant reported a global median dwell time of 11 days in its 2025 report. When an outside party found the intrusion, the median was 26 days. Use these figures as context for your own baseline. For each exercise, record whether the path was completed, along with detection coverage, time to detect, time to contain, business impact, and internal discovery time.

Emulation should show which improvement can reduce risk next.

What to do

Build one attack chain: map the path from the selected entry point to the target asset, including the control expected to stop each step.
Define the evidence in advance: agree on the alerts, logs, response actions, and timing measures that will determine whether each control worked.

With the path defined, pair independent attack pressure with collaborative defensive improvement.

Combine Red Team and Purple Team Exercises

Red Team exercises provide an independent challenge. Skilled operators try to bypass controls and follow realistic attack paths. They work toward a defined objective. Threat-emulation services include Red Team, Purple Team, physical security and breach assessment, and social engineering.

Purple Team work turns that challenge into measurable defensive improvement. The offensive and defensive teams examine alerts together. They tune detection logic, refine response playbooks, and rerun the highest-risk failed step. Red Team shows what an attacker may accomplish. Purple Team tests whether defenders can detect and stop it.

Start with the highest-risk failed step, and focus the first retest on the control that matters most. Have the Blue Team confirm the expected alert, then run the response action. Repeat the step until the result is measurable. Track time to detect, time to contain, technique coverage, and recurring false positives.

No single improvement percentage applies across Red Team and Purple Team exercises. Compare the baseline with the retest result to show whether the organization became faster, more visible, or more resilient.

What to do

Run two exercises: use an independent Red Team scenario to test the attack path, then use a Purple Team session to validate the highest-risk detection and response gaps.
Retest the failed step: after tuning the alert, repeat the technique and confirm that the response works under realistic conditions.

The resulting evidence feeds the next practice: continuous validation.

Use Security Validation to Continuously Test Controls

Controls can lose effectiveness after configuration changes, new technology, security incidents, or shifts in attacker behavior. Security validation provides a repeatable way to check priority controls over time.

Build validation into risk, change, and remediation workflows. A practical cycle is: test the control, identify gaps, remediate them, retest, and report progress.

Define a retest trigger for each priority control. Verizon’s 2026 Data Breach Investigations Report found that software vulnerabilities began 31% of breaches and ransomware appeared in 48% of breaches. The report also found that 15% of breaches involved attack techniques bolstered by generative AI. These findings support validation whenever the environment or threat picture changes.

What to do

Set five triggers: retest after a material configuration change, a new exposed service, a high-severity vulnerability, a relevant threat-intelligence update, or completed remediation.
Report one outcome: record whether the original failure was reproduced, contained, or resolved, and attach the evidence.

Continuous Validation Triggers and KPIs

Validation trigger	Minimum response	KPI to report
Material configuration change	Rerun the affected attack step	Detection coverage before and after the change
New exposed service	Test access, authentication, and monitoring	Unauthorized paths found
High-severity vulnerability	Validate exploitability and containment	Exploit success and time to contain
Relevant threat-intelligence update	Add or revise an emulation scenario	Techniques covered
Completed remediation	Retest the original failure and record evidence	Failure reproduced: yes or no

When a failed control crosses a system boundary, extend the test across the full stack and verify the handoff.

Test the Full Stack

Attack paths cross security teams and technology layers. A weakness in identity management may expose an application. An application compromise may then provide access to cloud infrastructure, operational technology, or sensitive data.

A mature program tests people and processes as well as technology. The scope may include applications, APIs, cloud environments, endpoints, connected devices, AI systems, supply chains, hardware, and firmware. Shape the assessment around business risk and the dependencies that could change the outcome.

Full Stack Security Assessments cover physical security, hardware, embedded systems, and silicon-level systems. They also cover software, people, processes, and supply-chain security. This cross-layer view helps teams understand one attack path from entry point to business impact.

AI adoption adds another cross-layer dependency that can span several teams. Include identity, cloud, data, and AI workflows in the same risk conversation. Keep those workflows connected to the broader security program.

Measure the layers that matter to the selected service. Useful KPIs include social-engineering success and reporting rates. Track privileged paths, authorization bypasses, cross-zone paths, asset-to-asset paths, and untested dependencies.

What to do

Start with one service: map every dependency that supports a business-critical service, from people and facilities to applications and data.
Cross two layers: select one attack scenario that moves across at least two layers, such as identity to cloud or physical access to a workstation.

This produces a practical full-stack test and gives business leaders evidence they can use.

Connect Findings to Enterprise Risk Management

Offensive security creates value when each significant finding answers four questions. What could an attacker do? Which business service is affected? Which control failed? What should the organization address first?

The financial stakes make this translation important. IBM’s 2025 Cost of a Data Breach Report put the average global breach cost at $4.44 million and the mean time to identify and contain a breach at 241 days. Connect each finding to exposure, disruption, response performance, and the cost of reducing the risk.

NIST’s 2026 Cybersecurity Framework 2.0 quick-start guide links cybersecurity risk, enterprise risk, and workforce decisions. Give each priority finding a business owner, risk scenario, treatment decision, target date, and success measure.

Useful measures include priority attack paths validated and detection and containment performance. Track recurring control failures and the time between remediation and retesting. Map those measures to decisions about ownership, funding, staffing, architecture, and accepted risk.

What to do

Assign a decision owner: give each priority finding one accountable business owner and a technical lead.
Build a 90-day roadmap: put the highest-impact attack paths first, define retest dates, and report progress in the same forum used for enterprise risk decisions.

Enterprise Risk Decision Matrix

Security evidence	KPI to report	Enterprise decision
A priority attack path succeeds	Percentage of priority paths completed	Fund remediation or formally accept the risk
Detection is missing or delayed	Median time to detect	Prioritize monitoring, logging, or staffing
A control fails after remediation	Repeat-failure rate	Revisit the control design or implementation
Retesting is repeatedly delayed	Days overdue	Escalate ownership and delivery risk
A business service has several exposed layers	Number of exposed layers	Sequence a full-stack improvement plan

The real result is a better question: “Which risk decision should this evidence change?”

Make Offensive Security an Ongoing Capability

An ongoing capability links four activities: threat intelligence shapes the scenario, testing produces evidence, an owner handles remediation, and retesting confirms the result.

IOActive offers Red Team and Purple Team exercises, physical security and breach assessments, and social engineering. Its services also include full-stack assessments, penetration testing, code review, reverse engineering, secure development, advisory services, security training, and OCP SAFE assessments.

Select the service combination that matches the attack path. One engagement can expose the path, while follow-on testing and advisory support can help teams sustain the fix.

What to do

Schedule the retest first: define the evidence required to close the finding before the initial engagement begins.
Review the cycle quarterly: refresh threat scenarios, check overdue remediation, and select the next business-critical attack path.

Talk to IOActive About Offensive Security Best Practices

A mature offensive security program turns realistic attack testing into clear decisions. Test a business-critical attack path, measure how quickly defenses detect and contain it, fix the highest-risk gap, and retest.

If you need help connecting these activities across your technology stack, talk to IOActive. The team can help you apply these practices to a clear business risk.

Talk to IOActive about offensive security best practices

Sources

Google Threat Intelligence, “M-Trends 2025: Data, Insights, and Recommendations From the Frontlines,” https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025
IOActive, “Red Team & Purple Team Services,” https://www.ioactive.com/service/red-team-and-purple-team-services/
Verizon, “2026 Data Breach Investigations Report,” https://www.verizon.com/business/resources/reports/dbir/
IOActive, “Full Stack Security Assessments,” https://www.ioactive.com/service/full-stack-security-assessments-2/
IBM, “2025 Cost of a Data Breach Report: Navigating the AI rush without sidelining security,” https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai
National Institute of Standards and Technology, “NIST Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick-Start Guide,” https://csrc.nist.gov/pubs/sp/1308/final

INSIGHTS | August 26, 2026

Signal Windows Desktop: contentProtection Bypass

By Taha Draidia

Signal Desktop on Windows ships a screen-capture protection feature that prevents the application window from appearing in screenshots or screen recordings. In this post, we walk through how we identified the underlying Windows API powering that feature, why naïve attempts to disable it fail even from a privileged process, and how we ultimately bypassed the protection by executing code within Signal’s own process context using CreateRemoteThread.

In this post we cover two distinct phases of the research:

Static analysis — locating the contentProtection API chain through Signal’s open source code and Electron documentation.
Kernel internals — reverse engineering win32kfull!NtUserSetWindowDisplayAffinity to confirm the ownership check that enforces the protection and understand exactly why cross-process calls are rejected.

Background

During an internal discussion, a colleague mentioned noticing that Signal’s window did not appear during a screen-share session. This prompted us to investigate the mechanism behind it and, naturally, to ask whether that mechanism could be bypassed.

Signal Windows Desktop contentProtection Bypass Signal Windows Desktop contentProtection Bypass

Finding the API Behind contentProtection

Signal Desktop is an Electron application and its source code is publicly available on GitHub. A ripgrep search for contentProtection across the codebase quickly identified the relevant call site:

SHELL · RIPGREP · SIGNAL-DESKTOP SOURCE

C:\Users\tahai\code\Signal-Desktop>rg contentProtection
app\main.main.ts
566:  const contentProtection = ephemeralConfig.get('contentProtection');
571:    (contentProtection ?? isContentProtectionEnabledByDefault(OS, os.release()))
3022:  if (name !== 'contentProtection') {
3026:  const contentProtection = ephemeralConfig.get('contentProtection');
3029:    if (typeof contentProtection === 'boolean') {
3030:      window.setContentProtection(contentProtection);

ts\windows\preload.preload.ts
6:installEphemeralSetting('contentProtection');

ts\util\createIPCEvents.preload.ts
208:        ((await getEphemeralSetting('contentProtection')) ??
216:      await setEphemeralSetting('contentProtection', value);

The call at line 3030, window.setContentProtection(contentProtection), is the Electron API responsible for the behaviour. Checking the Electron documentation reveals how this maps to platform-specific system calls:

On Windows, setContentProtection(true) calls SetWindowDisplayAffinity with the flag WDA_EXCLUDEFROMCAPTURE. On Windows 10 version 2004 and later the window is excluded from capture entirely. On older versions the flag falls back to WDA_MONITOR behaviour, which renders the window as a black rectangle in any capture.

This setContentProtection path is a well-trodden one outside Signal, and community write-ups describing it match what we observed. On Windows the call resolves to SetWindowDisplayAffinity(WDA_EXCLUDEFROMCAPTURE) (and on macOS to CGWindowSetSharingType(kCGWindowSharingNone)), it requires Windows 10 build 19041 — the May 2020 Update — or newer for true exclusion rather than the black-rectangle WDA_MONITOR fallback, and the exclusion happens at the Desktop Window Manager (DWM) / kernel display layer rather than in the application. As a result the window is omitted from every user-mode capture pipeline that goes through Windows Graphics Capture (WGC) — Zoom, Teams, Meet, OBS, Game Bar, and ordinary PrintScreen and BitBlt captures alike. One documented caveat worth noting for defenders is that certain DXGI / direct-GPU capture paths can, on some GPU and driver combinations, still capture a window flagged this way — the exclusion is strong but not literally universal.

Windows SetWindowDisplayAffinity()

The API signature is straightforward — a window handle followed by a DWORD affinity value:

WDA_NONE (0x00000000) — no restrictions
WDA_MONITOR (0x00000001) — content displayed only on a monitor
WDA_EXCLUDEFROMCAPTURE (0x00000011) — content excluded from all capture

To disable the protection, we need to call this API with a valid top-level window handle for Signal and pass WDA_NONE. Obtaining the handle is straightforward: EnumWindows() paired with GetWindowTextW() and GetWindowThreadProcessId() lets us identify Signal’s window by cross-matching title text and process name.

Disabling the Protection — Three Approaches

Approach 1 — Cross-Process API Call

With a valid handle in hand, the first attempt was direct: call SetWindowDisplayAffinity(hwnd, WDA_NONE) from a separate process. This returns immediately with ERROR_ACCESS_DENIED (5). Windows is enforcing an ownership check — a process cannot modify the display affinity of a window it does not own.

Approach 2 — Elevated Privileges

The same call was retried from a process running as Administrator. The result is identical: ERROR_ACCESS_DENIED. The check is not privilege-gated. Even a fully elevated process is rejected when calling SetWindowDisplayAffinity against a window it does not own.

Approach 3 — Remote Thread Injection (Successful)

The key constraint the previous two attempts revealed is that the call must originate from within Signal’s own process. We satisfied this using CreateRemoteThread to execute SetWindowDisplayAffinity(hwnd, WDA_NONE) inside Signal’s process context. Because the call is issued from Signal’s process, it passes the ownership check and the protection is silently removed. The proof of concept is available on GitHub.

SetWindowDisplayAffinity() — Kernel Internals

Having confirmed the ownership constraint empirically, we verified it through static analysis of the kernel implementation. The userland call chain is:

user32!SetWindowDisplayAffinity
  └─ win32u!NtUserSetWindowDisplayAffinity   [syscall boundary]

SetWindowDisplayAffinity in user32.dll is a thin wrapper around the NtUserSetWindowDisplayAffinity syscall exported by win32u.dll:

Locating the Implementation in the Kernel

In the kernel the syscall is handled across two modules. We confirmed this with the WinDbg x command:

WINDBG KD · MODULE SEARCH

1: kd> x win32*!*SetWindowDisplayAffinity*
fffff805`5d55ad40 win32k!stub_UserSetWindowDisplayAffinity
fffff805`5d51d320 win32k!_win32kstub_NtUserSetWindowDisplayAffinity
fffff805`5d4fe5ac win32k!NtUserSetWindowDisplayAffinity
fffff805`618bb180 win32kfull!NtUserSetWindowDisplayAffinity

Disassembling win32k!NtUserSetWindowDisplayAffinity shows it calls win32k!W32GetSessionState for a desktop-session sanity check, then dispatches through nt!KscpCfgDispatchUserCallTargetEsSmep — a first-layer check with no ownership logic. The ownership enforcement lives in win32kfull!NtUserSetWindowDisplayAffinity.

The Ownership Check

Working through the disassembly, the sequence is:

WINDBG KD · WIN32KFULL!NTUSERSETWINDOWDISPLAYAFFINITY — ANNOTATED

; Resolve the target window to its internal struct (via ValidateReceivingHwnd)
fffff805`618bb1ac  call  win32kfull!ValidateReceivingHwnd
fffff805`618bb1b3  mov   rdi, rax          ; rdi = window object

; Get the Win32 process object of the *current* (calling) process
fffff805`618bb1c2  call  nt!PsGetCurrentProcessWin32Process
fffff805`618bb1c7  mov   r8, rax            ; r8 = current process

; Compare: does the window's owning process match the calling process?
fffff805`618bb1db  mov   rax, [rdi+10h]     ; rax = window's thread info
fffff805`618bb1df  cmp   [rax+1D0h], r8    ; owning process == calling process?
fffff805`618bb1e6  jne   +0xe2              ; NO -> ACCESS_DENIED

; ACCESS_DENIED path
fffff805`618bb262  mov   ecx, 5             ; ERROR_ACCESS_DENIED
fffff805`618bb267  jmp   win32kfull!UserSetLastError

The check is explicit: PsGetCurrentProcessWin32Process returns the Win32 process object for the calling thread, and that value is compared against the process stored at offset 0x1D0 of the window’s owning thread structure. If they differ, the call is rejected. Administrator privilege does not factor into this path — the check is purely about process identity, which is why elevated callers receive the same ERROR_ACCESS_DENIED as unprivileged ones.

CreateRemoteThread satisfies this check because it causes the API call to execute on a thread within Signal’s own process, making PsGetCurrentProcessWin32Process return Signal’s process object — an exact match.

Going Below the API — Kernel-Level Enforcement

The ownership check above lives in the syscall handler for SetWindowDisplayAffinity, but that syscall is only the documented front door. The exclusion state it sets is ultimately applied deeper in the graphics stack, inside DWM. Independent kernel-mode research reinforces this: a proof-of-concept driver (DWMShield) skips the public API entirely and calls the undocumented internal routine win32kfull!GreProtectSpriteContent directly, passing a target HWND and the same 0x11 (WDA_EXCLUDEFROMCAPTURE) flag. It works from kernel mode by exposing a device and symbolic link, taking the target window handle over an IOCTL from a non-elevated client, and invoking GreProtectSpriteContent on its behalf — after which DWM applies the same capture-exclusion state that the official path would have produced.

That work is the mirror image of ours. Where CreateRemoteThread bypasses the kernel ownership check by making the call originate from inside the target process, the driver bypasses it from the other side — by dropping below the user-mode API to the routine that actually enforces the flag, where the per-process identity comparison never runs. It carries the usual kernel-research friction: because GreProtectSpriteContent is not exported, its address must be resolved manually and shifts on every reboot under KASLR, and the driver depends on an internal signature that Windows updates can change. But the takeaway is the same one the ownership check hints at: the capture-exclusion decision is made by DWM in kernel space, and it can be reached — by moving code into the owning process, as we did, or by reaching the enforcing routine directly, as the driver does.

Conclusion

EnumWindows is a powerful Win32 API: it allows any process, regardless of privilege, to enumerate top-level windows within the current desktop session and receive a handle to each. Those handles do not, by themselves, grant meaningful access — what can be done with a handle is gated separately by each target API’s own access controls. In the case of SetWindowDisplayAffinity, the gate is a kernel-level ownership check that correctly rejects cross-process calls from any caller, including administrators.

However, the check is bounded by process identity rather than a broader integrity or trust model. CreateRemoteThread — a documented, widely-available Windows API — provides a straightforward way to move code execution into the target process and thereby satisfy that identity check. The result is a silent, runtime removal of screen-capture protection with no indication to the user.

This finding illustrates a recurring theme in Windows security: individual API-level checks are often well-implemented, but the combination of legitimate APIs can produce outcomes the checks were not designed to prevent. Defence-in-depth controls like screen-capture protection are most effective when the device is uncompromised. Once an attacker has local code execution they are in a position to erode multiple such controls through in-process execution. Signal’s protection is a solid user-mode control. What these two paths show is only that, like any capture-exclusion built on the same DWM mechanism, it rests on the integrity of the endpoint rather than on a boundary the local attacker cannot cross.

References

Reach Out to a Security Specialist at IOActive

INSIGHTS | August 20, 2026

Key Takeaways from the 2026 OCP APAC Summit

By Alejandro Hernandez

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

Key Takeaways

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

AI in the Agentic Era

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

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

Open Data Centers and Open Networking

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

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

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

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

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

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

Taipei as a Meeting Point

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

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

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

Watch Our OCP APAC Summit Recap

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

INSIGHTS | August 18, 2026

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

By IOActive

Key Takeaways

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

A Statement for a Narrowing Window

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

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

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

What Does the Statement Set Out?

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

Leaders are urged to:

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

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

Who is Affected by the Statement?

Boards and Executive Leadership

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

CISOs and Security Leadership

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

Operators of Critical National Infrastructure

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

Vendors and Technology Providers

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

What are the Key Challenges Organisations Will Face?

Compressed Exploitation Timelines

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

Your Adversary Already Has an AI Upgrade

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

Legacy and Unsupported Systems

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

Governance Gaps Between Boards and Technical Teams

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

AI as a Dual-Use Capability

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

Shipping Faster Means Shipping More Attack Surface

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

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

Zero-Day Proliferation

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

How IOActive Can Help

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

Red Team and Purple Team Services

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

Full Stack Security Assessments

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

Supply Chain Integrity

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

Preparedness and Resilience Testing

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

Threat Modeling and Advisory

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

What are the Recommended Next Steps?

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

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

Conclusion

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

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

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

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

References

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

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

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

INSIGHTS | August 13, 2026

Red Team vs Penetration Testing: Key Differences

By IOActive

“Penetration testing identifies vulnerabilities. Red teaming evaluates how effectively an organization can detect and respond to realistic attacks.” IOActive Security Team

The decision between red team vs penetration testing comes down to one question: What are you trying to learn? Most mature security programs need both methodologies, deployed in sequence: penetration testing to close technical gaps, and red teaming to validate that the controls protecting what remains will hold under real adversarial pressure.

This article breaks down the differences between red team vs penetration testing so your organization can choose the right approach.

Red Team vs Penetration Testing at a Glance

Dimension	Penetration Testing	Red Team Engagement
Primary objective	Find and exploit as many vulnerabilities as possible	Simulate a targeted adversary; test detection and response
Scope	Defined: specific systems, apps, or networks	Broad: may include physical access, social engineering, supply chain
Duration	Days to weeks	Weeks to months
Stakeholders	Internal stakeholders are aware	Only select executives are involved; blue team is typically unaware
Methodology	Transparent, checklist-oriented	Covert, adversary-emulation, objective-based
Threat model	Generic opportunistic attacker	Specific threat actor (e.g., APT29, FIN7)
Output	Vulnerability list with severity rankings and remediation steps	Detection timelines, playbook gaps, response readiness report
Best for	Organizations building foundational security controls	Organizations with a mature SOC and incident response capability
Compliance value	High (PCI DSS explicitly requires it; the proposed HIPAA Security Rule update would mandate annual testing if finalized; SOC 2 auditors widely expect it)	Lower direct compliance value; higher strategic value
Cost	$5,000–$50,000 depending on scope; most mid-market engagements fall between $10,000 and $35,000	$20,000–$100,000+ depending on duration and complexity; full adversary simulations typically run $40,000–$100,000

Penetration Testing

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

The goal: Find as many exploitable weaknesses as possible, demonstrate their real-world impact, and deliver actionable remediation guidance.

Pros: Penetration testing goes beyond automated vulnerability scanning by adding human judgment: chaining vulnerabilities, testing business logic flaws, and filtering genuine risk from noise. Findings are immediately actionable.

Cons: Internal teams are typically aware the test is underway, which limits the value for measuring detection and response.

Choose a pentest when:

A compliance mandate requires it (PCI DSS, HIPAA, SOC 2 Type II)
You have deployed new infrastructure, applications, or cloud environments
You are validating remediation from a prior assessment
You are establishing your organization’s first formal testing program

Red Team Testing

What it is: A red team engagement is a full-scope adversarial simulation in which expert ethical hackers pursue specific objectives, such as accessing sensitive data or compromising executive accounts. Red team engagements use the same tactics, techniques, and procedures (TTPs) as real-world threat actors.

The goal: Determine whether your organization’s people, processes, and technology can detect, contain, and respond to a sophisticated attacker pursuing a specific objective, before a real adversary tests those same capabilities.

Pros: The engagement runs covertly, often without notifying the organization’s own security staff. This generates realistic data on detection timelines and incident response effectiveness.

Cons: Red team engagements are not optimized for cataloging technical vulnerabilities at scale. If foundational controls are weak, the red team will often achieve its objectives before meaningful detection data can be collected. In those cases, a penetration test would have surfaced the same findings faster and at lower cost.

Choose a red team engagement when:

Your SOC monitors alerts but has never been validated against a sophisticated intrusion
You need to test people and processes, not just technical controls
You want to measure detection and response against a specific, realistic threat scenario
Your security program has matured beyond foundational vulnerability management

Choose Based on Security Maturity

The most reliable decision factor is security maturity, which determines which question you are ready to answer. Organizations that have not yet closed known vulnerabilities will get more value from a pentest than from a red team engagement.

Organizations early in their security journey should run penetration tests first. If a red team can compromise your environment in hours without triggering a single alert, those findings could have been reached more efficiently with a pentest. Closing known vulnerabilities first allows a red team engagement to surface detection and response gaps that actually matter.

Security Maturity and Testing

Maturity Stage	Indicators	Recommended Approach
Foundational	No formal pentest history; basic patching	Penetration testing
Developing	Regular pentests; security tooling in place	Pentesting + targeted red team scenarios
Established	Functioning SOC, SIEM, incident response plan	Both methodologies on a defined cadence
Advanced	Mature threat intelligence; purple teaming capability	Red team + purple team for continuous validation

Most organizations overestimate their maturity. If you have not run a penetration test within the past 12 months, or if your SOC has never responded to a simulated intrusion, a red team engagement will tell you less than a rigorous pentest will.

How the Two Methodologies Work Together

Penetration testing and red teaming are not competitors: they serve different stages of a security program. The typical progression is to run a pentest, remediate vulnerabilities, and build detection and response capabilities. From there, a red team engagement tests whether the SOC would detect a sophisticated attacker exploiting what remains.

Red team findings routinely drive improvements to SIEM detection rules, incident response playbooks, and security awareness training. It’s also recommended to use purple team exercises, which pair red team attackers with the organization’s blue team in a collaborative format to accelerate control tuning in real time.

Work With IOActive for Red Team Engagements and Penetration Testing

With over 25 years of offensive security research and engagements across some of the world’s most complex environments, IOActive has the experience to determine the right methodology for your risk profile and execute it with precision. IOActive’s penetration testing practice goes beyond off-the-shelf tooling, applying an attacker’s perspective and human judgment to chain vulnerabilities, expose business logic flaws, and deliver findings with clear remediation priority. Our red and purple team engagements run multi-vector, goal-based adversary simulations across technical, physical, and human attack surfaces, testing prevention, detection, response, and recovery under realistic conditions.

Talk to an IOActive expert about the right security testing approach for your organization

Key Takeaways

Why Does Internet-Exposed OT Matter Now?

What Is Known About the UK Generator Incident?

What Does CISA’s Internet Exposure Reduction Guidance Recommend?

What Do UK Guidance and Regulation Already Require?

Who Is Affected by Internet-Exposed OT Risk?

Electricity generation and distribution operators

Water and wastewater utilities

Manufacturers and process industries

Suppliers, integrators and maintenance providers

Boards and audit committees

What Are the Challenges for Operators?

How Can IOActive Help?

What Are the Recommended Next Steps?

Conclusion

References

Cybersecurity Testing Methodologies Compared

Choosing the Right Cybersecurity Testing Methodology

Vulnerability Assessments

What a Vulnerability Assessment Actually Measures

When a Vulnerability Assessment Is the Right Choice

Where It Falls Short

Penetration Testing: Proving Exploitability

What Penetration Testing Measures

When Penetration Testing Is the Right Choice

Where It Falls Short

Red Teaming: Testing Resilience, Not Just Vulnerabilities

What Red Team Exercises Measure

When Red Teaming Is the Right Choice

Where It Falls Short

Purple Teaming: Turning Offense Into Defensive Improvement

What Purple Team Exercises Measure

When Purple Teaming Is the Right Choice

Where It Falls Short

Adversary Simulation: Testing Against the Threats That Target You Specifically

What Adversary Simulation Measures

When Adversary Simulation Is the Right Choice

Where It Falls Short

Security Validation: Continuous Testing for Mature Programs

What Security Validation Measures

When Security Validation Is the Right Choice

Where It Falls Short

Full-Stack Security Assessment: When Surface-Level Testing Isn’t Enough

Why the Full Stack Matters

IOActive’s Full-Stack Advantage

Frequently Asked Questions

How often should organizations conduct penetration tests?

Is a Red Team exercise always more valuable than a penetration test?

Can a single engagement combine multiple methodologies?

What distinguishes a full-stack security assessment from a standard penetration test?

Sources

Key Takeaways

Why This Update Matters Now

What CISA Actually Confirmed on August 26

Three Federal Advisories in Five Weeks

What This Means for Operators Outside the Named States

Water and Wastewater Operators, Regardless of State

Critical Manufacturing, Energy, Chemical, and Food and Agriculture Operators

State Regulators and Legislators

System Integrators and OT Suppliers

What Are the Practical Challenges for Operators?

A Threefold Undercount Changes the Board Conversation

AI Lowers the Barrier to Building Working OT Exploitation Tooling

Disclosure Remains Voluntary in Most Places, Which Means Scope Estimates Should Be Treated as Floors

Advisory Fatigue Is Now a Documented Pattern, Not a Hypothesis

How IOActive Can Help

What Are the Recommended Next Steps for Operators?

Conclusion

References

Secure SDLC Best Practices: Controls, Outputs, and Metrics

Run Threat Modeling Before Writing Code

Threat Modeling Method Comparison

Integrate Code Analysis and Supply Chain Controls Into Every Pipeline Stage

Code Analysis and Supply Chain Controls

Prioritize Vulnerabilities With Contextualized SLA Frameworks

Vulnerability Remediation SLA Framework

Establish Named Ownership and Track Security Program Maturity

Assess Your Current Maturity Level and Close the Gaps Systematically

Build Security Into Your Development Process With IOActive

Sources