Getting a manufacturer's production network from full-scope visibility to a segmentation policy that holds up under an AI-driven attack without breaking the line is the problem worth solving. That is what will sort these platforms out.
Expert Interview with Shankar Somasundaram, CEO | Asimily
Accenture and ServiceNow have spent close to $12 billion on IIoT / OT security companies within a few months of each other. What are these buyers really acquiring, and why buy the data and the technology instead of building it?
They’re buying the data and the years it takes to be trusted with gathering it. Large platform companies already sell into IT, and expanding into OT is far easier if you acquire the technology and the data instead of assembling it yourself. That data is hard to build. You discover connected devices primarily through passive monitoring and through active safe scanning where the environment allows it, then classify them well enough to run real risk analysis on equipment nobody ever designed to be monitored the way a laptop or a server is. That has to happen without disturbing the process those devices control. If it goes wrong in a plant, a line halts, and that’s why the vendors who do this well took a decade to get there.
Accenture’s numbers have the OT cybersecurity software market at $27 billion today, rising to $60 billion early next decade. Two of the largest professional services and enterprise software companies in the world looked at that number and decided, within a few months of each other, that owning the visibility layer was worth billions. ServiceNow paid $7.75 billion for Armis, and Accenture took a majority stake in Dragos and bought runZero and NetRise outright, over $4 billion all in. Building any of it internally would have cost them years, and by the end of those years the customers would already belong to somebody else.
What should manufacturers expect while these acquisitions close and integrate?
Expect the companies you buy from to move slower than they did, and plan around that.
Roadmaps inherently get redirected toward whatever the acquirer is already good at. Make no mistake about it: until proven otherwise, that serves the acquirer’s strategy more than it serves any one plant’s security. The people who used to make the product calls end up further away from them, and manufacturers are in limbo, and certainly more at risk, during that stretch.
At renewal, a manufacturing business should want to know who signs off on product direction now, and what has actually shipped since the deal closed as opposed to what got announced alongside it. It’s also worth asking whether the support engineers who know your environment are still on your account, and who picks them up if they leave. Those answers tell you more than the press release did.
Of course, the rest of it doesn’t pause while that happens. Food and beverage manufacturers are already running AI models against plant data to improve throughput, and every one of those deployments widens the attack surface at the same moment it raises the value of what sits behind it. Attackers pay attention to integration windows. I would treat the next 18 months as a period where you own more of your own security outcome than usual.
Network segmentation has been in NIST guidance for two decades, and most of the manufacturers you work with already own the NAC and firewall infrastructure. Why has so little of it been put into practice?
Largely because owning the infrastructure and operating it are two separate projects, yet only one of them typically gets budgeted correctly, if at all. Segmentation has been in NIST guidance and OT best practice documents for a couple of decades and is almost always framed as a way to contain the damage once something is already inside. The manufacturers I talk with own the NAC and the firewalls to do it (often bought 10-15 years ago). Operationalizing any of it is the part that never happened. Segmentation sat alongside endpoint security and MFA as a compliance line item, something a plant could point at during an audit and move on from.
Writing policy by hand across a heterogeneous set of OT and IIoT devices takes years and will find a way to consume every person you have. You’ll also get someone writing a rule based on an assumption about what a device does and push the policy, and then you see a line goes down because the assumption was wrong. For many manufacturers, a costly event like that will make the project politically dead for a long while. Thus, teams did the parts that couldn’t break anything and left the rest alone.
Device and equipment ownership also compounds it. A CNC machine or an industrial controller gets touched by operations one week and IT the next, with nobody formally on the hook for its security. Those machines run ten to fifteen years, so the ambiguity just sits there and hardens into normal.
AI agents arriving on industrial networks carry a risk profile the existing segmentation posture was never built to contain. What does that look like on a plant floor?
Say you bought a PLC from a well-established industrial supplier. That supplier controlled its own audited supply chain and could be held accountable when something went wrong. The provenance was knowable, so to speak, and the behavior of the device was fixed.
But now that plant buys an AI agent to improve a production process. It might come from a startup with none of that discipline, running on a model built by a company with a handful of employees, and nobody fully controls where that model has been embedded along the way. You have put something into the production environment whose supply chain you cannot describe.
At first things might play out normally. The agent needs data, so it gets read access to the historian and the MES. To earn its keep, it needs to act on what it finds, so somebody issues it a service account with write permissions. It then lands on a network flatter than the diagram suggests (which describes nearly every plant I have walked). Because its behavior is non-deterministic, the usual approach of allowlisting what a device is expected to do applies far less cleanly to it than to a pump controller.
Understand that even one agent behaving unpredictably is enough to cause damage across a manufacturer’s network, which likely was never originally built to handle or contain agents. Cyber insurers have noticed and are pushing on segmentation now, the way they pushed on authentication and endpoint controls a few years ago. Segmentation is quickly going from a checkbox to a funded project on that basis.
A typical manufacturer you work with has more than 100,000 devices and two million active connections. How does a small plant security team get from that raw connection data to policies it can enforce without taking down a line?
You need to start by filtering by exploitability, because you can’t just hand a plant team two million connections and ask them to write policy. Which connections can an attacker actually use given the specific device sitting in a specific topology? Our research puts the share of connected device vulnerabilities that carry genuine exploit risk at roughly 1-2%. Mapping connections against ATT&CK instead of a generic severity score turns two million connections into a prioritized queue that a team of four can (realistically) work through in a quarter.
Policies should also come out of observed behavior, whereby the platform watches what each device actually talks to, on which ports and protocols, what is baseline for it and what falls outside that, then generates conflict-free policy from what it saw. A person reviews and approves that policy instead of authoring it from a blank page. That step alone can otherwise eat up a year.
Next, before anything hits production, simulate it against real observed traffic and show the team precisely which flows would be blocked. Security always needs to account for keeping lines active, and showing that makes it a lot easier for plant managers to keep signing off.
Then it has to be maintained; this is not a set-it-and-forget situation. Firmware constantly changes, and new connected equipment arrives from an acquisition or a line expansion, so a policy set that was right four months ago is wrong now if nothing is adapting it. The sequence is discovery, prioritization, policy generation, simulation, and ongoing management. You need the whole chain; you can’t skip any part of that.
Visibility for standard IT and conventional OT assets has improved a lot. Which devices are still the hard problem for manufacturers, and what does that mean for the platforms that just got bought?
Some examples I see a lot are equipment that doesn’t speak a standard protocol and machines running embedded controllers from a vendor that went out of business years ago. I also run across instances of test and calibration gear that connects for an hour a month and disappears again, and HVAC and power monitoring that ended up on the plant network because it was convenient at the time. These devices and equipment don’t work with agents, and generally don’t appear in standard vulnerability scans, which is also the reason they pass compliance on paper. But, as headlines continue to show, one device like that on a flat network is usually all an attacker needs to get inside.
As far as platforms, a richer inventory bolted into a bigger suite does not reduce risk on a network by itself. What I would put to any of them is whether the product carries you from discovery through prioritization, policy, simulation, and ongoing management, or whether it stops at telling you what you have and hands the hard work back.
Getting a manufacturer’s production network from full-scope visibility to a segmentation policy that holds up under an AI-driven attack without breaking the line is the problem worth solving. That is what will sort these platforms out, and it will happen over 5-10 years rather than within the next two.
Shankar Somasundaram is the CEO of Asimily, a proactive cyber defense platform. Previously, he worked on IoT analytics and security solutions at Symantec, where he helped lead the company’s enterprise IoT product management.
