Key takeaways

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

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

Ease of Access

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

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

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

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

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

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

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

LLM in the Loop

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

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

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

The Detection That Held

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

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

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

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

Lessons Learned

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

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

References

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

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

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

Key Takeaways:

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

A Strategy for a Critical Moment

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

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

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

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

What Does the Energy Sector Cyber Security Strategy Set Out?

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

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

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

Who is Affected by the Energy Sector Cyber Security Strategy?

Energy Operators and Utilities

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

Smaller Operators and New Market Entrants

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

Supply Chain Vendors and Technology Providers

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

What are the Key Challenges Organisations Will Face?

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

Legacy OT and ICS Infrastructure

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

The Cyber-Engineering Skills Gap

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

Supply Chain Visibility

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

Expanding Attack Surface from Clean Energy Technologies

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

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

Board-Level Cyber Literacy

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

How IOActive Can Help?

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

OT/ICS Full Stack Security Assessments

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

Red Team and Purple Team Services

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

Supply Chain Integrity

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

Threat Modelling and Advisory

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

Preparedness and Resilience Testing

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

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

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

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

Conclusion

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

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

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

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

References

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

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

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

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

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

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

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

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

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

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

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

Key Takeaways

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

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

The CIA Triad, Briefly

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

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

Where AIC Comes From (And Why It Stuck)

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

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

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

A Coverage Model, Not a Hierarchy

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

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

The Integrity Problem

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

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

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

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

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

On Confidentiality

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

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

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

The Property That Is Not in the Triad

Safety.

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

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

What the Actual Frameworks Say

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

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

A More Useful Frame

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

About IOActive

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

References

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

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

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

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

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

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

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

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

What bug bounties reliably provide

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

Bounties work best when:

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

The natural limits of bounties

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

Five practical limits show up repeatedly:

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

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

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

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

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

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

What professional services deliver

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

The difference is method:

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

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

Where bounties miss

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

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

Where bounties outperform, and how to let them

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

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

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

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

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

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

Program design that treats both as first-class

You need an operating model.

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

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

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

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

What to measure

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

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

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

Common objections

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

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

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

Bottom line for the industry

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

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

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

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

Key Findings:

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

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

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

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

Over the past decade, I’ve conducted a series of research projects at IOActive focused on hacking robots. Robots are interesting from a security research perspective because they sit at a unique intersection: they are cyberphysical systems, embedded devices that can perform physical actions. A vulnerability in a web application leaks data. A vulnerability in a robot can harm the person standing next to it. That physical dimension is what makes this research worth pursuing. The first, “Hacking Robots Before Skynet” with Cesar Cerrudo in 2017, assessed over a dozen robots from vendors including SoftBank, Universal Robots, UBTECH and Rethink Robotics. After identifying nearly 50 vulnerabilities across various robotic platforms, we demonstrated the real-world risks by successfully exploiting industrial collaborative robots.

That research continued in 2018, when we demonstrated the first-ever ransomware attack on robots at Kaspersky SAS, infecting SoftBank’s NAO and Pepper robots with proof-of-concept malware that disrupted operations, disabled factory reset mechanisms, and showed that robot downtime could be weaponized for extortion. That same year, we contributed to the development of RVSS (Robot Vulnerability Scoring System), a scoring framework designed to address what CVSS misses when applied to robotics: safety impact, environmental context, and downstream effects on physical systems.

At the time, the conventional wisdom was that attacking robots required deep expertise in ROS, embedded systems, and cyber-physical dynamics. That specialized knowledge was supposed to be the barrier. Our research showed the barrier was thin, but it was still there. You needed to know where to look and how robotic ecosystems were assembled.

Nine years later, that barrier no longer exists.

What Changed

A new research paper I contributed to, “Cybersecurity AI: Hacking Consumer Robots in the AI Era”, published in March 2026 with Alias Robotics, demonstrates something I’ve been watching unfold across every engagement surface: AI doesn’t just accelerate the work. It compresses the expertise requirement.

Alias Robotics built CAI (Cybersecurity AI), an open-source, CLI-based cybersecurity agent that combines domain knowledge of robotics protocols, embedded systems, and exploit databases into a GenAI-powered assessment framework. The methodology was deliberately constrained: for each robot, CAI received only the product name and access. No documentation. No prior research. The AI agent autonomously discovered attack surfaces, tested for weaknesses, built exploits, and assessed impact. Human operators guided the process and intervened when tests reached vendor cloud infrastructure, but the analytical engine was the AI.

What We Found

Three consumer robots were assessed using this framework: an autonomous lawnmower (Hookii Neomow), a powered exoskeleton (Hypershell X), and a window cleaning robot (HOBOT S7 Pro). Different categories, different manufacturers, different countries of origin: China and Taiwan. Using this AI framework, we found **38 vulnerabilities** across them: 16 Critical, 14 High, 6 Medium, 2 Low.

Across these products, the same patterns kept showing up.

No authentication, anywhere.

Every robot exposed critical interfaces without requiring credentials. The lawnmower had an unauthenticated debug service granting root access (CVSS 10.0). The exoskeleton accepted BLE connections from any device in range, no pairing required. The window cleaner opened all GATT services to anyone who connected. These aren’t subtle implementation flaws. They’re the complete absence of a security boundary.

Fleet-scale exposure from single-device access.

The lawnmower’s hardcoded MQTT credentials were identical across the entire fleet. From one compromised device, CAI escalated to the vendor’s broker running default admin credentials, enumerated 267 connected robots, and confirmed the ability to command any of them. One robot compromised, hundreds accessible. That’s the kind of attack chain that, in 2017, would have taken a team days to map.

Credential leakage in every direction.

Across all three platforms, we found hardcoded credentials embedded in configuration files, mobile applications, and heap dumps. Plaintext database passwords, cloud API keys, SMTP credentials providing access to thousands of internal support emails, even Shopify account recovery codes. The exoskeleton alone yielded root MySQL credentials for servers in both China and internationally.

Unsigned firmware, plaintext updates.

The window cleaner’s OTA service accepted arbitrary firmware writes without cryptographic verification, served over plaintext HTTP. The exoskeleton’s firmware binaries were publicly accessible at predictable URLs, protected only by CRC16 checksums. In both cases, firmware replacement is trivially achievable.

Motor control without authorization.

This is where robot vulnerabilities diverge from conventional IoT. The exoskeleton exposed 177 BLE commands including motor control functions, all executable without authentication from up to 70 meters away. The window cleaner’s suction motors could be disabled mid-operation. We’re not talking about data exposure at this point. We’re talking about physical safety.

Same Vulnerabilities, Different Decade

In 2017, we found unauthenticated network services on robots, unencrypted communications and unsigned firmware updates. We recommended encryption, authentication, secure defaults, and vulnerability disclosure channels. Nine years later, none of the three consumer robots assessed in the new paper implemented any of these basic security controls.

The vulnerability classes are identical. The specialized expertise that once served as a de facto security barrier is now encoded in AI systems that anyone can run.

The Physical Dimension

Back then, we described robots as “kinetic IoT devices”: computers with arms, legs, or wheels that, if compromised, could cause physical harm, destroy property, or kill. A woman had already died in 2015 when an industrial robot restarted at the Ajin USA plant in Alabama. Our argument was that deliberate attacks could produce the same outcomes.

Nine years later, the scenarios are concrete. An exoskeleton whose motor commands execute without authentication. A lawnmower fleet accessible through a single set of hardcoded credentials. A window cleaner whose suction can be disabled mid-operation from 70 meters away.

Beyond physical safety, the paper documents systemic data governance failures. Two of the three robots showed confirmed GDPR violations: data transmission without user consent, no data subject rights mechanisms, cross-border transfers without legal basis. What’s notable is that CAI identified these alongside the technical vulnerabilities. AI-powered assessments naturally extend into regulatory risk, not just exploitation.

The vendor response pattern hasn’t changed either. All three manufacturers were contacted. Hypershell’s reply: “At this time, Hypershell is not pursuing vulnerability disclosure reports or external security research submissions.” In 2017, four of six vendors responded to our disclosures. Two said they’d fix the flaws but never did. One vulnerability was patched over a year later. The industry’s relationship with security research has not materially improved.

Security Through Obscurity Is Over

The robotics industry relied on an implicit assumption: the specialized knowledge required to assess robotic systems created a natural barrier to entry. That assumption was already questionable in 2017. In 2026, it’s demonstrably false.

LLMs trained on robotics documentation, security research, and exploit databases can guide someone through a complex robotic system without requiring years of specialized training. The domain expertise that historically protected these systems is now accessible through a command-line interface.

The implications are immediate.

For manufacturers:

Complexity is not protection. All three robots exhibited fundamental authentication failures. Not sophisticated zero-days. The absence of basic security controls that an AI agent identifies in minutes. The hardware engineering across all three platforms was impressive. The cybersecurity maturity doesn’t match.

For regulators:

Connected consumer robots introduce physical safety risks that traditional product liability frameworks weren’t designed for. Exploitable motor controls, fleet-wide credential reuse, absent consent mechanisms. This demands regulatory attention specific to robotic systems.

For the security community:

Traditional defense-in-depth architectures like the Robot Immune System (RIS) are a foundation, but their static, rule-based approach isn’t built to counter AI-powered attacks that autonomously chain vulnerabilities across BLE, cloud APIs, and OTA channels. The paper argues for a shift toward GenAI-native defensive agents: adaptive threat detection, autonomous patch generation, coordinated fleet-wide intelligence sharing.

Looking Forward

This new collaboration with Alias Robotics shows that the threat hasn’t diminished. It has been amplified by AI capabilities that compress months of expert analysis into hours.

The full paper is available on arXiv (2603.08665) CAI is open source at github.com/aliasrobotics/cai.

For organizations deploying robotic systems, in manufacturing, logistics, healthcare, agriculture, or consumer contexts, the calculus has changed. The assessment timeline has collapsed. A consultant with the right AI tooling can now cover in hours what used to take weeks. The question is no longer whether your robots have vulnerabilities. It’s whether you find them before someone else does.

*This research was conducted in collaboration with Alias Robotics, a Spain-based company specializing in robot cybersecurity. Alias Robotics developed CAI and the Robot Immune System (RIS), and continues to lead open-source efforts in robotic security tooling.*

IOActive continues to provide specialized security assessments for robotic platforms, IoT devices, and cyber-physical systems. Contact us to discuss how we can help evaluate and strengthen the security posture of your deployments.

Overview

Cybersecurity regulation in the EU is shifting in a meaningful way. With the Cyber Resilience Act (CRA), the focus is moving upstream—from how organizations operate to how digital products are actually built and maintained. For manufacturers and software vendors, it changes what it means to bring a product to market in the EU.

The CRA aims to give consumers a consistent baseline of security across all products with digital elements, regardless of industry. These products now sit at the heart of critical infrastructure, industrial systems, and everyday life. Ongoing vulnerabilities, unclear software supply chains, and weak default settings have already proven expensive—and risky—for organizations.

What is the EU Cyber Resilience Act (CRA)?

The CRA sets mandatory cybersecurity requirements for any product with digital elements sold in the EU. At its core, it’s about making sure products are secure by design, secure by default, and supported throughout their lifecycle.

The regulation formally came into force on 10 December 2024. According to the European Commission, most requirements will apply from 11 December 2027, with vulnerability reporting obligations starting earlier, on 11 September 2026.

In practical terms, manufacturers are now responsible for their product’s security from initial design all the way through post-market support. That includes identifying and reducing risks, managing vulnerabilities, and delivering updates when needed.

The CRA works alongside other EU frameworks like GDPR and NIS2, but it tackles a different layer. GDPR is about protecting personal data. NIS2 focuses on organizational security. The CRA, on the other hand, is about the product itself—raising the baseline so that risks are reduced across the entire digital ecosystem.

Who does the EU Cyber Resilience Act Affect?

Types of Organizations

The CRA applies to any organization selling digital products in the EU, no matter where the organization may be based and touches a broad range of organizations, including:

• Hardware manufacturers with connected or digital functionality
• Software vendors offering commercial or enterprise solutions
• Developers of embedded systems and firmware
• Importers and distributors selling products under their own name in the EU

Non-EU companies are fully in scope if their products are sold in the EU. In many cases, responsibility is shared across the supply chain, which makes clear ownership and documentation essential.

Categories of Products

“Products with digital elements” covers a wide range of technologies, such as:

• Connected devices (IoT, industrial systems, automotive, medical components)
• Software (operating systems, applications, network services)
• Hardware that depends on software or firmware for secure operation

The CRA distinguishes between standard and critical products, with stricter requirements for higher-risk categories. That distinction directly affects how much investment and assurance work is needed.

Inclusions and Exclusions

Most commercially distributed hardware and software fall within scope. Some non-commercial open-source projects may be excluded, but once software is used commercially, it’s generally covered. Products built solely for national security or defense are excluded.

A common mistake is assuming that third-party components or bundled software fall outside the regulation. In reality, many of these products are still covered.

What is required by organizations and how can IOActive help?

Secure-by-Design and Default Practices

Security needs to be built in from the start. That means identifying risks early, reducing attack surfaces, and shipping products with secure default settings. Relying on perimeter defenses or fixing issues after release is no longer enough.

IOActive supports this with a structured Security Design Review process that evaluates:

• Technology stacks
• Known vulnerabilities
• Potential design flaws
• Data flows
• Practical recommendations for improvement

Finding issues early not only improves security—it also reduces cost and avoids reputational damage down the line.

Vulnerability Discovery and Management

Organizations need a clear process for receiving vulnerability reports, assessing their impact, and fixing issues quickly. Reporting and disclosure are core requirements, and responsibilities don’t end at product launch.

IOActive has a long track record of identifying vulnerabilities in both software and hardware. Clients regularly rely on our teams to test new products and uncover risks before attackers do.

Product Lifecycle Accountability

Manufacturers are responsible for product security throughout its entire lifecycle. That includes providing updates and communicating clearly with users when issues arise. Unsupported products can quickly become both compliance and reputational risk.

IOActive helps organizations put structure around the full lifecycle—from design and development through testing, maintenance, and eventual decommissioning.

Supply Chain and Component Risk

Using third-party components doesn’t shift responsibility. You’re still accountable for the security of everything in your product. That makes supplier assurance, software bills of materials, and risk tracking much more important.

Modern supply chains are global and complex, often involving multiple vendors and regions. IOActive approaches this with an attacker’s mindset, combining research and real-world techniques to identify weaknesses across the entire stack—even down to the silicon level.

Governance and Documentation

Compliance isn’t just about doing the work—it’s about proving it. Organizations need clear documentation of their security processes, decisions, and risk management activities.

This pushes product security beyond engineering. It becomes a shared responsibility across product, security, legal, and compliance teams.

FAQs

Who will the EU CRA Impact?

Any organization that sells products with digital elements in the EU, regardless of where it’s based.

When is an organization’s product considered in scope of the Cyber Resilience Act?

As soon as it’s placed on the EU market. Engaging early in the development process is the best way to ensure compliance.

What is considered a product with ‘digital elements’?

• Connected devices (IoT, industrial, automotive, medical)
• Software (OS, apps, network services)
• Hardware relying on software or firmware

When will the CRA take effect?

According to the EU Commission, “The main obligations introduced by the Act will apply from 11 December 2027, with reporting obligations to apply as of 11 September 2026.”

What is the difference between “main obligations” and “reporting obligations?”

Main obligations are the core “secure-by-design” requirements—things that shape how a product is built, documented, and assessed before it goes to market.

Reporting obligations are about what happens when something goes wrong: the need to quickly notify the appropriate parties if there’s an active security breach or a newly discovered vulnerability.

Additional Resources

• Get Strategic About Cyber Risk Management (Blog)
• Eight Steps to Improving Your Supply Chain Security Program (Blog)
• The State of Silicon Chip Hacking (eBook)
• Threat Brief: Low-level Hardware Attacks (Research)