7 AI Threats Utilities and Co-ops Are Not Ready For—And What to Do Before They Arrive

The electric utility industry is deploying AI faster than it is securing it. Vendors are embedding machine learning into ADMS platforms, outage management systems, and customer portals that utilities of all sizes are actively procuring.

For large investor-owned utilities, dedicated cybersecurity teams can evaluate what arrives. For rural electric cooperatives and smaller utilities, AI is arriving embedded in software updates — with no accompanying security playbook.

The cybersecurity frameworks protecting utility OT today were built for a different world: deterministic systems, air-gapped networks, and static configurations. AI breaks all three of those assumptions. Machine learning models are probabilistic.

They require data moving across security boundaries. They change with every training cycle. And they introduce attack surfaces that firewalls, network segmentation, and the Purdue Model were never designed to address.

Seven specific threats stand out as the most consequential and the least addressed across the industry. The scale disparity compounds the risk.

The average rural electric cooperative serves fewer than 25,000 meters with an IT department of one or two people. When an ADMS vendor delivers an AI-enhanced outage management platform to a mid-sized cooperative, there is often no dedicated security architect evaluating whether the model serving infrastructure is properly segmented from the OT network, and often no one asking whether the AI model was trained on validated data or whether the training pipeline is monitored for manipulation. The threat vectors do not check the size of your utility before they arrive.

#1: Data Poisoning

Every AI model is only as trustworthy as the data it was trained on. In utility environments, training data comes from SCADA historians, GIS databases, AMI meter events, and weather feeds. An adversary who tampers with any of those upstream sources — even subtly over weeks — corrupts the AI model itself.

A manipulated GIS dataset fed to an AI topology model produces incorrect network assessments. Operators see what appears to be a reliable AI recommendation for a switching sequence while the underlying model is producing systematically wrong outputs.

NIST’s 2025 adversarial ML taxonomy classifies and documents this attack vector in detail. The defense requires cryptographic data lineage from sensor to AI pipeline, cross-system validation checkpoints, and anomaly detection on the training pipeline itself — monitoring what goes into the model, not just what comes out.

#2: Model Inversion and Extraction

A trained AI model is not just software. It is an encoded representation of the data it learned from — grid topology, protection settings, critical asset locations, and operational patterns.

Under CIP-011, much of this qualifies as BES Cyber System Information. An adversary with query access to a utility’s AI model can use model inversion techniques to reconstruct training data or create a functionally equivalent copy offline, providing a detailed map of grid vulnerabilities without triggering any alerts.

AI models processing BES data must be treated as BCSI themselves. Model serving endpoints require rate limiting, query pattern monitoring, and access controls at least as rigorous as the underlying SCADA data they encode.

#3: Advesial Input Manipulation

Unlike data poisoning, which targets training data, adversarial inputs target the AI model during live inference. Carefully crafted sensor readings — often imperceptible to human operators — can cause an anomaly detection model to misclassify a genuine intrusion as normal behavior, masking lateral movement through OT networks while the AI security monitoring system reports all clear.

AI models should operate alongside traditional rule-based systems, not replace them. A compromised AI detection layer should not eliminate all detection capability. Adversarial robustness testing before production deployment is a prerequisite, not an optional step.

#4: Supply Chain Compromise

The dependency tree for a single AI inference service is extensive — machine learning frameworks, GPU compute libraries, container runtimes, dozens of Python packages. CIP-013-2 requires vendor risk assessments for supply chain security, but FERC’s FY2025 CIP audit findings specifically flagged that entities need to evaluate compliance risks from cloud services and third-party AI dependencies.

A compromised open-source ML library deployed on servers processing BES telemetry creates a direct pathway into OT environments. Pre-trained models from public repositories may carry embedded backdoors that activate only on specific input patterns.

CIP-003-9, the most recent update to NERC’s security management controls standard, has expanded baseline cybersecurity requirements to low-impact facilities for the first time — but says nothing about how those obligations apply to AI model artifacts, training data pipelines, or edge AI inference containers.

For production OT environments, this demands air-gapped dependency management: all AI libraries pre-packaged and vulnerability-scanned in a connected staging environment, then transferred to production on encrypted media. Software Bills of Materials for ML frameworks and cryptographically signed model artifacts are essential controls, not optional ones.

#5: Al-Enabled Reconnaissance

Adversaries are not only attacking utility AI systems — they are using their own AI against utilities. Publicly available outage data, social media posts, PUC filings, and customer outage portal displays can be analyzed at scale to map grid topology and identify vulnerable points.

A customer portal displaying feeder-level outage details, specific equipment identifiers, or exact fault locations is inadvertently publishing reconnaissance data. Information classification rules for every public-facing AI output need to be enforced at the data layer, not bolted onto the presentation layer.

Approximate outage areas, estimated customer counts, and restoration status are appropriate public disclosures. Equipment identifiers, exact fault locations, crew GPS coordinates, and feeder-level load data are not.

#6: LLM Prompt Injection

Utilities are deploying large language models as operator assistants — tools that can query operating procedures, summarize switching protocols, and navigate complex restoration scenarios. These are genuinely useful capabilities, but they introduce a threat with no precedent in traditional OT security.

Prompt injection — where a carefully crafted input causes the LLM to reveal sensitive procedures, bypass access controls, or generate dangerous operational recommendations — was formally added to NIST’s adversarial ML taxonomy in 2025.

LLM inference for grid operations must occur on private, CIP-aligned infrastructure. Public cloud LLM APIs are not acceptable for processing BES Cyber System Information.

All outputs must be grounded in verified utility documentation through retrieval-augmented generation, and input/output validation must catch injection attempts before recommendations reach the operator screen.

#7: Lateral Movement via AI Infrastructure

AI processing infrastructure — GPU clusters, model serving platforms, data pipelines, monitoring systems — sits between IT and OT by definition. Data flows in from OT. Recommendations flow back toward operations.

Improperly segmented AI infrastructure becomes a bridge that attackers can use to pivot from IT into OT, bypassing the security boundaries NERC CIP has mandated for decades.

CIP-015-1, approved by FERC Order 907 in June 2025, mandates Internal Network Security Monitoring inside Electronic Security Perimeters, with compliance deadlines beginning October 2028. Generic IT-focused INSM tools will not recognize AI-specific attack patterns — monitoring for anomalous model serving behavior, data exfiltration from inference endpoints, and lateral movement from AI servers to SCADA requires OT-specific capability designed for AI infrastructure zones.

What Utilities Should Do Now

All seven threats exploit the same gap: traditional OT cybersecurity was not designed for AI systems. Start with vendor accountability before procurement.

Require written answers to four questions before signing any contract for an AI-enhanced ADMS, OMS, or outage management platform: Where was the AI model trained and on whose data?

Can the vendor provide a Software Bill of Materials for all AI dependencies? How is the AI inference infrastructure segmented from the OT network — and the answer must describe a hardware-enforced boundary, not just a firewall rule?

What is the vendor’s incident notification procedure if a model component is found to be compromised? If a vendor cannot answer all four in writing before contract signing, that is a risk to document and escalate.

Once deployed, classify every AI system by whether it touches BES-adjacent operational data or customer-facing systems only, and apply controls proportionate to that classification. Require hardware-enforced one-way data flows between OT and AI processing environments.

Mandate that no AI system autonomously executes grid control actions — every recommendation affecting switching sequences, restoration priorities, or load management must go to a qualified operator for final approval. Apply existing CIP-003-9 malware controls to AI model artifacts — they are software and the obligation already covers them.

Deploy INSM specifically designed for AI infrastructure zones ahead of CIP-015-1 deadlines. At the industry level, ADMS and OMS vendors must architect AI security into cooperative-scale products rather than treating it as a customer responsibility.

NRECA should develop AI security guidance adapted to the operational reality of resource-constrained utilities. And the NERC CIP standards development process needs to explicitly address how AI fits within the compliance obligations of low-impact facilities — providing the specific guidance that CIP-003-9’s expansion requires but does not yet deliver.

Cooperatives and smaller utilities adopting AI-enhanced ADMS and OMS platforms today are making architecture decisions that will shape their security posture for a decade.

The 42 million Americans served by rural electric cooperatives deserve the same security considerations being applied to customers of large investor-owned utilities. The window to build security in from the start is open now. It will not stay open much longer.