AI adoption in OT security accelerates as legacy infrastructure and poor data expose readiness gaps


Industrial organizations are racing to adopt AI for operational security faster than their systems can support it. Takepoint Research’s latest survey shows 87.7% are already using or planning AI for OT cybersecurity, yet only 7.9% have deployed it across multiple functions. The gap isn’t reluctance—it’s architectural. Major obstacles cited by survey respondents are data quality and integration of legacy systems, representing 45.4% and 42.4%, respectively.

Most industrial facilities were built long before anyone imagined running AI on top of them and the control systems underneath haven’t caught up. Not a single industrial plant was designed with AI computing in mind, while their control systems produce scattered and inconsistent telemetry. Without fixing that foundation first, organizations are essentially piling cutting-edge tools on top of decades-old infrastructure debt.

Physical consequence risks compound the problem. Almost two-thirds of participants recognize that corrupt decisions made by AI could result in damage to equipment, unintended shutdowns, or even safety incidents, but just 15.6% of companies have adopted OT-specific AI governance policies. Readiness levels vary immensely depending on industry, with those having more data-friendly and advanced infrastructure progressing much quicker than others stuck in brownfield operations.

The real question isn’t whether AI belongs in OT security. It’s whether industrial environments are willing to shore up their architectural foundations first, or whether they’ll deploy AI systems destined to operate unreliably in environments never built to support them.

OT security faces AI infrastructure gaps

Luis Luque, global cyber-physical security lead at AccentureLuis Luque, global cyber-physical security lead at Accenture
Luis Luque, global cyber-physical security lead at Accenture

Industrial Cyber reached out to experts to assess what infrastructure limitations most often prevent industrial organizations from deploying AI effectively in OT security environments

Luis Luque, global cyber-physical security lead at Accenture, told Industrial Cyber that these issues vary by industry and by geography, but some examples are data sovereignty issues related to AI technology access or even the preference at a company or government level to provision AI technologies from certain sources. 

He added that in terms of limitations, legacy OT environments often have immature identity and access management infrastructure needed to properly manage human, agentic and machine-related identities, combined with limited security tooling related to managing AI model-specific challenges like prompt injection risks.

Moreno Carullo, co-founder and chief technology officer at Nozomi NetworksMoreno Carullo, co-founder and chief technology officer at Nozomi Networks
Moreno Carullo, co-founder and chief technology officer at Nozomi Networks

“The most significant infrastructure limitation we see is the lack of cloud connectivity for OT security systems,” Moreno Carullo, co-founder and chief technology officer at Nozomi Networks, told Industrial Cyber. “While local, on-premises LLMs have gained traction for certain development and research use cases, they simply don’t match the capability or scalability of the latest models running in the cloud. This creates a real tension for industrial organizations, as the AI that would deliver the most value is cloud-based, but many OT environments aren’t architected to connect to the cloud in the first place.”

He added that it’s worth noting that this isn’t always a pure infrastructure problem. In many cases, the barrier is regulatory. Compliance requirements or industry-specific mandates prohibit OT systems from establishing cloud connections.

“From my perspective, one of the biggest limitations is not necessarily the age of the infrastructure, but whether the data needed by the AI system is available, structured, and provided with sufficient context,” Marissa Morales Rodriguez, founder and technology security strategist at STEMPRISE, detailed to Industrial Cyber. “In OT environments, we have long dealt with questions around what data needs to be collected, at what frequency and resolution, and in what quantity and quality to support analytics and traditional machine-learning applications. Those requirements depend heavily on the use case.”

Marissa Morales Rodriguez, founder and technology security strategist at STEMPRISEMarissa Morales Rodriguez, founder and technology security strategist at STEMPRISE
Marissa Morales Rodriguez, founder and technology security strategist at STEMPRISE

She added that generative and agentic AI introduce a somewhat different consideration. These systems may be able to work with data already available within the industrial environment, but that data still needs to be accessible and presented with enough structure and operational context for the AI system to interpret and use it appropriately.

For example, Morales Rodriguez mentioned that an AI system performing network anomaly detection may primarily require network telemetry and asset context, while an AI system attempting to determine whether a cyber event is affecting the physical process may also require time-series process data, equipment relationships, and operational context. 

Roman Arutyunov, chief product officer at Xage SecurityRoman Arutyunov, chief product officer at Xage Security
Roman Arutyunov, chief product officer at Xage Security

Roman Arutyunov, chief product officer at Xage Security, said that one of the biggest limitations is the lack of a consistent security and identity layer across heterogeneous OT environments. “Many industrial organizations operate decades of technology from different vendors, generations, and protocols, and legacy assets often lack modern telemetry and identity controls.”

Arutyunov added that AI also requires identity-based controls to determine what users, devices, workloads, and agents can access and do. “Organizations should not have to replace functioning equipment to adopt AI. A modern security architecture can provide consistent identity, access, segmentation, and policy enforcement across legacy and modern assets, creating a stronger foundation for AI-enabled security.”

Paul Griswold, independent consultant, cybersecurity fractional CPO and advisorPaul Griswold, independent consultant, cybersecurity fractional CPO and advisor
Paul Griswold, independent consultant, cybersecurity fractional CPO and advisor

“Most OT environments were architected for control and reliability, not for the data throughput AI requires,” Paul Griswold, independent consultant, cybersecurity fractional CPO and advisor, told Industrial Cyber. “Many industrial networks still run on limited bandwidth, and there’s often no edge compute infrastructure to process data locally before it needs to traverse constrained links to the cloud or a central data lake.” 

He mentioned, “Add in air-gapped or segmented networks (by design, for good security reasons), and you get environments where the data AI needs simply can’t move fast enough or far enough. Until organizations invest in edge processing and re-architect data flows with AI in mind, they’re deploying AI on top of infrastructure that was never meant to feed it.”

Poor OT data undermines AI security

The executives examine how poor data quality, inconsistent telemetry and incomplete asset context affect the accuracy and trustworthiness of AI-enabled OT security tools.

“Incomplete asset context can be the biggest risk for AI-enabled security tooling if it is used for recommending actions or automating some actions,” Luque said. “Context is the most important aspect to get right in OT environments because the same piece of equipment can be used for very different purposes and can carry very different consequences.” 

Moreno evaluates that AI technology is powerful, but it cannot compensate for poor-quality data. “When telemetry is missing or asset context is incomplete, AI-enabled tools are left to fill in the gaps. And when they do, AI often produces hallucinations, guesswork, or assumptions of the most likely option. That behavior directly undermines the accuracy and trustworthiness security teams depend on.”

He added that the solution is better-architected data collection paired with honest reporting. A well-deployed AI-enabled OT security tool should be designed to gather the most complete asset context possible from multiple sources. Just as importantly, it should be transparent when the data it has isn’t good enough to support a confident conclusion. 

Morales Rodriguez said that “we first need to distinguish accuracy from trustworthiness. Accuracy can be viewed as whether the AI-enabled tool produces results that correctly characterize the condition or behavior it is evaluating. Trustworthiness can be broader: whether we have sufficient confidence in the data, context, methodology, and resulting output to use that information for its intended purpose.”

“Poor data quality, inconsistent telemetry, and incomplete asset context affect both,” she added. “Missing or poor-quality data can create an incomplete picture of system behavior, while insufficient asset and operational context can limit the AI system’s ability to understand what those observations actually mean. The significance of those limitations also depends on the AI use case and the decision the tool is intended to support.”

She pointed out that this is particularly important in OT security because identifying an anomaly is not necessarily the same as understanding its cause or operational significance. “A sensor can report an unexpected value because it is failing, drifting, misconfigured, experiencing a communications problem or because an adversary manipulated the information.”

“AI is only as good as the data and context it receives. In OT, poor data quality can have real-world consequences because security decisions may affect physical processes, continuity, and safety. Identity and authorization context are critical to distinguish benign anomalies from unauthorized activity,” Arutyunov told Industrial Cyber. “Security teams need to know who or what initiated an action, what resource was accessed, whether it was authorized, and what policy applied. Without that context, AI can generate false positives, miss threats, or recommend actions based on an incomplete view of the environment.”

Gridwold noted that AI is only as good as the data it’s trained on and operates on, and OT environments are notorious for messy, incomplete data that the ICS vendor often alone fully understands. 

“If your asset inventory is stale, your telemetry has gaps, or sensor data is inconsistent across sites, the AI won’t have the context to distinguish a real anomaly from noise,” he added. “This leads to false positives that erode operator trust, or worse, false negatives that miss a real threat. Before organizations trust AI-driven decisions, they need to invest in the unglamorous work of asset discovery, data normalization, and telemetry consistency. These are the foundational elements that determine whether AI is an asset or a liability.”

Legacy OT architecture challenges AI

The executives look at what architectural weaknesses tend to become visible when organizations try to apply AI in brownfield industrial environments.

“We tend to see architectural weaknesses related to securely managing AI models and agent usage in OT environments. We also see issues with securely architected cloud access into OT environments and limited identity maturity in these environments,” Luque said. “That said, these weaknesses do not stop vendors and internal project teams from testing and deploying a wide range of AI-based solutions or provisioning cloud-based AI enablement solutions into OT. It just means that these vendors or internal teams introduce these systems into production with much greater risk.”

Moreno observed that AI needs good data to deliver real value, and in brownfield environments, data-collection architecture is often where weaknesses surface first. Systems must support passive traffic collection, active device queries, and third-party integrations.

“Passive collection is the toughest: many brownfield sites lack managed switches for mirror/SPAN sessions, and even where possible, traffic still needs local sensors or centralized connectivity, adding architectural hurdles,” he added. “Active device connectivity is comparatively easier to solve. Integrations pose a different challenge: ensuring third-party sources are securely, reliably reachable, with accurate, current data. Fortunately, vendors largely solve this.”

“I would first be careful about calling all of them architectural weaknesses. Brownfield industrial environments contain multiple generations of technologies that were designed and implemented for different operational requirements,” Morales Rodriguez said. “Those systems may be performing their intended functions very well. The limitations can become visible when we introduce a new requirement, such as an AI application, that needs to access and integrate information across those systems.”

She explained that one of the first questions this raises is how well the organization actually understands its assets and architecture. “Do we know what assets we have, what they do, how they are connected, what information they generate, and where that information resides? AI integration can expose gaps in that knowledge that may not have been apparent when the individual systems were operating independently.”

“The second issue is data readiness,” Morales Rodriguez identified. “Industrial organizations can have enormous amounts of data, but having data is not the same as having data that is ready for an AI application. The relevant information may exist across control systems, historians, cybersecurity tools, maintenance systems, and engineering records, but it may not be structured, contextualized, or readily accessible for the intended AI use case.”

“AI initiatives often expose security weaknesses that already existed, including flat networks, shared accounts, excessive privileges, limited asset visibility, inconsistent authentication, weak segmentation, and security controls that vary from site to site,” Arutyunov said. “Brownfield environments make those gaps especially visible because organizations cannot assume every asset can run an agent, support modern authentication, or be patched on a conventional IT schedule.” 

He added that security controls need to be enforced independently of the underlying asset wherever possible. “A Zero Trust architecture can provide granular access controls and segmentation around legacy systems without requiring those systems themselves to support modern security capabilities.”

Brownfield environments expose three architectural weaknesses fast: connection speed, legacy network fragility, and poor data accessibility, Gridwold said. “Decades-old control systems weren’t built with modern connectivity or APIs in mind, so pulling data out often means bolting on middleware or risking the stability of systems that were never designed to be touched.” 

He added that legacy networks can also be fragile enough that simply querying them for telemetry introduces latency or availability risk to production. “As a result, AI initiatives in brownfield settings often stall not because the AI itself is immature, but because the underlying network and data architecture can’t yet safely support it.”

AI readiness varies across industrial sectors

The executives focus on which industrial sectors appear best positioned to use AI in OT security today, and which are likely to face the greatest implementation challenges. 

Luque said that “We typically see more AI adoption in OT security today across various forms of traditional manufacturing such as pharmaceuticals, consumer packaged goods and automotive while we are seeing less adoption in utilities and public sector OT environments.”

“Readiness for AI in OT security has to do with how that organization has owned its systems and architecture over time,” according to Nozomi’s Moreno. “Organizations that have maintained well-thought-out architecture built on open protocols and standards are more likely to succeed with AI adoption than those running more legacy setups controlled end-to-end by a single vendor, meaning that vendor has historically decided, deployed, and maintained the environment.”

He noted that this distinction shows up across nearly every vertical rather than breaking cleanly along sector lines. That said, the power systems and utilities sector tends to stand out as one where organizations more often own their systems directly, which may position that sector favorably for AI adoption compared to others.

“I would be cautious about categorizing entire industrial sectors as more or less ready for AI. AI readiness in OT is not necessarily a sector characteristic; it is a system and organizational maturity characteristic,” Morales Rodriguez said. “Organizations with well-understood architectures, sufficient digital information to provide system context, data that is accessible and ready for the intended AI application, and the ability to integrate new technologies in a controlled way are likely to be better positioned for AI adoption.” 

Conversely, she added that organizations that lack visibility into their assets and architecture, have fragmented or difficult-to-access data, or have limited integration capabilities may face greater implementation challenges. “Regulatory or compliance requirements may introduce additional design and governance constraints, but those requirements influence how AI is deployed rather than necessarily determining whether an organization is ready to adopt it.”

Arutyunov said that readiness often depends more on architecture and operational maturity than industry. “Organizations with strong asset interaction visibility, clear identities, granular access controls, segmentation, and centralized policy management have an advantage. Some of the most forward-leaning adopters are in industries typically seen as conservative. The biggest challenges arise in highly distributed environments with long asset lifecycles, many third parties, and a mix of legacy and modern technology.” 

He added that successful AI adoption depends more on the maturity of the underlying environment than the sector itself.

“Sectors where modern tech stacks are a competitive differentiator (like discrete manufacturing and semiconductor fabs) tend to have newer OT infrastructure, better connectivity, and cultures more accustomed to rapid technology adoption, which puts them ahead,” according to Gridwold. “Sectors running on older, highly capital-intensive infrastructure, such as pulp and paper, refining, and some utilities, face a tougher road, since their control systems can be decades old and replacing them isn’t a quick or cheap decision. Those industries will need AI approaches that work around legacy constraints rather than assuming a modernized foundation.” 

He mentioned that sector readiness ultimately tracks the age and flexibility of the underlying OT environment more than appetite for AI itself.

AI in OT needs stronger security foundations

The executives look into what foundational OT security capabilities need to be in place before AI can scale beyond limited pilots or isolated use cases. 

Luque observed that a modern network architecture with micro-segmentation where possible is needed to isolate zones based on risk and consequence. “The architecture and capabilities should account for traditional legacy OT systems but have flexibility to securely integrate or exchange data with cloud-based solutions where justified.  Cyber resilience is more important than ever, so having basic monitoring of infrastructure and identities where possible, combined with a robust immutable backup and recovery strategy, is essential.”

“It starts with asset inventory and visibility. AI can only reason about what it can see, so if the view of the environment is partial, the output will be confidently wrong,” Moreno said. “But three things need to accompany it.” 

First, coverage: ensure that the sites and the asset base that AI-generated guidance is based upon reflect the actual environment rather than a sample of it. Second, data quality and consistency: confirm that assets are identified the same way across sites, draft communication baselines that are truly representative, and develop telemetry without gaps. Third, process context: understand which assets matter to which process and what the consequence of disruption would be. That context is what allows AI to prioritize accurately.

Recognizing that there is a significant difference between AI that observes an environment, Morales Rodriguez explained that AI that provides recommendations to a security analyst or engineer, and AI that is authorized to take an action. “Even when a human remains in the loop, the AI may still be influencing decisions that have operational consequences. As that influence or authority increases, so should the level of validation, monitoring, accountability, and human oversight. The level of assurance should be proportional to the consequence of the decision or action the AI is allowed to influence.”

Before AI scales, she added that organizations need to understand not only where AI is deployed, but where it sits within the operational decision chain and how much confidence is required in its outputs.

“Organizations need strong identity, least-privilege access, segmentation, centralized policy enforcement, and reliable auditability,” Arutyunov highlighted. “They also need to securely extract and share data with AI without directly exposing OT assets or data sources. These same Zero Trust principles should apply to AI itself.” 

He identified that as agents gain access to data and take actions across critical environments, their identities, permissions, and access paths must be tightly controlled. AI should augment deterministic security controls, not replace them, especially as the impact of a compromised or overprivileged AI system grows.

Griswold said that before AI can scale, “organizations need accurate, continuously updated asset inventories, as you can’t secure or analyze what you can’t see. They also need network segmentation and visibility that lets telemetry flow safely and consistently to wherever the analysis happens, plus a baseline of ‘normal’ behavior established through mature monitoring, as AI-driven anomaly detection is only as sharp as the baseline it’s compared against.” 

Noting that governance matters too, Grisworld pointed to clear ownership between IT and OT teams for how AI-driven alerts get triaged and acted on, so a model’s output actually translates into a response. “Without these fundamentals, AI pilots stay pilots… impressive in isolation, but unable to generalize across a real production environment.”

Are industrial environments ready for AI?

Lastly, the executives examine whether vendors overstate the readiness of industrial environments for AI-driven security operations and what buyers should look for beyond those claims.

Luque said that AI-driven security operations can be leveraged at any maturity level, but expectations need to be calibrated, and caution should be used when considering any form of agentic or automated AI-driven responses. “If you can get basic cybersecurity telemetry out of an OT environment and into an AI-supported analysis and recommendation engine, then you should do it, but hold off on automating responses. There are some industries and geographies where the risks are escalating more aggressively, and in those sectors, companies are becoming more open to automating security responses, including in OT.”  

He added that it is important to have auditability and human-led responses in these sensitive environments. As companies continue to invest in modernizing OT networks and maturing OT security programs, there will be more opportunities to safely leverage AI.

“Vendors generally assume their solutions are properly deployed with access to all relevant data. It’s the vendor’s duty not to overstate capability, but equally the customer’s job to deploy it so it can thrive, not operate under unnecessary limits,” Moreno said. “Often, the gap between promised and realized capability comes down to budget, not readiness or honesty. The ideal deployment might call for more sensors or a different architecture, but a leaner, cheaper setup gets chosen instead—affecting what the AI can see and do.”

He added, “So buyers should look for, beneath the claims, not just proof of capability but genuine partnership: vendors and customers working together to find the right fit given real architectural, budget, and regulatory constraints.”

“I think this can happen, but I would distinguish between the maturity of an AI-enabled product and the readiness of the environment in which it will be deployed,” according to Morales Rodriguez. “A product can be AI-ready without the environment being ready for the product. The appropriate level of integration will depend on the maturity and readiness of the organization.”

Arutyunov said that there is a real risk that AI becomes a checkbox rather than a meaningful security capability. “Buyers should ask what data the AI relies on, what context informs its decisions, and how it performs when telemetry is incomplete. They should also distinguish between AI that recommends an action and architecture that can safely enforce one. Because AI can be manipulated or compromised, organizations must also protect OT assets from rogue behavior.” 

He noted that zero trust controls should proxy AI interactions, strongly authenticate and authorize identities, hide critical assets, and segment the environment to prevent lateral movement.

Griswold agreed that this is a very common occurrence, and it’s understandable given competitive pressure to lead with AI in every pitch. “Buyers should push past the demo and ask for demonstrable proof that a given AI use case delivers real business value, not just a technically impressive output.” 

“Just as important, they should confirm it can be implemented without triggering a massive infrastructure or technology upgrade — if the AI capability only works after a multi-year modernization project, that’s not a near-term solution; it’s a roadmap item disguised as a product feature,” he concluded. “The best litmus test is asking a vendor to show results in an environment that looks like yours, not theirs.”

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *