2026 Global State of ICS/OT Exposure: Flat Counts, Expanding Risk

Are the repeated warnings throughout the years taking effect? Although we would like to say they are, the answer is complex and, most likely, we aren’t quite there yet.

Good news and bad news

Since last year's report about the Unforgivable Exposure of industrial control systems, we have continued to scan the Internet at scale for this type of system, like we always do. At Bitsight, this is just work as usual. We have been receiving extremely good feedback on our yearly paper and we are pleased to release this year’s report looking back 2025’s ICS exposure, hoping to continue to contribute to the much needed awareness of the topic and the cyber security challenges that our digital society continues to face.

The first question that our readers usually ask and really want to know is: is the ICS/OT exposure getting better? Did it get better last year? Getting better in the sense of reduction of exposures, of course. The answer is: well… not really.

Good news

The ‘good news’ is that last year's observed trend, which seemed to indicate that we would surpass 200,000 monthly exposures this year, is no longer showing. That past study has been based on 13 of the major ICS/OT communications protocols that are found in the wild. It is a good way to compare year-on-year evolution. So comparing those 13 protocols we were tracking the entire 2024 with the scan data for 2025, the total exposure seemed to have reached a peak in January 2025 and was lingering around 170,000 monthly exposure the rest of the year.

Calling this ‘good news’ implies a certain amount of optimism which many readers, and even the writer, might not share. The fact that this exposure doesn’t continue to grow faster than global inflation is a positive sign, but the average monthly numbers are still staggering. If you add to the fact that this is a study on a subset of protocols that these types of devices are known to implement, the good news doesn't really look like good enough.

Bad news

The time when an industrial system was confined to the traditional ICS/OT protocols is gone. Nowadays, increasingly complex controllers support a multitude of protocols, they are internet-ready and can function independently or as part of complex integrated ecosystems. It is not hard to find PLCs (programmable logic controllers) that support standard OT protocols like BACNet and MODBUS, but also feature built-in SSH servers, Web Servers, or even provide MQTT support, allowing the controller to push data directly to cloud platforms.

So it only makes sense that, when we are trying to understand the overall exposure of these types of systems at scale, we also take a look at these other non-traditional, but adjacent, protocols supported by many modern controllers.

If we look at last year's data, it doesn’t look great. We are seeing more devices slowly creeping up on these adjacent protocols over time. If you are a security researcher, especially on the offensive side and used to scan the internet, this seems quite natural. As vendors improve their devices with additional features, latest protocol support, and all the other bells and whistles, the attack surface necessarily expands. This is concerning because, not only the exposure increases, so does the risk. For example, in some new devices, instead of one potential vulnerability or misconfiguration in the EtherNet/IP protocol implementation, now there are two more potential issues in the system FTP and HTTP server.

The expansion of device capabilities through new technology inherently introduces greater potential for security vulnerabilities. This is just how it works in general and the ICS/OT space is no exception.

But why is Bitsight looking at Industrial Control Systems and Operational Technology protocols? Two words: Critical Infrastructure.

Critical Infrastructure and ICS/OT protocols

Critical Infrastructure relies on ICS/OT protocols. The systems controlled by them are tightly coupled to the physical processes necessary for our society to function. These protocols, whether legacy or modern, are the established standards for industrial control and automation. This study, as we mentioned, covers 15 of such protocols (13 we already covered in the past plus Apcupsd and IEC 104). Here’s a summary of the protocol usage and the risks associated with them, so that the readers understand why we are monitoring them (expect this list to keep growing).

• Apcupsd (APC UPS): An open-source daemon running on Linux/Windows hosts that manages APC UPS units. Its Network Information Server on TCP/3551 often binds 0.0.0.0 by default, exposing battery, line, and system status. Secondary hosts configured in slave mode trust status data from the master over TCP/3551 and can be coerced into unexpected shutdowns by a spoofed master or MitM.
• Automatic Tank Gauge (ATG): Liquid level monitoring for fuel tanks. These systems often use open terminal interfaces with no login requirements. Research has proven that exploiting these can lead to physical damage, including "relay burnout" from rapid cycling, forced fuel overflows, or the disabling of critical leak detection.
• BACnet: The dominant protocol for building automation, controlling HVAC, lighting, and elevators. It traditionally uses unauthenticated broadcast messages, allowing for easy spoofing and system hijacking. The newer BACnet/SC variant provides TLS-based security but in practice requires new edge hardware (BACnet/SC routers/hubs) and certificate lifecycle management which is a non-trivial uplift.
• CODESYS: A PLC runtime environment used by over 500 hardware vendors. It represents a massive supply-chain risk; vulnerabilities disclosed recently, such as CVE-2025-41660, allow for remote code execution, potentially leading to a full process takeover across diverse brands.
• DNP3: The backbone of North American water and electric utilities. DNP3 Secure Authentication v6 (SAv6), aligned with IEC 62351-5, uses X.509 certificates with ECDH key agreement and HMAC-based key derivation. Deployment remains slow and most utilities still run unauthenticated DNP3 vulnerable to replay and spoofing.
• EtherNet/IP: An industrial Ethernet protocol used for high-speed machinery control. It relies on the Common Industrial Protocol (CIP), which can allow attackers to bypass network boundaries. "CIP Security" adds encryption and integrity, but requires specific CIP Security–capable hardware that is not yet industry-standard.
• IEC 104: A primary standard for power grid telecontrol used to manage substations and circuit breakers. It operates without native authentication or encryption, making it a direct path for attackers to disrupt grid stability. While the IEC 62351 secure variant exists, its implementation remains rare in legacy hardware due to high computational overhead and certificate/PKI lifecycle management and interoperability challenges.
• IEC 61850: A sophisticated substation automation standard that uses object modeling for high-voltage protection. Exposure gives attackers direct access to protection relays and automation logic, potentially allowing them to trip high-voltage circuit breakers. Security relies on the IEC 62351 standard, though many operators still rely on external firewalls instead.
• KNX: A popular smart building protocol in Europe for lighting and climate control. When used over IP, it acts as a transparent bridge to the building's wiring; if exposed, an attacker can take full control of the automation. "KNX IP Secure" exists to mitigate this but is frequently ignored during installation.
• Modbus: The most widespread protocol for industrial sensors and actuators across all sectors. It lacks any native security, allowing any network-adjacent device to read or write data to a controller. A TLS-wrapped "Modbus/TCP Security" version was released to address this, but adoption is still very low in the field.
• Moxa NPort / Lantronix: These are serial-to-Ethernet device servers that bridge legacy equipment to IP networks. They often ship with default credentials or no authentication, providing a raw network tunnel directly to critical serial-connected devices like meters, RTUs, or older PLCs, but can be connected to pretty much any device that has a serial port.
• Niagara FOX: Tridium’s framework for managing large-scale building systems in commercial real estate. Legacy "AX" systems are frequently found exposed online with weak credentials, while newer "N4" systems are more secure but often left vulnerable due to poor configuration of administrative interfaces.
• OPC UA: The modern machine-to-machine middleware for industrial data exchange. Although it supports strong encryption and certificates, 2025 scans show that many servers are still misconfigured with the "None" security profile, leaving highly sensitive process data visible to any unauthorized user.
• S7: A proprietary protocol for Siemens PLCs, including the legacy S7-300 and modern S7-1500. Older S7 versions lack native authentication. Stuxnet exploited this by hijacking the engineering workstation's DLL (s7otbxdx.dll) to inject malicious logic blocks into programming sessions the PLC already trusted. While newer S7-1200/1500 models support encrypted S7CommPlus with anti-replay, many insecure legacy S7-300/400 units remain in active service.

While secure variants exist for almost every protocol on the list, their actual adoption in the field is remarkably low. There are several reasons for this, ranging from the "if it ain't broke, don't touch it" mentality of industrial engineering to the extreme longevity (and cost) of the hardware which can stay in service for 20–30 years. This longevity is also something we need to face in 10–12 years, when the NTP era rollover (2036-02-07) and Y2K38 (2038-01-19) happen. There are two distinct failure modes: the NTP rollover affects the protocol's 32-bit seconds field, while Y2K38 affects any system using signed 32-bit time_t, but both threaten long-lived field hardware.

Protocol view

For 2025, we will focus the study on 15 consistently monitored ICS/OT specific protocols throughout the year, adding 2 compared to the prior year. The global exposure remained around 180,000 on those protocols, with Modbus and Niagara FOX representing around half of all internet reachable ICS/OT devices. These kinds of measurements at scale are hard, but the ICS/OT space presents additional challenges given the nature of most devices' internet connections and their ephemeral IP addresses: the churn rate is high. Still, it is nevertheless useful to choose a metric and stick to it so we have some overall comparison on how things are evolving. In our study, the reader might already have noticed that we usually choose to show monthly unique IPs per protocol. We find it a good empirical metric, that is easy to communicate, easy to understand, and useful when comparing historical records. There are other advantages to this, as we will see further down.

Protocol Rankings

Figure 3. ICS/OT protocols, exposed unique IP addresses, per protocol per month.

There hasn’t been a huge fluctuation if you look across all these protocols, although we are noting some increased detections on some specific protocols, especially in some geographic areas. Not all protocols are equally concerning either, and we chose those 15 for a reason: they all live within our critical infrastructure.

Geographic view

Looking at the exposure of different countries on different protocols, we can see that each geography tells a different story. In the next chart, we show the monthly averages for 2025, counting unique IPs and protocols pairs (for top 30 countries with more exposures). Unlike last year, where we showed total exposures per year. Although this yearly count can be useful for some metrics, there is an issue with this approach if you want to use it as a proxy for total devices exposed at any single moment in time. The problem is that the ICS/OT space is characterized by a high level of IP churn rate. This means the IP addresses devices use are often ephemeral and change frequently. Because of this high churn, a total yearly exposure count could over-represent the true number of simultaneously exposed devices in any given time. A monthly count is better suited for comparisons, especially among different countries since it provides a more consistent and accurate snapshot of devices exposed at any given moment.

There might be a number of explanations for geographical changes over time, ranging from specific local vendors' market penetration to probe improvements or even high interaction honeypots being deployed as deceptive measurements. In some cases we have a clear understanding of the root cause, others need a more in depth study of the exact circumstances behind them.

Regardless, our empirical observations per protocols and per geographies show some interesting patterns, when we compare the averages of the first and last six-month periods of 2025 and measure the exposure growth (top 30 countries):

When looking at protocols per geographies, we noticed an overall increase in exposure of IEC104, Apcupsd, and ATG. Some protocols present a general downward trend, like Lantronix (except Brazil). Some countries have an overall exposure reduction but then have spikes in particular protocols, like Belgium on OPC-UA or Greece on CODESYS. Then there are countries where a lot of growth of exposure is observed across the board, like Russia or Portugal.

Notable deltas

Country-by-protocol deltas should be read with care and taken as a general direction and not as an absolutely correct number. With that framing, a handful of movements stand out enough to call out by name.

• Lithuania's IEC 104 exposure grew +107% over the year. IEC 104 runs substation telecontrol (breaker operations, protection settings, telemetry) and given Lithuania's NATO membership, Baltic geography, and the pattern of Russian and Iranian threat groups scanning for grid protocols through 2025, this is the single delta in the dataset most worth immediate follow-up. We flag this for coordinated investigation rather than treat it as a settled finding.
• Germany's apcupsd exposure grew +109%. apcupsd is the host daemon that manages APC UPS units; what is exposed is the Network Information Server on TCP/3551, not the UPS itself. A spoofed or MitM "master" can coerce slaved hosts into unexpected shutdowns, which in a dense data-center market (Frankfurt being one of the largest European interconnection hubs) maps to availability risk for whatever those UPSes back. The absolute count is still modest relative to Modbus or Niagara FOX, but the trajectory is steep.
• Portugal shows unusual breadth rather than a single spike: BACnet +59%, EtherNet/IP +37%, Modbus +86%, KNX +37%. Building automation, manufacturing, and universal OT all moved together. We don't have a confirmed cause for the cluster.
• Belgium moved the opposite direction on most protocols: Modbus −42%, KNX −50%, Niagara FOX −16%, while BACnet rose +80%. The pattern is consistent with targeted remediation on the declining protocols alongside a genuine building-automation expansion.

Two protocol pairings are worth noting regardless of country. Modbus growth in countries with significant port and energy infrastructure (Portugal +86%, Netherlands +56%) matters because Modbus has no native security and sits directly on physical actuation. And concurrent S7 and CODESYS growth, visible to varying degrees in the Netherlands, Romania, and Portugal, compounds PLC attack surface: the two cover most of the deployed process-control base between them, and exposure on both at once means an attacker doesn't need to be vendor-specific to reach control logic.

Apples and oranges

Although it is good to have an understanding of the absolute exposure count per country, it is not exactly easy to compare countries or even understand what exactly does that absolute value mean for a given country's reality. Are 1,100 exposures in Portugal a lot? How about 2,600 in the United Kingdom? And what country should be more concerned in that example, Portugal or the United Kingdom?

To have a better understanding of how significant the exposure for each geographical area is, we would need a value that is challenging to obtain: the total number of devices. That might exist for some very specific countries or areas, but rarely does. If you work at a medium/large organization, you know that having an inventory of all systems is a permanently ongoing job that is never quite done, let alone an entire country.

We have considered several approaches to tackle this issue and have a public statistical source we could use as an interesting proxy, ranging from using United Nations Industrial Development Organization data to EUROSTAT, but nothing seemed quite horizontal enough. Eventually we settled with energy consumption. There are decent statistics worldwide for energy consumption and energy consumption for the industrial sector.

With those values we can have an idea about the number of exposures per industrial tera-watt consumed, which is an interesting proxy for the number of organizations and establishments in a country. A country like Portugal, which has 86 TWh of industrial energy consumption, has less industries than the UK with 814 TWh. This seems to be a more interesting proxy than the population (like we used last year), for example. Why? Because the Industrial Sector is where most ICS/OT devices are located. This is a coarse measure and can obviously be improved, but it allows us to compare countries better between themselves and have an understanding of how serious the exposure is.

When normalized for industrial energy consumption, the ranking shifts dramatically, and the Portugal versus United Kingdom question posed earlier gets a clear answer. The UK, with 2,600 raw exposures, looks far more concerning in absolute terms, but if we consider its 814 TWh industrial footprint, it collapses toward the bottom of chart 2, as seen in Figure 6. Portugal, with 1,100 raw exposures against only 86 TWh of industrial consumption, sits notably higher in the normalized ranking. In other words, Portugal has significantly more exposed devices per unit of industrial activity, making it the more concerning country by this measure despite having less than half the raw count.

This is precisely the kind of inversion this proposed metric is designed to surface. Lithuania highlights this effect perfectly. Unremarkable in raw count, it becomes the clear outlier in chart 2, its exposure-to-industrial-TWh ratio dwarfing every other country in the dataset. Greece and Denmark follow at a significant distance, as well as small industrial economies that punch well above their raw-count weight. At the other extreme, the United States, China, Russia, and Japan all collapse toward the bottom once normalized, their enormous industrial energy footprints absorbing the exposure count.

The key caveats remain. Industrial energy consumption is a coarse proxy as it systematically undercounts exposure density in countries dominated by light manufacturing or high device-count low-energy industries and overstates the relative safety of heavy industry nations where few facilities consume disproportionate energy. These limitations do not undermine the approach, but they mean the normalized scores are better read as a relative risk signal than as a precise measurement, far from perfect but useful when trying to understand the ICS/OT country specific challenges. It allows us to compare, instead of apples and oranges, something more like Fujis and a Golden Delicious.

Systemic risk

Exposing operational technology to the Internet introduces risk of a different kind than IT exposure. ICS/OT devices are tightly coupled to physical processes such as fuel distribution, power regulation, building climate control, and industrial automation. The consequences of compromise carry into physical safety, equipment integrity, and service continuity, not just data confidentiality. And the exposures catalogued above don't sit in isolation. A single vulnerable CODESYS runtime version is shared across hundreds of PLC brands; a Moxa NPort misconfiguration in one facility is likely replicated across every other site the same integrator deployed; an unauthenticated IEC 104 gateway in one substation is almost certainly matched by identically configured peers across the same utility's footprint. ICS/OT exposure scales horizontally in ways IT exposure usually doesn't.

Our own research into Automatic Tank Gauging systems illustrates what this means in practice. We found thousands of these fuel-monitoring devices online, the vast majority lacking authentication and speaking insecure serial protocols over TCP/IP. In the worst case, they could be abused to cut off fuel access or tamper with safety-critical parameters at scale. Because these deployments follow common integrator patterns, an attack playbook developed against one site generalizes cheaply to many others. CISA’s recent guidance on hardening automatic tank gauge systems reinforces this point: the exposure of these devices is a live critical-infrastructure concern, not a hypothetical edge case.

We have been warned before, warned again and again that ICS/OT are an increasingly interesting target in cyberwar and hacktivism. Dragos' yearly report leaves no doubts for what is at stake: “The activity observed throughout 2025 reinforces an urgent reality: adversaries are already targeting infrastructure as it evolves.”

CyberAv3ngers, an IRGC-affiliated group that began compromising Israeli-made Unitronics Vision Series PLCs via default credentials, hasn't stopped. By 2025 the campaign had evolved to custom Linux-based OT malware to blend with legitimate traffic, and is now observed targeting Rockwell Logix controllers across water, energy, and government sectors. In March 2026, Jordan's National Cybersecurity Center (NCSC) confirmed thwarting an Iran-attributed attack on the national wheat silo management system, which attempted to manipulate silo temperature controls to spoil the strategic reserve.

And in May 2026, news surfaced about US officials suspecting Iran linked hackers being behind a series of breaches of systems that monitor the amount of fuel in storage tanks serving gas stations (ATGs).

ZionSiphon, flagged just some weeks ago by Darktrace, reveals that an OT‑focused malware targeting Israeli water treatment and desalination systems has been going around since mid 2025 too. It can specifically perform ICS/OT multi protocol scanning with sabotage capabilities aimed at chlorine and pressure controls.

Opportunistic actors have noticed, too. Groups like NoName057(16) have spent the past year cycling through ICS-protocol scan lists looking for soft targets to pair with their usual DDoS campaigns likely not because they have sophisticated ICS tradecraft, but because the targets are cheap to find and the headlines write themselves.

So what was the initial access in most cases? Devices exposed on the public internet, often behind cellular modems that bypass traditional monitoring.

Caveats and challenges

This study documents observations, and there are caveats worth being explicit about.

Honeypot contamination 
Any internet-wide scan for ICS/OT protocols captures honeypots alongside real devices. We apply filtering to remove known honeypots from the dataset, but any internet-wide scan will capture some that slip through: researcher deployments, vendor test infrastructure, commercial deception platforms, and defender-deployed decoys designed specifically to look like real devices. The residual honeypot component is real but bounded; readers should treat the monthly counts as close to, but not exactly, real-device exposure.

Single-protocol deltas 
Growth or decline in any single protocol's count over the year can reflect several factors, including but not limited to connectivity loss, packet drop, and catastrophic events. In an ideal world they should only reflect real changes in the field. Readers should treat single-protocol deltas as suggestive rather than conclusive.

Attribution 
Perhaps the most pressing operational caveat is attribution. Most ICS/OT assets are reachable via IPs we can only assign to Internet Service Providers (land, mobile, or satellite) rather than the actual facility or organization operating the device. We frequently observe:

• IPs linked to mobile broadband or 4G/5G M2M deployments
• Industrial gear behind dynamically assigned commercial IP space
• Devices reachable over public IPs from third-party service integrators

This introduces real friction into remediation. Even when we can confirm an exposed, vulnerable device, there's often no clear path to notify the operator or asset owner. And when the owner is unknown, it's not only nearly impossible to notify for remediation, it also means an organization may be indirectly dependent on an exposed device within its supply chain and never know. So what can be done?

The role of ISPs in ICS/OT security

ISPs have quietly become enablers of ICS/OT exposure. Whether knowingly or not, their networks host exposed control systems, many of them running critical processes our society depends on. Something I've argued before, and still believe, is that ISPs are in a unique position to help reduce systemic ICS/OT risk.

If involved, they could:

• Monitor for known ICS/OT protocols and exposure patterns
• Notify owners of vulnerable or exposed ICS/OT devices on their networks
• Collaborate with security vendors and CERTs to route alerts
• Flag high-risk traffic for upstream customer outreach

Given the current threat landscape, from criminal abuse to state-level adversaries targeting infrastructure, ISP visibility and participation is honestly an operational necessity. The growing scale of cyber warfare operations only accelerates that need.

General recommendations

ICS/OT exposure is as much a local problem as a supply chain risk. As Bitsight's Uncovering Cyber Risks in the Global Supply Chain report showed, the global digital supply chain is a tangled web of shared dependencies. Some vendors support tens of thousands of customers; others, while serving only a handful, account for up to 30% of revenue-weighted market share in a sector.

Think about it: it's not just your own Modbus relay online, it's your vendor's, your vendor's vendor's, and the unpatched remote desktop box they use to connect to both. Add software and hardware dependencies on top, and a water chlorinator in Spain can end up sharing firmware with a pump controller in Florida and a chemical valve actuator in Taiwan.

So how do we, as a society and at scale, deal with the ongoing rise of ICS/OT device exposure? There's no single fix, but rather a set of steps each stakeholder can take. Throwing blame around doesn't make our society safer. What makes sense depends on where you sit in the chain, but the following simple steps can be giant leaps towards resolving the problem:

For ISPs:

Help. Get involved. Act as a remediation partner, not just a transit provider. 
Monitor for protocol abuse and unsafe deployments. 
Treat exposed ICS/OT as a critical abuse category. 
Develop programs to accept reports and facilitate owner attribution.

For Manufacturers:

Stop shipping insecure-by-default devices. 
Phase out legacy protocol support where possible. 
Provide realistic guidance and tooling for secure deployment. 
Build programs to detect misconfigured or otherwise exposed systems in the field. 
Leverage CISA's Secure by Design and OT Cybersecurity Principles.

For ICS/OT Integrators and End Users:

Inventory and identify all ICS/OT devices. 
Remove unnecessary Internet exposure immediately. 
Implement segmentation, access control, and monitoring. 
Plan for incidents and run tabletop exercises. 
Use CISA's OT Cybersecurity Principles as a baseline for secure deployment and configuration hardening.

For Policymakers:

Recognise exposed ICS/OT as a public safety issue. 
Fund visibility and disclosure initiatives. 
Incentivise secure product design and lifecycle. 
Support coordination between vendors, ISPs, and operators. 
Quantify the impact, financial and otherwise, that a cyberattack on industrial infrastructure could inflict on national, regional, and local economies, as well as diplomatic relationships.

In closing

With decades of legacy, operational constraints that don't forgive downtime, and devices that outlive the engineers who installed them, ICS/OT carries baggage no other domain has to manage. A huge number of systems sit on the public Internet, many still fundamentally insecure, and the operational realities that made them hard to secure in the first place haven't gone anywhere. The reasons vary. The impact doesn't.

Dragos's 2026 year-in-review makes the operational picture plain: adversaries have moved past maintaining persistent access and are now actively learning the physics of their targets, exfiltrating configuration files and alarm data to understand how physical processes operate. That is the last barrier before an attacker can cause actual physical consequences, and it is being removed in front of us. Three new threat groups (AZURITE, PYROXENE, and SYLVANITE) illustrate the range: engineering-workstation targeting for process intelligence, supply-chain and watering-hole compromises (including a water utility serving the Haifa Bay Port area), and high-speed weaponization of edge device vulnerabilities within days of public proof-of-concept.

Meanwhile, defenders remain blind. Fewer than 10% of OT networks worldwide have network monitoring in place, and 30% of 2025 incident response cases were initiated because a human operator felt "something seems wrong."

The vulnerability ecosystem isn't helping either. Many advisories carried incorrect CVSS scores and 26% of public advisories shipped with no patch or mitigation advice at all. We need to make all stakeholders aware of the potential catastrophic dangers of continuing to ignore the security of these critical systems. And, again, ISPs can definitely be part of the solution.

Only 45% of organizations continuously monitor their environment to discover assets at risk according to Bitsight’s State of Cyber Risk and Exposure Report. Asset inventory and exposure management is critical to improve ICS/OT cybersecurity posture, and is the first line of defense. You can’t audit, segment or ultimately protect what you don’t know. Adopting secure protocols and protocol features (ex. EtherNet/IP CIP Security, Secure S7, OPC UA Security profile) is the next step and cannot be eternally postponed. Everyone involved in the ecosystem, from manufacturers to operators to ISPs, needs to act accordingly.

The supply-chain framing is usually read in one direction: your security posture depends on everyone upstream of you. The reverse is equally true and gets far less attention. If you operate, integrate, or ship ICS/OT systems, your exposed by default devices are a liability you inject into your customers' supply chain. An integrator who stands up a fleet of identically-configured PLCs across twenty customer sites has effectively published a playbook: compromise one, and the same credentials, the same exposed port, the same firmware version work on the other nineteen. Customers will increasingly hold these integrators accountable for it, and regulators will require them to: NIS2 and DORA in the EU already pull third-party ICT risk into the scope of regulated entities, and the CRA pushes further upstream still, to the product itself.

These systems control more than infrastructure and economies. We shouldn't need a major incident to happen to begin to take action. Their exposure has implications that go far beyond security: it is about safety, trust and continuity. It is completely unacceptable for these critical systems to be perpetually vulnerable to compromise for the same reasons, year after year: one default password, one exposed port, one obsolete device…

If this sounds familiar, it is because it is. Like a broken record.

Strategic partnerships that made this work possible

Schneider Electric has been instrumental in broadening Bitsight's reach into ICS/OT protocols and devices. Beyond that, they've moved from detection to remediation, coordinating with customers to locate exposed assets, alerting end users, and engaging authorities where relevant, while also advising on secure configuration, deployment, and maintenance practices. That posture lifts the entire ecosystem, not just their own product line.

EDP (Energias de Portugal) and Rockwell Automation's contributions came in a different but equally valuable form. Their hardware donations helped build out our ICS lab, which gives us the environment to test, simulate, and examine protocol behavior at scale.