jain.com — data centers, connectivity and security, analyzed daily

Tag: critical infrastructure

  • 100+ Water System Hacks Show AI Cooling Risk Sits Outside the Data Center

    100+ Water System Hacks Show AI Cooling Risk Sits Outside the Data Center

    TL;DR · 30-second read

    The Short Version

    In July, hackers broke into the control systems of a drinking-water provider in Oregon. Officials have not said which one. It was part of a wave that reached at least 100 American water systems in seven states.

    The attackers reached small computers that run pumps and valves over the internet and locked operators out. Some towns saw water pressure drop, flooding, or a precautionary boil-water notice.

    This matters beyond your tap. Many of the huge computer buildings behind artificial intelligence use local tap water to stay cool, so a hacked water utility is their problem too.

    Oregon Public Broadcasting reported on August 7, 2026, that Oregon Gov. Tina Kotek’s office confirmed hackers gained access to an Oregon water district’s core operating technology in July. Oregon Enterprise Information Services, which provides cybersecurity support to state agencies, confirmed a July incident involving unauthorized access to operational technology used by an Oregon drinking-water provider. State officials would not name the district, would not say whether the incident is linked to a wider campaign, and said the impact is still being assessed.

    The Oregon disclosure follows a July 30 New York Times report that at least 100 US water systems had detected malicious attacks, which the paper said were initiated by hackers in Iran. An FBI release the same day acknowledged attacks in seven states and said some of the activity degraded water operations. At least 30 systems were targeted in Minnesota, where one treatment plant temporarily went offline; in Georgia, one system lost water pressure and briefly issued a boil-water precaution.

    Executive Summary

    An unnamed Oregon drinking-water provider is the latest confirmed victim of a July campaign against municipal water and sewage systems. According to the FBI, attackers connected over the internet to programmable logic controllers, the small industrial computers that run pumps and valves, then changed their IP addresses and passwords, cutting operators off from monitoring and control. Reported effects included loss of pressure and flooding.

    For the data center industry, the episode matters because water is an operating input, not only a sustainability metric. Facilities that reject heat through evaporative cooling draw continuously on local utilities. The campaign shows that at least 100 of those utilities could be reached directly from the internet within days. A data center’s resilience therefore depends partly on the security of infrastructure it neither owns nor audits.

    The same class of controller also runs chilled-water plants, pumps and valves inside data centers. The FBI’s guidance to water utilities, to limit remote access and keep manual fallback procedures, reads as a checklist for cooling plant operators as well.

    What the FBI Says Happened

    The FBI’s description of the attack is short and specific. Between July 27 and July 30, attackers connected to programmable logic controllers (PLCs), rugged single-purpose computers that open valves, start pumps and read sensors, directly over the internet. They then changed the devices’ IP addresses and passwords, which the agency said resulted in a loss of monitoring and control. Operators could no longer see or steer parts of their own systems.

    The consequences were physical. The FBI said operational effects included loss of pressure and flooding, and warned that pressure loss could potentially allow untreated groundwater to seep into pipes. In Minnesota, where at least 30 systems were targeted, one treatment plant temporarily went offline. In Georgia, a pressure drop prompted a precautionary boil-water notice.

    Attribution remains partly open. The New York Times reported the campaign was initiated by hackers in Iran. Oregon officials declined to say whether their incident belongs to that campaign and referred questions to federal investigators. That caution is reasonable while the investigation continues, and the operational lessons do not depend on who was behind the attacks.

    Why AI Cooling Risk Sits Outside the Fence

    Many data centers remove heat with evaporative cooling towers, which lose water continuously to evaporation and replace it, as so-called makeup water, from the local municipal supply. AI clusters pack far more heat into each rack than conventional servers. Even when the chips are cooled directly by liquid, that heat still has to leave the building, and in many designs it leaves through those same towers. For a significant share of facilities, water pressure at the meter is as much a dependency as power at the substation.

    The failure modes the FBI listed match that dependency closely. A pressure loss or an offline treatment plant is exactly the event a cooling plant’s onsite water storage exists to ride through. What the July campaign changes is the likelihood and breadth of that event. At least 100 systems in at least seven states were affected in a matter of days. The technique did not require first breaching a corporate network, because the controllers were reachable from the internet. A risk that site selection teams once modelled as drought or main breaks now has a cyber path, and it can hit many utilities simultaneously.

    The people exposed are the ones who build, lease and finance capacity: operators sizing onsite storage, tenants whose service agreements assume cooling continuity, and lenders underwriting sites in water-dependent markets. Oregon hosts major data center clusters around Hillsboro, The Dalles and Prineville. Nothing disclosed so far indicates the affected district serves any of them. The point is structural, not local.

    The Same Controllers Run the Chiller Plant

    PLCs are not unique to water utilities. The same kind of device, often from the same vendors, sequences chillers, modulates pumps and controls valves in data center mechanical plants. Remote access is common there for the same reason Tualatin Valley Water District spokesperson Justin Dyke gave for utilities: it lets operators respond quickly when demand shifts. The convenience cuts both ways when a controller’s management interface is reachable from the open internet.

    The FBI’s recommendations to water systems translate almost directly. Limit remote access to controllers. Enforce authentication and other security protocols. Maintain manual procedures for when automation is lost. Dyke described that last practice at his district: if online systems go down, operators make changes by hand. Data center operators can apply the same test to their cooling plants and ask whether staff can run the chilled-water system safely with the controls network unavailable.

    A Defense Spread Across 2,500 Districts

    Oregon has more than 2,500 water districts, and all of its drinking-water systems are locally managed. Oregon Enterprise Information Services consults with districts on cybersecurity and threat assessments but does not run them. That structure is typical of US water and puts security decisions in the hands of many small operators with limited budgets and staff.

    It also limits disclosure. The Portland Water Bureau said it routinely examines vulnerabilities with the city’s security team, the Cybersecurity and Infrastructure Security Agency and the FBI, but declined to say whether it was targeted in July. Tualatin Valley reported an increase in attempts, none successful. Klamath Falls and Corvallis reported no increase, and Redmond and Bend reported no breach. For a large water customer, that patchwork means a utility’s security posture is mostly invisible unless the customer asks directly.

    Background

    Water utilities have spent years connecting their treatment plants, pumping stations and reservoirs to remote monitoring. This lets small operating teams adjust flow and reservoir levels quickly as demand changes. The same connectivity, when controllers are reachable from the internet, exposes physical equipment to remote tampering. Federal agencies, including the FBI and the Cybersecurity and Infrastructure Security Agency, work with utilities on these risks, but in states like Oregon, day-to-day operation and security remain local responsibilities.

    Oregon is also one of the country’s established data center markets, with large campuses around Hillsboro, The Dalles and Prineville. Water supply has featured in local debate about their growth. As AI workloads raise heat density per rack, cooling design, and for many facilities the municipal water behind it, has become a primary constraint on where and how capacity gets built.

    Sources

    Source: Oregon drinking water system accessed in recent cyber attacks (Oregon Public Broadcasting): Oregon officials confirm a July intrusion into a water provider’s operating technology amid a national campaign against water utilities.

  • Minnesota’s 30+ Water Systems Show Why a CISA OT Mandate Alone Won’t Protect Utilities

    Minnesota’s 30+ Water Systems Show Why a CISA OT Mandate Alone Won’t Protect Utilities

    TL;DR · 30-second read

    The Short Version

    Hackers have tampered with the computers that run water and sewage plants in at least seven American states. In Minnesota alone, more than 30 local water systems were targeted, allegedly by attackers working for Iran.

    A group of industrial security firms and plant operators wants the federal government to stop issuing warnings and start requiring basic protections. The catch: the rule they want would only cover federal government sites. Small-town water utilities would still rely on a federal grant program that Congress has not yet renewed.

    The Operational Technology Cybersecurity Coalition (OTCC) has called on the Cybersecurity and Infrastructure Security Agency (CISA) to issue a Binding Operational Directive setting baseline security controls for operational technology, the systems that run physical equipment, across federal civilian facilities. Industrial Cyber reported the statement on August 3, 2026. It follows the FBI’s confirmation, as of July 30, that water and wastewater utilities in at least seven states had reported cyber incidents, some of which disrupted operations. The worst impact was in Minnesota, where alleged Iranian-affiliated state actors targeted more than 30 water systems.

    The coalition also asked Congress to reauthorize and fund the State and Local Cybersecurity Grant Program, support Andrew McClure as director of the Department of Energy’s Office of Cybersecurity, Energy Security, and Emergency Response (CESER), and pass long-term authority for the Cybersecurity Information Sharing Act of 2015, which is set to expire at the end of September.

    Executive Summary

    The OTCC is asking Washington to move from advisories to requirements on industrial cybersecurity. Its headline request, an OT-focused Binding Operational Directive from CISA, would oblige federal civilian agencies to put fundamental controls on the systems that operate pumps, valves, power equipment and building infrastructure.

    The detail that matters most is one the coalition states itself: such a directive would not have applied to the Minnesota water utilities. OTCC executive director Tatyana Bolton argues its value lies in the demand signal it sends to the private sector. The coalition’s three requests to Congress are the measures that actually reach local utilities. They cover grant money for state and local defenders, energy-sector security leadership, and the legal basis for companies to share threat data with the government.

    For anyone who owns or depends on critical infrastructure, including energy, water and the data centers that draw on both, the practical question is whether those congressional levers move before the information-sharing law lapses at the end of September.

    A Mandate That Stops at the Federal Fence Line

    A Binding Operational Directive is a compulsory instruction from CISA to federal civilian executive branch agencies. It is not a regulation on industry. Bolton says so plainly: an OT directive “only applies to FCEB entities, and the water utilities in Minnesota would not have been required to implement the requirements.” The incident that prompted the call therefore sits outside the reach of the call’s headline remedy. More than 30 targeted water systems in one state, and reported incidents in at least seven, all involve utilities that are mostly local, not federal.

    The coalition’s argument for the directive is indirect. Federal requirements tend to become the reference point that vendors build to, insurers ask about and state regulators borrow. Bolton cites a 2024 National Security Agency directive covering OT on National Security Systems, which required security, reporting and inventory measures, as evidence that such a baseline is “not a novel or unimplementable idea.” That precedent supports the feasibility claim. Whether a federal-only directive changes behaviour at a small municipal water plant is a separate claim, and the coalition presents it as a signal rather than a mechanism.

    Who is affected, then? Federal civilian agencies would carry the direct compliance burden. The operators under active attack, small utilities with limited security staff, would see change only if the signal travels. That is why the coalition itself describes the directive as insufficient on its own.

    The Levers That Reach Local Utilities

    The requests aimed at Congress do more of the work for the actual victims. The State and Local Cybersecurity Grant Program funds state and local governments, and the coalition frames it bluntly: without it, Congress is “leaving small towns to protect themselves from nation-state actors like Iran.” For a utility serving a few thousand customers, the constraint is usually money and staff, not awareness of best practice. A grant program addresses that constraint. A federal directive does not.

    The Cybersecurity Information Sharing Act of 2015 matters for a different reason. It lets private companies pass technical threat data to the government. That flow is how agencies spot a campaign moving across sectors and warn the next target before it is hit, which is exactly the pattern of an attack wave that reached at least seven states. The coalition warns the US “can no longer rely on short-term extensions” with the authority due to expire at the end of September. A lapse would thin the evidence that the FBI and EPA warnings are built on.

    The request to back Andrew McClure at CESER extends the argument to energy. The Environmental Protection Agency leads on water, but the coalition notes that energy underpins all 16 critical infrastructure sectors, and CESER is responsible for protecting the OT that runs the grid.

    Internet-Exposed Controllers Are Everyone’s Problem

    The FBI and EPA warning centred on hackers targeting internet-connected industrial controllers. These are the small computers that open valves, run pumps and dose treatment chemicals. The same class of equipment runs substations, backup generation, and the chillers and power distribution inside commercial buildings and data centers. Bolton points to “increasing convergence between IT and OT,” meaning office-style networking reaching equipment that was once isolated. That convergence is why a technique proven against water plants is relevant well beyond water.

    For infrastructure operators outside the water sector, the lesson is not that their own facility was hit; nothing reported suggests that. The lesson is that their upstream dependencies, municipal water and the grid, run on controllers of this kind, often operated by organisations with far smaller security budgets than their largest customers.

    Weighing the Coalition’s Case

    The OTCC describes itself as a coalition of OT cybersecurity organizations and owners and operators. Firms that sell OT security stand to benefit from mandates, and readers can weigh the call with that in mind. The substance of the requests is modest, however. The directive covers only the government’s own systems, and the congressional items reauthorize or fund existing programs rather than create new regulatory regimes.

    The assertion that deserves the closest scrutiny is the demand-signal effect, which is plausible but not demonstrated in the statement. The strongest parts of the case are the concrete, dated items: an information-sharing authority with a known expiry, and a grant program whose absence falls hardest on the smallest operators.

    Background

    The Operational Technology Cybersecurity Coalition is an advocacy group of OT cybersecurity organizations and infrastructure owners and operators, led by executive director Tatyana Bolton. CISA, part of the Department of Homeland Security, coordinates national cyber defense and can issue binding directives to federal civilian agencies. For most privately and locally run infrastructure, however, it relies on advisories and voluntary guidance, alongside sector agencies such as the EPA for water and the Department of Energy for power.

    US water and wastewater service is delivered largely by local utilities, many of them small, which operate industrial control systems with limited security staff. Bolton points to repeated warnings that Chinese and Iranian actors have pre-positioned inside critical infrastructure, and to growing IT and OT convergence, as the backdrop to what the coalition calls years of guidance without enough action.

    Sources

    Source: OTCC urges CISA to issue binding OT cybersecurity directive after cyberattacks disrupt water utilities (Industrial Cyber). The OT Cybersecurity Coalition calls for a CISA OT directive and congressional action after attacks on water utilities in at least seven states.

  • Minnesota’s 30-Plus Water System Attack Shows Data Center Cooling Risk Starts Upstream

    Minnesota’s 30-Plus Water System Attack Shows Data Center Cooling Risk Starts Upstream

    TL;DR · 30-second read

    The Short Version

    A coordinated cyberattack hit more than 30 local public water systems in Minnesota this week. Federal investigators are now involved.

    The damage was small. One city’s well and treatment plant briefly shut down, and there are no signs the tap water became unsafe. Officials say early clues point to hackers linked to Iran, but that is not confirmed.

    Why it matters beyond Minnesota: the giant computer buildings behind apps and artificial intelligence often cool their machines with water from these same local utilities. A hack at the water plant is a risk to them too.

    A coordinated cyberattack affected more than 30 community water systems in Minnesota in the week of July 27, according to Minnesota IT Services, the state’s technology agency, Al Jazeera and Reuters reported on July 30. Local officials said the well and treatment plant in at least one city temporarily went offline, but the attack appears to have had minimal impact, and there are no indications the water supply became unsafe to drink. The FBI said on Wednesday that it was “actively engaged with victims.”

    State officials said the incidents resemble activity attributed to hackers aligned with Iran’s government, and cautioned that the assessment is preliminary. The New York Times, citing unnamed state and federal officials, reported that Iranian hackers were the likely culprits, while noting that attribution is not definitive and that the attackers may have posed as Tehran-aligned actors. The attack comes amid renewed US–Iran hostilities after a June memorandum of understanding that paused the fighting broke down this month.

    Executive Summary

    More than 30 local water systems in a single US state were hit in what state officials called a “coordinated cyberattack.” The physical consequences were limited: one city’s well and treatment plant briefly went offline, and drinking water was not reported unsafe. But the breadth of the event and the FBI’s involvement put the security of utilities’ operational technology (OT) — the industrial control systems that run pumps, wells and treatment processes — back at the top of the critical-infrastructure agenda.

    For the data center industry, the relevance is indirect but concrete. Many facilities that use evaporative cooling draw their water from municipal systems like these. The Minnesota incident is a reminder that a data center’s cooling supply depends not only on its own cybersecurity but on the cybersecurity of utilities it neither owns nor controls, and whose security resources are set by local public budgets rather than by the data center.

    No data center has been reported as affected, and attribution of the attack remains preliminary. The episode’s value for operators is as a live test of a common assumption: that water outages are local, physical events rather than coordinated ones spanning many utilities at once.

    The Cooling Risk Sits Outside the Fence

    Data centers that use cooling towers or other evaporative systems reject heat by evaporating water, which has to be continuously replaced — industry shorthand calls this “makeup water.” Where a campus draws that water from a municipal utility, the utility’s wells, pumps and treatment plant become part of the data center’s cooling chain. Those assets are run by OT: programmable controllers and supervisory software that start pumps, open valves and dose chemicals. An intrusion that reaches them is, for every large water customer downstream, a cooling-supply risk.

    Minnesota shows what that looks like in practice. More than 30 community water systems were affected in a single coordinated event, and in at least one city the well and treatment plant went temporarily offline — precisely the kind of interruption that stops water flowing to a large commercial customer. Water resilience planning has traditionally centered on familiar, local failures: a main break, a drought restriction, a fault at one plant. A coordinated intrusion is different in kind, because it can reach many independent systems at once, which may also affect neighboring utilities or backup supplies an operator expected to lean on.

    The exposure is not uniform. AI training and inference hardware concentrates far more heat per rack than conventional servers, pushing operators toward liquid cooling and larger heat-rejection systems. Closed-loop liquid cooling and air-cooled chillers consume little water; evaporative designs trade lower electricity use for continuous water dependence. The operators most exposed to an event like Minnesota’s are water-reliant sites on a single municipal feed with limited on-site storage. Nothing reported so far indicates that any data center served by the affected systems saw an interruption, and the outage that did occur was brief.

    Minimal Impact Is the Good News, Not the Whole Story

    The most important outcome is that drinking water was not reported unsafe and service disruption appears to have been limited. That is a credit to the utilities and responders involved, and it should temper any alarm.

    But officials’ own description points to a campaign rather than a one-off. Minnesota IT Services spokesperson Emily Zimmer said “the timing, methods of access, and targeted infrastructure share characteristics with other coordinated cyber incidents our federal partners have observed involving critical infrastructure.” Community water systems often run lean, with limited dedicated security staff, which makes a campaign that sweeps many of them at once hard to defend against one utility at a time.

    The number that matters for infrastructure planners is therefore the 30-plus, not the single outage. Breadth indicates that access was obtainable across many separate operators simultaneously. A contained result this time says more about where the attackers stopped than about how far they could have gone.

    Attribution Is Unsettled; the Threat Picture Is Not

    State officials said the incidents resemble those attributed to Iran-aligned hackers but called that assessment preliminary. Officials cited by The New York Times said Iranian hackers were the likely culprits, while acknowledging the conclusion could change and that the attackers may have impersonated Tehran-aligned groups to raise tensions. Former intelligence officials told the paper a false-flag operation was less likely. The fair reading is that the available indications point one way but are not conclusive, and no technical evidence has yet been published that would let outside analysts test either view.

    For defenders, final attribution matters less than the context. Water infrastructure has become a target across the current conflict: reported US strikes have hit Iranian water plants, and Iran has targeted desalination plants in neighboring Gulf states. Whoever is ultimately responsible for Minnesota, that backdrop raises the baseline risk to water-sector OT, and to every large customer that depends on it.

    What Operators Can Ask Their Water Utility

    Data center operators cannot secure a municipal utility’s control systems, but they can reduce how much a compromise of them would cost. Practical steps include confirming how and how quickly the utility will notify large customers of a cyber incident, knowing how many hours of cooling the site’s on-site water storage actually covers, qualifying alternative supplies such as reclaimed water or trucked delivery, and weighing low-water cooling designs for new builds.

    The relationship can run both ways. Large water customers have a direct stake in their utility’s security posture, and utilities facing coordinated campaigns have an interest in knowing which customers carry the highest consequences from an outage. Minnesota makes that conversation easier to start.

    Background

    Water utilities are among the more exposed parts of US critical infrastructure: many are small, locally run and operate industrial control systems designed for reliability rather than security. US agencies have previously linked attacks on water-sector equipment to Iran: in late 2023, intrusions into industrial controllers at several US water utilities, including the Municipal Water Authority of Aliquippa in Pennsylvania, were attributed to a group affiliated with Iran’s Islamic Revolutionary Guard Corps.

    Data centers become significant water users when they rely on evaporative cooling, which trades lower electricity use for continuous water consumption. As AI workloads raise heat density, cooling design, and the water supply behind it, has become a central siting and permitting question. The Minnesota incident arrives amid renewed US–Iran hostilities: the US joined Israel in a war against Iran on February 28, and a June memorandum of understanding that paused the fighting broke down in July.

    Sources

    Source: US authorities probe cyberattack on water systems in Minnesota – Al Jazeera — Al Jazeera and Reuters on a coordinated cyberattack affecting more than 30 Minnesota community water systems and the federal response.

  • AI Breaches Now Cost $6M. IBM’s Data Says the Weak Spot Is Fixing, Not Finding

    AI Breaches Now Cost $6M. IBM’s Data Says the Weak Spot Is Fixing, Not Finding

    TL;DR · 30-second read

    The Short Version

    Criminals used artificial intelligence in about one in four serious hacking attacks last year, according to a yearly study backed by IBM. Many of those attacks used fake videos or voices to impersonate real people.

    Each of those attacks cost the victim about $6 million to deal with, roughly $1 million more than a typical break-in. Launching one can cost the attacker only thousands.

    The surprise: about half of companies use automated tools to spot attacks, but fewer than one in five use them to fix known weak spots before criminals get there.

    IBM said on July 29, 2026 that one in four malicious breaches in its 2026 Cost of a Data Breach Report were AI-enabled, which it described as a 56% increase over last year. Those breaches, mostly deepfake impersonation and AI-enabled malware, cost an average of $6 million, roughly $1 million more than the $4.99 million global average across all breaches in the study.

    The report, conducted by Ponemon Institute and sponsored and analyzed by IBM, covers breaches at 602 organizations worldwide between March 2025 and February 2026. A follow-on survey in May 2026 drew responses from 456 of those organizations.

    Executive Summary

    The headline number is the cost premium. By IBM’s account, AI-enabled breaches cost about 20% more than the average breach, while the attacks themselves are getting cheaper and faster to launch. IBM frames this as a shift in the economics of cyber risk: attacks that cost thousands to mount now produce losses in the millions.

    The more useful finding for security and infrastructure teams sits further down. More than half of organizations use AI agents, meaning software that can take actions on its own, to detect and contain threats. Only 18% use them for vulnerability management, the work of finding and fixing known flaws. IBM ties breach costs directly to the lag between discovering a problem and fixing it.

    The report also finds that more than 20% of organizations had a breach aimed at their AI models or applications. The most common causes were not exotic attacks on the models but ordinary weaknesses around them: exposed APIs and plug-ins, and misconfigured cloud environments running AI workloads.

    Thousands to Launch, Millions to Clean Up

    IBM’s central argument is that AI has widened a cost asymmetry that already favored attackers. Deepfake impersonation, in which synthetic audio or video of a real executive or colleague is used to trick staff into sending money or granting access, costs little to produce. AI-enabled malware can be adapted and scaled with less human effort. On the other side of the ledger, IBM puts the average AI-enabled breach at $6 million, against a global average of $4.99 million.

    That premium deserves careful reading. The release says AI-driven attacks were concentrated in financial services and energy, where average breach costs were $6.3 million and $5.2 million respectively. Some of the $1 million gap may therefore reflect which industries AI-enabled attackers targeted rather than anything intrinsic to AI-enabled techniques. The release does not say whether IBM controlled for sector or company size, so the premium is best treated as an observed average, not a measured effect of AI.

    The 56% increase is also stated without its base. Readers can infer that AI-enabled breaches were a meaningfully smaller share of the total a year earlier, but the release does not give last year’s figure.

    Finding Is Automated. Fixing Is Not.

    This is where the report’s numbers point to an operational conclusion. More than 50% of organizations reported using AI agents for threat detection and containment. Only 18% apply them to vulnerability management. In practice, many security teams have automated the alarm but not the repair: they can see an intrusion faster, but the known software flaws and misconfigurations that let attackers in are still patched on human timelines.

    IBM argues that this gap matters more as AI shortens exploit windows, the time between a weakness becoming known and attackers using it. Suja Viswesan, VP of IBM Security Software, put it directly: “When organizations have an extended gap between discovery and remediation, that imbalance shows up directly in breach costs.” IBM’s stated priority is to build remediation into development workflows and secure identity at runtime.

    The report’s other findings fit the same pattern of known, fixable exposure. Only 37% of breached organizations encrypt sensitive data both at rest and in transit, and just 34% have visibility into their cryptographic assets. The leading causes of AI-model breaches, compromised APIs and cloud misconfigurations, are well-understood problem classes rather than novel ones. Organizations using AI and automation in security operations cut breach costs by almost $2 million on average, per IBM, yet one in four have not adopted them at all. The release does not isolate the cost of slow remediation as a single number, so this conclusion rests on the deployment gap and the pattern of causes rather than a direct measurement. It is nonetheless the clearest reading of the data IBM published.

    AI Workloads Get Breached Through the Plumbing

    For data center and cloud operators, the most relevant statistic is that more than 20% of organizations reported a breach targeting AI models or applications. The two leading causes tied at 27% each: compromised APIs, applications or plug-ins, and cloud misconfigurations affecting AI workloads. APIs are the interfaces that let software systems talk to each other, and plug-ins extend what an AI application can reach. Both widen the surface an attacker can probe.

    This shifts attention away from attacks on model internals and toward the infrastructure surrounding them. AI workloads tend to sit in cloud environments with broad data access, many service connections and fast-changing configurations. Responsibility for those settings is typically split between the provider and the customer. When the weak point is a permissive storage setting or an unauthenticated endpoint, the fix is configuration discipline and access control, not a new class of AI security product.

    Critical Infrastructure and a Shift in Spending Intent

    IBM reports that 62% of AI-driven attacks targeted critical infrastructure sectors, with financial services and energy most affected. The company warns of cascading effects across supply chains and essential services. Energy is directly relevant to the AI buildout, since utilities and grid operators are central to powering new data center capacity. The release does not break down attacks on energy by subsector or describe any operational disruption.

    The follow-on research suggests awareness of advanced AI capabilities is moving budgets more than breaches do. Among surveyed organizations, 85% said they plan to increase security spending after learning about frontier AI cyber capabilities, compared with 64% that planned increases after experiencing a breach. These are stated intentions, not committed budgets, and 78% of follow-on respondents were aware of reports about frontier models such as Mythos. Three quarters said frontier AI threats are prompting them to rethink how agents are deployed across security operations. That suggests the remediation gap is recognized, even if it has not yet closed.

    Background

    The Cost of a Data Breach Report is a long-running annual benchmark produced by Ponemon Institute, a privacy and security research firm, and sponsored and analyzed by IBM. It surveys organizations that suffered breaches and estimates the full cost of each incident, including detection, containment, notification, lost business and recovery. Security leaders and insurers widely cite its averages when setting budgets and pricing risk.

    The 2026 edition is the first in which AI appears across nearly every finding. It covers AI as an attack tool through deepfakes and malware, as a defensive tool through agents and automation, and as a target through breaches of AI models and the cloud systems that host them. IBM is a hybrid cloud, AI and consulting company that also sells security software and services.

    Sources

    Source: IBM Study: One in Four Malicious Breaches are AI-Enabled, Costing Companies $6 Million on Average, IBM Newsroom’s July 29, 2026 announcement of its 2026 Cost of a Data Breach Report findings.

  • Gold Eagle’s 4-Agency Clearinghouse Shows AI Bug-Finding Now Needs a Triage Desk

    Gold Eagle’s 4-Agency Clearinghouse Shows AI Bug-Finding Now Needs a Triage Desk

    TL;DR · 30-second read

    The Short Version

    The White House has set up a central office, called Gold Eagle, where government agencies and the companies that run essential services like power, water and communications networks can pool security weaknesses that artificial intelligence finds in software.

    Why it matters: artificial intelligence can now search huge amounts of software for weak spots, and different groups often find the same ones. Gold Eagle is meant to sort that pile, drop the duplicates and tell defenders what to fix first. Taking part is voluntary.

    On July 14, 2026, the White House announced Gold Eagle, a federal clearinghouse for sharing AI-derived cybersecurity vulnerability information between government agencies, “American critical infrastructure companies” and “open-source software partners,” Covington & Burling’s Inside Privacy blog reported. The clearinghouse was established under Executive Order 14409, “Promoting Advanced Artificial Intelligence Innovation and Security,” which directed the Secretary of the Treasury to form it in consultation with the National Cyber Director, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA).

    According to the White House, Gold Eagle has already begun intake and prioritization of vulnerabilities “from across industries and sectors” and is coordinating “scanning verifications.” A day later, on July 15, CISA, the NSA and cyber agencies from the United Kingdom, the Netherlands and Japan issued joint guidance on coordinated vulnerability disclosure.

    Executive Summary

    Gold Eagle is a coordination body, not a scanning tool. Its stated purpose is to “leverage frontier AI capabilities to continue advancing faster than adversaries, reduce duplicative scanning efforts, and deliver prioritized and actionable threat and remediation information to defenders across the federal government and the private sector.” In practice, that means taking in software flaws surfaced by advanced AI models, verifying them, removing duplicates and handing defenders a ranked list of what to fix.

    The design matters because it signals where the government sees the problem. If AI has made finding vulnerabilities cheap and fast, the scarce resources become verification, prioritization and repair. For operators of critical infrastructure, including the data centers, network carriers and cloud platforms other sectors depend on, the practical question shifts from “what is vulnerable?” to “how quickly can we act on an authoritative must-fix list?”

    Participation is voluntary, and key operating details, including who has joined, how findings are protected and how quickly they are disclosed, had not been made public as of the announcement.

    Why AI Bug-Hunting Needs a Triage Desk

    Gold Eagle’s job, as described, is not to find vulnerabilities but to sort them. Executive Order 14409 structures it around four federal players, with Treasury leading in consultation with the National Cyber Director, the NSA and CISA, and tasks them to “coordinate and deconflict” the identification and remediation of software flaws. Deconflict is the telling word: it is what you do when many parties are working the same terrain and getting in each other’s way. The White House’s own framing, reducing “duplicative scanning efforts” and delivering “prioritized” information, points the same direction.

    The mechanism is straightforward. Frontier AI models, the most capable general-purpose systems from leading labs, can be pointed at large bodies of code and return candidate vulnerabilities in volume. When AI developers, agencies, security firms and independent researchers all scan the same widely used libraries, the same flaw can surface repeatedly, and every report lands on a maintainer or operator who has to check whether it is real. A clearinghouse that verifies once, collapses duplicates and ranks by severity turns a flood of raw findings into an ordered queue. The “scanning verifications” the White House says Gold Eagle is already coordinating are exactly that step.

    For critical infrastructure operators, the consequence is that the constraint moves downstream. A ranked advisory is only useful if the recipient can act on it: test a patch, book a maintenance window, push a firmware update (the low-level software built into hardware) to equipment that cannot simply be switched off. Gold Eagle can shorten the path from discovery to a prioritized warning; it cannot shorten an operator’s change-control process. The organizations that gain most will be those whose patching pipelines can absorb a faster, more authoritative stream of must-fix items. Those running always-on facilities with long approval cycles will feel the gap between knowing and fixing most sharply.

    Open-Source Maintainers Are the Pressure Point

    The announcement names “open-source software partners” alongside agencies and critical infrastructure companies, and that inclusion is significant. Much of the software running in data centers, telecom networks and industrial control systems is built on open-source components, freely available code often maintained by small teams or volunteers. If AI-driven scanning multiplies the number of credible reports, those maintainers carry the verification and repair burden before any operator can deploy a fix.

    The July 15 guidance addresses the other side of that exchange. CISA, the NSA, the UK’s National Cyber Security Centre, the Netherlands’ National Cyber Security Centre and Japan’s computer emergency response coordination center, five agencies from four countries, set out best practices for coordinated vulnerability disclosure: reporting a flaw privately to whoever can fix it and publishing details once a fix exists or an agreed deadline passes. The guidance urges software makers and online service providers to adopt transparent processes for receiving, evaluating and remediating reports. Read together, the two moves work both ends of the pipe: centralize intake of AI-found flaws, and press software producers to have a working front door ready when those findings arrive.

    Voluntary by Design, Concentrated by Nature

    Gold Eagle rests on voluntary collaboration with the AI industry and critical infrastructure operators, so its value will track who joins and how much they share. Information-sharing programs have long had to address the same hesitations: legal exposure, competitive sensitivity and the reputational cost of disclosing one’s own weaknesses. A new clearinghouse inherits those questions, and its early participation will be the clearest indicator of whether industry sees it as useful.

    A central store of verified, prioritized and not-yet-fixed vulnerabilities affecting critical infrastructure is also, by its nature, a high-value target. That is not an argument against the model, since coordination usually requires some concentration of information. But it makes the clearinghouse’s own security, access controls and disclosure timelines material design questions rather than administrative details, particularly for operators deciding whether to contribute findings about their own systems.

    Background

    The federal government has long encouraged private-sector sharing of cyber threat and vulnerability information, with CISA, part of the Department of Homeland Security, serving as the main civilian coordinator and the NSA contributing on the national security side. Critical infrastructure covers the systems society depends on, including energy, water, communications and information technology, which in turn rely on the data centers and networks that carry their traffic.

    The rise of highly capable AI models has changed the economics of finding software flaws: automated systems can now analyze large codebases at a scale that manual review cannot match. Gold Eagle, created under Executive Order 14409, is the Administration’s latest action on AI-enabled cybersecurity and an attempt to channel that capacity into a single, prioritized stream for defenders.

    Sources

    Source: White House Launches “Gold Eagle” AI Cybersecurity Clearinghouse, Inside Privacy (Covington & Burling), on the White House’s launch of a federal clearinghouse for AI-derived vulnerability information under EO 14409.

  • CISA’s Coming 72-Hour Rule Makes AI Data Center Incident Response a Contract Term

    CISA’s Coming 72-Hour Rule Makes AI Data Center Incident Response a Contract Term

    TL;DR · 30-second read

    The Short Version

    The US government’s cybersecurity agency plans to finish new rules in September 2026. They will require essential services, likely including hospitals, banks and power companies, to report serious hacks within three days and any ransom paid to hackers within one day.

    The catch: many of these organizations run their computers inside buildings owned by someone else, including the huge data centers being built for artificial intelligence. A customer can only meet a three-day deadline if the building’s operator tells it about a break-in fast. Expect the contracts between them to get much stricter.

    The Cybersecurity and Infrastructure Security Agency (CISA) expects to issue its final rule under the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) in September 2026, Hunton Andrews Kurth reported on July 17. The rule will require covered critical-infrastructure entities to report covered cyber incidents to CISA within 72 hours and ransom payments within 24 hours.

    The date comes from a preview of the 2026 Unified Agenda, the federal government’s schedule of planned regulatory actions. CISA missed the statutory October 2025 deadline, then set an internal target of May 2026. Town halls originally planned for March and April were postponed by a lapse in Department of Homeland Security funding and held June 15 through 18, drawing more than 1,200 stakeholders over four days.

    Executive Summary

    CIRCIA is the first cross-sector federal mandate requiring critical-infrastructure operators to report cyberattacks to a single agency. After a proposed rule in April 2024 and more than a year of slippage, a final rule is now expected in September 2026, with the two headline obligations unchanged: 72 hours to report a covered cyber incident and 24 hours to report a ransom payment.

    For the data center and cloud industry, the most immediate consequence may come less from whether operators are themselves covered and more from their customers’ obligations. Hospitals, banks, utilities and other covered entities increasingly run critical systems in third-party facilities and clouds, and the statute explicitly contemplates incidents that begin with a compromised hosting provider. A customer’s 72-hour clock therefore depends on how quickly and completely its provider tells it what happened, which turns incident notification into a negotiated contract term.

    The practical window is short. Organizations that may be in scope should assess coverage against the proposed criteria, align incident response plans with the reporting deadlines, and review provider and customer agreements before the final text lands.

    A Tenant’s 72-Hour Clock Runs Through Its Data Center

    Under CIRCIA, the reporting duty sits with the covered entity: the hospital system, bank, utility or other organization that meets the final rule’s criteria. The 72-hour window runs from the point that entity reasonably believes a covered incident has occurred. Much of that entity’s computing, however, no longer sits in buildings it owns. It runs in colocation facilities, where a tenant rents space, power and cooling inside someone else’s building, and in public and GPU clouds, where it rents the computers themselves. The 2022 statute anticipates this: among the incidents the rule is meant to capture, it lists unauthorized access facilitated through the compromise of a cloud service provider, managed service provider or other third-party data hosting provider.

    That places the provider’s detection and notification speed directly on the customer’s compliance path. A covered tenant cannot report what it has not been told, and it needs enough detail from its provider (what was accessed, when and how) to file a report that meets CISA’s content requirements. Breach-notification clauses are not new, but a binding federal deadline gives customers a concrete number to negotiate against: notification windows well inside 72 hours, named incident contacts, and obligations to share forensic detail. If a provider is itself swept in by the final size- or sector-based criteria, it will be running its own clock in parallel with its customers’.

    The AI buildout sharpens the problem. New AI capacity is often delivered in layers: a facility owner, a GPU cloud or managed-infrastructure provider operating inside that facility, and the enterprise or model developer consuming the compute. Each layer is a hand-off in the notification chain, and each hand-off consumes hours of the covered entity’s window. Operators whose customer lists include regulated industries should expect incident-notification terms to be negotiated with the same seriousness as power and uptime commitments.

    Three Targets, One Missed Deadline, No Final Text Yet

    The timeline explains why caution is warranted. The statute required a final rule by October 2025. CISA missed that date and set an internal target of May 2026, citing the volume of comments on the April 2024 proposal and an intent to streamline requirements. Town halls meant to inform the final text were then pushed from March and April into mid-June by a Homeland Security funding lapse. September 2026 is the third target date.

    CISA has signalled that it wants to streamline the rule but has not said how. Streamlining could mean narrower coverage, fewer required data fields, clearer thresholds for what counts as a reportable incident, or some combination. Until the text is published, the April 2024 proposal remains the best available guide, which is why the practical advice is to assess coverage against its proposed sector-based and size-based criteria rather than wait. The turnout of more than 1,200 stakeholders at the June sessions suggests how many organizations believe they may be affected.

    Unified Agenda dates are projections, not commitments, and this rule has slipped before. Publication of a final rule is also not the same as the start of reporting obligations; the effective date and any transition period will matter as much as the publication date. Operators should treat September as a planning anchor, not a certainty.

    The 24-Hour Ransom Report Tests Governance, Not Just Tooling

    The 24-hour window for reporting a ransom payment is the tighter of the two deadlines. Ransom decisions typically involve executives, legal counsel and cyber insurers, not the security team alone. A one-day reporting clock after payment means the documentation behind that decision (who approved it, how much was paid, to whom, and why) has to be assembled as the decision is made, not reconstructed afterward. Organizations without pre-assigned authority and a documented escalation path will find the deadline hard to meet.

    CIRCIA also lands on top of existing obligations. Public companies already face the SEC’s requirement to disclose material cybersecurity incidents within four business days of determining materiality, and several sector regulators have their own notification rules. The statute provides an exception where an entity reports substantially similar information to another federal agency under an agreement with CISA, but how widely that exception applies will depend on agreements not yet described. A data center operator serving customers across several sectors may find that its customers each face a different combination of deadlines, and that each will expect its provider’s notification terms to fit.

    The intended payoff is real. CISA’s stated purpose is to deploy help to victims quickly, analyze reports across sectors for patterns, and share warnings with other defenders. For infrastructure operators, better cross-sector visibility into attack trends is a genuine benefit; the cost is process discipline that has to be in place before the first incident, not after.

    Background

    The Cybersecurity and Infrastructure Security Agency is the component of the Department of Homeland Security responsible for coordinating the protection of US critical infrastructure against cyber and physical threats. Before CIRCIA, cyber incident reporting to the federal government was largely voluntary or governed by a patchwork of sector-specific rules. CIRCIA, signed in March 2022, directed CISA to create a single cross-sector reporting regime, and CISA published its proposed rule in April 2024, setting out proposed coverage criteria, the scope of reportable incidents, and required report contents.

    Data centers and cloud platforms sit underneath much of that critical infrastructure, hosting systems for healthcare, finance, energy and government customers. As AI demand drives new capacity, more of those workloads run in shared facilities and layered provider arrangements, which is why the reporting rules matter to operators whether or not they end up directly covered.

    Sources

    Source: CISA Plans to Finalize Cyber Incident Reporting Regulations in September 2026 (Hunton Andrews Kurth), on CISA’s expected timeline for the CIRCIA final rule and its 72-hour and 24-hour reporting requirements.

  • Gold Eagle’s Four-Agency AI Bug Hunt Shows Why Patching Is the Grid’s Real Limit

    Gold Eagle’s Four-Agency AI Bug Hunt Shows Why Patching Is the Grid’s Real Limit

    TL;DR · 30-second read

    The Short Version

    The White House has launched Gold Eagle, a program that uses the most advanced artificial intelligence systems to hunt for hidden flaws in the software that runs power grids, banks and the buildings that house the internet.

    Four parts of the federal government share the lead, working with private companies. Finding flaws faster is the easier half. Fixing them is harder: a power grid cannot simply switch off to install an update. The real test is how quickly operators can make repairs.

    The White House on Tuesday, July 14, launched the Gold Eagle Initiative, a cybersecurity vulnerability coordination clearinghouse meant to speed the identification, prioritization and remediation of software flaws across U.S. critical infrastructure, Industrial Cyber reported. The initiative was established under Executive Order 14409, the June 2 order on advanced artificial intelligence innovation and security.

    Gold Eagle is led jointly by the White House, the Treasury Department, the Department of Homeland Security through the Cybersecurity and Infrastructure Security Agency (CISA), and the Department of War, working with open-source software partners and critical infrastructure companies. It will use frontier AI, meaning the most capable current AI models, for faster exploit detection and prioritized threat sharing, and it has already begun collecting and prioritizing reported vulnerabilities across sectors.

    Executive Summary

    Gold Eagle is a coordination model, not a new regulation. The administration says it will draw on existing federal authorities and resources to cut duplicative vulnerability scanning, verify reported flaws once, and push prioritized, actionable remediation information to defenders in government and the private sector. The pitch is efficiency: many organizations currently scan for, triage and verify the same weaknesses independently.

    The significance for infrastructure operators lies in what happens after a flaw is found. AI-assisted discovery can increase the volume and speed of credible vulnerability reports reaching utilities, data center operators and their equipment vendors. For information technology systems, patching is routine. For the operational technology that controls power, cooling and physical processes, every fix competes with uptime, safety testing and vendor certification.

    That makes remediation capacity, not detection, the measure that will determine whether Gold Eagle materially reduces risk in the grid and data center sectors. The announcement describes the front half of that pipeline in detail and the back half only in general terms.

    A Clearinghouse, Not a Mandate

    The structure the administration describes is a central intake point for vulnerabilities: reports are collected, de-duplicated, verified and ranked, then routed to the organizations that must act on them. Frontier AI is positioned as the accelerant for both discovery and triage. Nothing in the announcement creates new reporting obligations for private operators; it frames Gold Eagle as a way to use “existing federal authorities and resources” more effectively and to “amplify collaboration between government and industry.”

    That design choice matters. A voluntary, collaboration-based model can move quickly because it does not wait on rulemaking, and the announcement says work is already under way. The trade-off is that its reach depends on which companies choose to participate and how much they share. The officials’ statements lean heavily on rhetoric, with references to a “wartime footing” and “unprecedented coordination,” but the announcement provides no participant list, volume figures or performance targets against which those claims can be measured yet.

    Why Patching, Not Finding, Is the Constraint

    The mechanism Gold Eagle describes covers identification, prioritization and verification, and then delivers “prioritized and actionable threat and remediation information to defenders.” The actual fix still lands on two groups outside the clearinghouse: the vendors who must write and validate a patch, and the asset owners who must install it. If frontier AI does what the administration expects and surfaces more credible flaws faster, the four federal leads will be increasing the flow into a pipeline whose downstream end they do not control.

    In operational technology, that downstream end is narrow. The programmable controllers, protection relays and supervisory systems that run a substation, and the building management, power distribution and cooling controls that keep a data hall online, are designed to run continuously for years. Updating them typically requires firmware validated by the equipment maker, testing against safety functions, and a scheduled maintenance window in which redundancy is temporarily reduced. A utility or colocation operator cannot absorb an unlimited number of those windows, and some legacy devices cannot be patched at all, leaving compensating controls such as network segmentation as the only near-term option.

    This is where Gold Eagle’s prioritization promise has real value, and also where it will be tested. A ranked list that tells an operator which of many findings is most exploitable in their environment helps them spend scarce maintenance windows well. An unranked or poorly contextualized flood of findings would do the opposite. The people most affected are control-system engineers at utilities, facility and critical-environment teams at data centers, and the product-security staff at industrial equipment vendors, all of whom have finite capacity to act on what Gold Eagle produces.

    What Grid and Data Center Operators Should Prepare For

    The operators best positioned to benefit are those that already know what they run. Prioritized advisories are only actionable if an organization can quickly match a flaw to a specific firmware version on a specific device, which requires an accurate asset inventory and, increasingly, software bills of materials from vendors. Operators without that inventory will receive the same intelligence but struggle to use it.

    Procurement is the second lever. Contracts for switchgear, uninterruptible power systems, cooling plant and building management platforms can specify how quickly a vendor must deliver a validated patch after a credible vulnerability is reported. If Gold Eagle accelerates disclosure, those terms become more consequential. Smaller utilities and regional data center operators with thin security staff are the most exposed to a gap between what they are told and what they can fix, and they may lean more on managed security providers and vendor support as a result.

    Open Source and the Question of Trust

    The inclusion of open-source software partners is notable, because much critical infrastructure software depends on open-source components maintained by small teams. AI-scale discovery could send those maintainers more verified reports than they can resolve, so the value of deduplication and verification upstream is substantial if it works as described.

    Participation also raises questions that private operators will weigh carefully. The Department of War is a co-lead alongside civilian agencies, and Treasury’s statement focuses on the financial sector. Companies deciding how much to share will want clarity on how data is handled, who sees it, how long vendors get before details circulate more widely, and what legal protections apply. None of that undercuts the initiative’s aims, but the answers will shape how much of the private sector’s visibility Gold Eagle can actually draw on.

    Background

    Coordinated vulnerability disclosure is the long-standing practice of reporting a software flaw privately to the vendor, giving time for a fix, and then publishing details so users can protect themselves. In the United States, CISA, created in 2018 within the Department of Homeland Security, plays a central role: it supports the CVE system that assigns identifiers to known flaws and maintains the Known Exploited Vulnerabilities catalog, which flags weaknesses attackers are actively using.

    Critical infrastructure spans energy, finance, communications, water and other sectors, and increasingly includes the data centers that support cloud and AI services. Much of it runs on operational technology, the industrial control systems that manage physical equipment, which historically lags office IT in patching because uptime and safety come first. Gold Eagle is the administration’s attempt to apply AI to the discovery and triage end of that process at national scale.

    Sources

    Source: US launches Gold Eagle initiative to boost cybersecurity vulnerability coordination, bolster critical infrastructure defense (Industrial Cyber): the White House’s launch of an AI-driven vulnerability clearinghouse under Executive Order 14409.

  • CISA Built Its Incident Playbook Mid-Incident: A Test of National Cyber Readiness

    CISA Built Its Incident Playbook Mid-Incident: A Test of National Cyber Readiness

    The US Cybersecurity and Infrastructure Security Agency (CISA) had to build its incident-response playbook while an incident was already underway, the agency revealed, according to a TechCrunch report published July 11, 2026. The report indicates that the government’s lead civilian cyber-defense agency entered at least one real-world event without a finished, ready-to-run plan for handling it.

    The available source material does not identify the incident in question, when it occurred, or what the playbook now contains — details that matter considerably for judging how serious the admission is.

    Executive Summary

    An incident-response playbook is the documented, step-by-step procedure an organization follows when it is under attack: who is in charge, who gets called, what gets isolated, what gets communicated, and in what order. The entire value of a playbook is that it exists before the crisis, so responders execute rather than improvise. According to the TechCrunch report, CISA has acknowledged that in at least one incident, that document was being written while the response was in motion.

    The admission matters because CISA is not an ordinary organization. It is the agency charged with coordinating the defense of US federal civilian networks and supporting the private operators of critical infrastructure — power, water, telecommunications, and the data centers that underpin the digital economy. When the coordinating agency is improvising its own procedures mid-crisis, every organization that plans to lean on federal support during a major incident has reason to re-examine that assumption.

    At the same time, the disclosure should be read with proportion. Candid admissions of this kind usually surface through after-action reviews — a sign the retrospection process is working — and improvised response is a failure mode that afflicts well-resourced private companies too. With only a single, thin source available, the honest position is that the admission is notable, the surrounding detail is missing, and the questions it raises are more valuable than any verdict.

    When the Plan Is Written During the Fire

    Incident response rests on a simple premise: decisions made under pressure are worse than decisions made in advance. A playbook front-loads the hard choices — escalation thresholds, containment authority, communication trees, legal notification duties — so that during an actual intrusion, responders follow a tested script instead of negotiating roles at 3 a.m. Building that script mid-incident inverts the model. It means the response absorbed effort that should have gone to containment, and it means early decisions were made without the benefit of pre-agreed procedure.

    For CISA specifically, the irony is sharp. The agency is the federal government’s principal author of incident-response guidance for others: it published formal incident and vulnerability response playbooks for federal civilian agencies in 2021, following Executive Order 14028, and it routinely urges private organizations to maintain and exercise their own plans. The available reporting does not say how the newly admitted gap relates to those published playbooks — whether the incident fell outside their scope, whether internal procedures lagged the public guidance, or something else. That distinction is central to how much weight the admission should carry, and it is currently unanswered.

    Paper Readiness vs. Operational Readiness

    The episode illustrates a distinction every security leader knows: having a document is not the same as being ready. Plans that are written for auditors and never exercised routinely collapse on first contact with a real adversary — contact lists go stale, assumed tooling is unavailable, and the people named in the escalation chain have changed jobs. The security industry’s standard corrective is the tabletop exercise: a rehearsal that stress-tests the plan before an attacker does. If CISA’s playbook had to be authored during an incident, the implication is that for that class of event, neither the document nor the rehearsal existed in usable form.

    It is worth being even-handed here. Organizations that conduct genuine after-action reviews are precisely the ones that surface uncomfortable findings like this, while organizations that never look find nothing. An agency admitting the gap — if that is what occurred — is behaving more transparently than one quietly papering over it. The fair question is not whether CISA once lacked a playbook, but whether the gap has since been closed, exercised, and independently validated. The source material does not say.

    What It Means for Critical Infrastructure and Enterprise Operators

    Data-center operators, network providers, and other critical-infrastructure firms sit in a shared-responsibility arrangement with CISA: the agency provides threat advisories, coordination, and in some cases direct assistance during major incidents. This disclosure is a reminder that federal support is a supplement to, not a substitute for, an operator’s own readiness. Enterprises that have penciled ‘call CISA’ into their crisis plans should treat that line as one resource among several — and should verify that their own playbooks are current, exercised, and executable without outside help.

    There is also a resourcing dimension that the admission invites, without settling. Sustained readiness — maintained playbooks, regular exercises, retained senior responders — is a function of budget and staffing continuity. The reporting available here does not address CISA’s resourcing, and it would be speculation to attribute the gap to any particular cause. But it is a legitimate line of oversight inquiry: preparedness is perishable, and it decays quietly until an incident makes the decay visible.

    Background

    CISA was established by Congress in November 2018 as the Department of Homeland Security’s operational lead for civilian cybersecurity. Its remit spans defending federal civilian (‘.gov’) networks, publishing threat advisories and its Known Exploited Vulnerabilities catalog, and partnering with the private operators who run most US critical infrastructure. After the 2020 SolarWinds supply-chain compromise exposed coordination weaknesses, Executive Order 14028 directed a series of federal cyber reforms, including standardized incident-response playbooks that CISA published in 2021.

    That history frames the current disclosure: the agency positioned as the government’s playbook author has acknowledged, per the reporting, entering at least one real incident without a finished playbook of its own — a reminder that in cybersecurity, documented preparedness and operational readiness are not the same thing.

    Source: US cybersecurity agency CISA had to build its incident playbook during the incident, agency reveals — TechCrunch report, July 11, 2026, on CISA’s disclosure that its incident-response playbook was authored mid-incident.

  • FortiBleed Credential Leak Puts Maritime and Energy Infrastructure on Alert

    FortiBleed Credential Leak Puts Maritime and Energy Infrastructure on Alert

    Maritime cybersecurity firm Cydome has warned that a credential leak dubbed “FortiBleed” poses elevated risks to maritime and energy critical infrastructure, according to a July 6, 2026 report in trade publication Industrial Cyber. The name follows the convention of earlier incidents involving Fortinet-family network security appliances, which are widely deployed as VPN gateways and firewalls at the network edge of ships, ports, and utilities.

    Executive Summary

    The core claim is straightforward: a set of leaked credentials associated with perimeter security devices is circulating, and Cydome assesses that maritime operators and energy providers are among the sectors most exposed. Leaked credentials for firewalls and VPN concentrators are especially dangerous because those devices sit at the boundary between the public internet and internal networks — a valid login can hand an attacker the same doorway that remote employees and vendors use, with no exploit required.

    The available reporting is thin on specifics. It does not enumerate how many credentials leaked, how they were obtained, which product lines or firmware versions are implicated, or whether the vendor has confirmed the incident. What makes the warning worth attention anyway is the sector focus: maritime and energy operators run operational technology (OT) — the systems that move cargo, steer vessels, and keep power flowing — behind exactly the class of edge devices a credential leak of this kind would unlock. For critical infrastructure, credential hygiene at the network perimeter is not an IT housekeeping item; it is a safety and continuity issue.

    Why Leaked Edge-Device Credentials Are a Skeleton Key

    Firewalls and VPN gateways are the locks on the front door of a network, and a credential leak turns the lock with its own key. Unlike a software vulnerability, which a patch can close, a leaked username and password remains valid until someone rotates it — and organizations are historically slow to rotate credentials on infrastructure devices, because doing so risks disrupting the remote access that operations depend on. Prior leaks of VPN credentials in the security-appliance market showed a long tail: credentials harvested years earlier kept working because operators patched the software flaw but never reset the passwords exposed through it.

    That dynamic is why credential leaks consistently outlast the news cycle that announces them. An attacker with a valid VPN login does not need to “hack” anything in the conventional sense; they authenticate, and from the network’s point of view they look like a legitimate remote user. Detection then depends on behavioral monitoring most industrial operators do not yet have.

    Maritime and Energy: Where IT Exposure Becomes Physical Risk

    Cydome’s sector framing matters because maritime and energy networks increasingly blend information technology with operational technology. A modern vessel is a floating industrial network — navigation, engine management, ballast, and cargo systems — reachable through satellite links that are commonly fronted by exactly the kind of compact security appliance implicated by the FortiBleed name. Ports and terminals mirror that architecture ashore, and energy utilities use similar edge devices to connect substations and remote facilities to control centers.

    In these environments, a compromised perimeter is not just a data-breach risk. Access to OT networks can translate into disrupted cargo operations, degraded situational awareness at sea, or interference with grid-connected equipment. Regulators have been moving in this direction — maritime authorities and energy-sector rules increasingly treat cyber risk as an operational safety matter — and a credential leak affecting perimeter devices is a concrete test of whether those frameworks change behavior in practice.

    Supply-Chain Credential Hygiene Is Grid Security

    The deeper issue FortiBleed illustrates is that critical infrastructure inherits the credential hygiene of its entire supply chain. Ship managers, port terminals, and utilities rely on integrators, equipment vendors, and managed service providers who hold remote-access credentials into operational networks. Every one of those relationships is a place where a credential can leak, be reused across customers, or sit unrotated for years. A leak attached to a single widely deployed product line therefore propagates across thousands of unrelated organizations at once.

    The practical countermeasures are unglamorous and well established: multi-factor authentication on every remote-access path, credential rotation tied to patch events, per-vendor accounts rather than shared logins, and monitoring for logins from unexpected locations. The persistent gap between that checklist and field reality — especially on vessels and remote energy sites with limited IT staff — is the actual risk surface this warning describes.

    Reading a Vendor Warning With Appropriate Care

    It is worth being clear-eyed about the source. Cydome sells maritime cybersecurity services, so it has a commercial interest in maritime operators taking this threat seriously — which does not make the warning wrong, but does mean the burden of specifics matters. The available report, as surfaced through aggregation, provides the assessment but not the underlying evidence: no credential counts, no confirmed victim organizations, no vendor confirmation, and no indication of observed exploitation against maritime or energy targets.

    The prudent posture for operators is to treat the warning as a prompt for verification rather than a verdict: check whether your perimeter devices are on current firmware, whether credentials have been rotated since the last relevant advisory, and whether MFA actually covers every remote-access path — steps that are worthwhile whether or not this particular leak ultimately proves as severe as its framing suggests.

    Background

    Perimeter security appliances — firewalls and VPN gateways from a handful of major vendors — have become one of the most attacked categories in enterprise infrastructure, precisely because they are internet-facing by design and guard the way in. The market has seen repeated cycles in which appliance vulnerabilities led to harvested credentials that circulated in criminal forums long after the underlying flaws were patched, and government cyber agencies have repeatedly urged operators to rotate credentials, not just update firmware, after such incidents.

    Maritime and energy have meanwhile become focal sectors for industrial cybersecurity as ships, ports, and grids digitized faster than their security practices matured. Specialist firms such as Cydome emerged to serve the maritime niche, and trade outlets like Industrial Cyber track the intersection of these leaks with critical infrastructure — the context in which the FortiBleed warning landed in July 2026.

    Source: Cydome reports FortiBleed credential leak poses elevated risks to maritime and energy critical infrastructure — Industrial Cyber’s July 6, 2026 report on a maritime cybersecurity vendor’s warning about leaked network-appliance credentials.

  • Iran-Linked Cyberattack Forces UK Power Plant Offline: A Wake-Up Call for OT Security

    Iran-Linked Cyberattack Forces UK Power Plant Offline: A Wake-Up Call for OT Security

    A small power plant in the United Kingdom was taken offline following a cyberattack that has been linked to Iran, according to a report by The Telegraph carried by CNBC on July 6, 2026. The facility’s name, capacity, and the duration of the shutdown were not disclosed in the report.

    If confirmed, the incident would join a very short list of cyberattacks anywhere in the world that have resulted in the loss of physical power-generation capacity — a category of event that grid operators and security agencies have long warned about but rarely seen materialize.

    Executive Summary

    According to the reporting, hackers attributed to Iran compromised systems associated with a small UK generating facility, and the plant was subsequently shut down. That one sentence contains nearly everything that is publicly known — and that brevity is itself significant. Neither the operator, the attack method, nor the official basis for the Iran attribution has been made public in the source material.

    Why it matters: the vast majority of cyberattacks on energy companies hit their corporate IT — email, billing, customer data. What makes this report notable is the claimed crossing into the physical domain, where an intrusion ends with turbines stopping rather than data leaking. Confirmed cyber-physical grid incidents are so rare that the canonical examples remain the 2015 and 2016 attacks on Ukraine’s grid. A confirmed case in the UK, a G7 economy with mature critical-infrastructure regulation, would mark a meaningful escalation in what operators must plan for.

    For the infrastructure industry — utilities, data center operators, and anyone whose business depends on reliable power — the practical takeaway does not depend on the attribution being right. The incident, as described, is a live test of assumptions about how well operational technology is separated from the internet-facing systems attackers can reach.

    From Stolen Data to Stopped Turbines

    Security professionals draw a sharp line between IT (information technology — the email servers, databases, and laptops every company runs) and OT (operational technology — the industrial control systems that open valves, spin generators, and switch breakers). Attacks on energy-sector IT are routine; attacks that reach OT and cause physical consequences are exceptionally rare, because control systems are typically segmented from corporate networks and because causing physical effects requires specialized knowledge of industrial equipment.

    The report does not say whether the attackers actually manipulated control systems, or whether the operator shut the plant down as a precaution after detecting an intrusion elsewhere. That distinction matters enormously. A precautionary shutdown means defenses worked as designed — disruptive, but contained. Direct manipulation of control systems would put the incident in the same category as Ukraine 2015, where attackers remotely opened breakers and blacked out roughly a quarter-million customers. Until the mechanism is disclosed, both readings remain open, and honest analysis has to hold them both.

    Attribution Is a Claim, Not Yet a Conviction

    The Iran link originates with The Telegraph’s reporting rather than, so far as the source material shows, a formal government attribution. Cyber attribution is genuinely hard: attackers reuse each other’s tools, route through third countries, and sometimes deliberately imitate rival groups. Western agencies have previously documented Iranian-linked activity against industrial control systems — including the 2023 compromises of Unitronics controllers at US water utilities — so the claim is plausible. Plausible, however, is not proven, and the geopolitical stakes of naming a state actor make the evidentiary bar higher, not lower.

    Fair questions cut in every direction here. What forensic indicators support the Iran link, and will the UK’s National Cyber Security Centre confirm it? Equally, if the attribution is later walked back, was the initial linkage sourced from officials, from the operator, or from third-party researchers? Early attribution reporting on infrastructure incidents has a mixed track record — the 2019 claims around a US grid ‘attack’ that turned out to be a firewall flaw are a cautionary example — which is reason for patience, not dismissal.

    Why Small Plants Are the Soft Underbelly

    It is no accident that the target described is a small power plant. Large transmission operators and major generators sit under heavy regulatory scrutiny and can amortize security operations centers across billions in revenue. Small generators — peaking plants, biomass and waste-to-energy sites, independent operators — run thin staffs, often rely on remote-access links for vendor maintenance, and operate control equipment that predates modern security design. They are individually low-value targets but collectively numerous, and in an increasingly decentralized grid their aggregate capacity matters.

    The economics are unforgiving: a security program that is table stakes for a gigawatt-scale utility can be a material fraction of a small plant’s operating budget. That gap is precisely where regulation, insurance requirements, and shared-service security models will be contested in the years ahead. An incident like this one strengthens the argument that minimum OT-security standards need to reach the long tail of generation, not just the giants.

    What Operators — Including Data Centers — Should Take From This

    For data center and cloud operators, this story is about the other side of the meter. Facilities that promise 99.999% availability model grid failure as a weather or equipment problem; a world where generation can be taken offline by remote adversaries changes the risk calculus for utility redundancy, on-site generation, and fuel reserves. It also lands amid record data-center-driven load growth, which is already straining grid planning in the UK and elsewhere.

    For anyone running OT: the defensive playbook this incident points to is well established, if unevenly applied — rigorous segmentation between IT and OT networks, multi-factor authentication on every remote-access path, monitoring inside the control network rather than only at its edge, and rehearsed manual-operation procedures so a plant can run or shut down safely when its digital systems cannot be trusted. None of that is exotic. The persistent gap is investment and follow-through, and events like this are what close it.

    Background

    Power plants and grid operators have digitized steadily over three decades, layering remote monitoring and control onto industrial equipment that was designed long before modern cyber threats. Security agencies have warned since at least the Stuxnet operation of 2010 — which physically damaged Iranian centrifuges via malicious code — that industrial control systems can be weaponized, but confirmed grid consequences have remained rare: the 2015 and 2016 Ukraine blackouts are the textbook cases.

    The UK regulates its critical energy infrastructure under the NIS Regulations of 2018, with the National Cyber Security Centre as technical authority, and both UK and US agencies have repeatedly warned of Iranian-linked interest in Western critical infrastructure amid broader geopolitical tensions. A confirmed cyber-induced plant shutdown on British soil would be the first incident of its kind publicly acknowledged in the country.

    Source: Small UK power plant shut down after cyberattack linked to Iran: Telegraph — CNBC’s July 6, 2026 report of The Telegraph’s account of an Iran-linked cyberattack that forced a small UK power plant offline.