Zscalerのブログ
Zscalerの最新ブログ情報を受信
Settled on Fundamentals, Stuck on Funding: What We Heard at ManuSec USA 2026
The theme of this year's ManuSec USA in Chicago was "Solidifying OT Security Fundamentals While Building Next-Gen Cyber Resilience." Over two days, the manufacturing security leaders in the room largely agreed on what those fundamentals are: control remote access, know what's on the network, segment what matters, and rehearse an incident response plan with the plant. Nobody we spoke with needed to be sold on that list.
What they wanted to talk about was getting it done. Mostly that meant paying for it, and getting the plant to go along with it.
Zscaler was this year's official sponsor. Amit Aneja opened day one with a session on agentless OT segmentation and joined the closing panel on prevention versus resilience. The rest of our team spent the event in sessions, at the booth, in customer meetings and at dinners with the people who run plants and the leaders who manage them. After the ICS Cybersecurity Conference earlier this month, we wrote that OT security is strong on controls and light on decisions. ManuSec showed us where a lot of those decisions get stuck. It's usually the budget meeting or the plant floor, and rarely the firewall.
How do you get OT security funded?
Funding came up more than any technical topic, in sessions and in the hallway. The question was always some version of how to explain OT risk to a CEO, a board or a CFO so that they act on it. On day two, Satish Kumar of Parker Hannifin dedicated a whole session to it, walking through how his team built quantifiable risk metrics across complex OT environments and turned technical vulnerabilities into risk scores a board can use.
The CISOs we heard from had different frameworks, but their advice lined up. Pick off small wins instead of trying to fix everything at once. Rank plants by business risk, and be honest about where each one stands today.
For us, that points back to discovery, and to a narrower question than most security assessments start with: which assets would hurt most if they failed? A device list doesn't answer it. You need to understand the process loops those devices govern. Which PLCs, safety instrumented systems or engineering workstations sit in a loop where a failure halts the line, triggers a regulatory event or puts a worker in danger? And what does an hour of downtime on each one actually cost?
One CISO walked through a scenario in which an attacker takes control of a boiler. At that point the team is running an emergency response, and people's safety is on the line. Some processes carry that weight by default. Food and agriculture, water and healthcare are all designated critical infrastructure sectors, and an unauthorized change to a chemical-dosing controller or the temperature on a food processing line can quickly become a public health problem.
Idaho National Laboratory's Virginia Wright made a related case on day one with Cyber-Informed Engineering, whose first principle is consequence-focused design. You begin with the outcomes that would be unacceptable and work backward to the functions that can never fail. Boards respond to that framing because it describes a production line and the people working on it, which is what they're actually being asked to protect.
Do you actually know what's on your network?
Asset visibility was the problem we heard about most, at the booth and in sessions alike. Even in mature programs running several tools, roughly half the people we talked with couldn't say with confidence that they had a full picture of their network, let alone what each device was talking to. Some put it more bluntly. They don't know what's connected until an incident forces an audit, and they're a little nervous about what that audit will find.
One CISO had simple advice for smaller shops with no tooling budget: do it by hand. Walk the floor with your plant operators, because they know where every machine is. A session from Daimler Truck North America covered the same ground at a larger scale, building a baseline OT inventory from scratch with a mix of manual and automated discovery.
An inventory is only a starting point. It tells you what's there without changing what any of it can reach. When Eaton first got visibility across its plants, one early find was a game console plugged into the OT network. Most plants probably have something similar waiting to be found.
Why does the plant floor push back?
This was the biggest surprise of the event. We expected segmentation architecture and detection tooling to dominate, and instead CISOs spent far more time on their relationship with plant floor operators.
At the booth, a head of cybersecurity at one manufacturer described the pushback they got when they tried to add controls to legacy production lines. The objection wasn't to the technology. Operations was afraid a security change would break an aging process the plant's daily output depends on, and that fear is reasonable. Security teams that treat it as obstruction tend to lose the argument.
Speaker after speaker made the same point about incident response: it only works if the relationship already exists. If a plant operator meets the security team for the first time during an incident, nobody in the room knows that machine's tolerances or which line can safely be touched. A day-two panel raised the structural version of the problem by asking whether accountability for OT security comes with the authority to act. In many plants it doesn't. Security owns the risk, and operations owns the equipment.
The fixes people described were practical. Meet with plant staff regularly before you roll anything out, and use the time to learn how they work. Talk in their terms and get to know your counterparts in legal, operations and IT well before an incident. And at least four CISOs we spoke with offered the same tip on their own: bring donuts.
Is segmentation still a hard sell?
Opinions were split - some practitioners who had held back on microsegmentation were noticeably more open to it, and several are now making it a priority. We heard the opposite just as often, usually from teams who consider a firewall between IT and OT, plus VLANs inside OT, to be enough.
The disagreement is worth a closer look. An IT/OT firewall controls what crosses into the plant. It does nothing about a compromised engineering workstation sharing a VLAN with every PLC on the line. Many manufacturers we work with ran flat OT networks for years, and they point to the cost and complexity of traditional approaches as the reason so many segmentation projects stall before they start.
The vendor pitches that landed best with network teams were segmentation built on the infrastructure they already own, with no network redesign. That suggests most teams object to the disruption more than to segmentation itself. They'll move once it doesn't mean re-architecting a running plant, and once they can begin with the critical assets they've already identified.
Why is remote access still first on the list?
Whenever the conversation turned to where to start, remote access came up first or close to it. It's the most common way into a plant and the most achievable early win. The most useful version we heard was a question to ask about every contractor and third party: can they reach one specific host, or do they land on the network around it? Even teams that already own a dedicated remote access tool told us they weren't happy with it.
That matches what we see in our own OT workshops and what we heard at ICS. If the secure path is slower than the workaround, people use the workaround.
Patching makes the access path matter even more. One session argued that AI will find flaws in PLCs, firmware and engineering tools faster than ever, while a controller running production can't be patched or rebooted on anything like that schedule. Plants will build up a pile of known vulnerabilities they can't fix, and the access path (who can reach an asset, from where, and for how long) becomes the control doing most of the work. We've made a version of this argument before, and we agree. Virtual patching at the boundary helps, but limiting reachability holds up better as the CVE count grows, because you validate each path once instead of each vulnerability.
Where did AI land?
The reaction was mixed. "AI-driven everything" was all over the show floor, and it drew a crowd. Yet the practitioners we talked to were mostly pulling back from new tools and putting their effort into foundational maturity. One session made the case for AI agents on the shop floor with extra controls around them, and the room wasn't ready for it.
People take the threat seriously, and nobody we spoke with still treats AI moving from IT into OT as hypothetical. What they doubt is whether autonomous AI belongs on the plant floor today, and most believe strong fundamentals remain the best defense against it. That was the argument in Amit's session, that architecture beats AI-accelerated attacks, and it's what people wanted to talk about when they came by the booth afterward.
What should you do differently on Monday?
If you couldn't be in Chicago, here's where we'd start:
- Name your critical assets and price their downtime in revenue, regulatory exposure and safety. That gives you a priority list and the start of a funding case.
- Fix your highest-risk remote and third-party access path. Know whether each contractor reaches one host or the network around it.
- Start the inventory, even by hand. Walk the floor with the people who run it.
- Meet the plant team before you need them. Then confirm your incident response plan exists, has been tested in a tabletop, and that operators know their part. If any of that is missing, it's your first project.
- Cut internet exposure. If an asset doesn't need to be reachable from outside, take it off.
From there, segment outward from those critical assets one step at a time. Most of this can start without new tooling, and none of it puts safety or uptime at risk.
Back to the funding question
Each item on that list still has to clear the budget meeting, and boards want a number. In our on-demand webinar on OT risks in manufacturing, Umang Barman lays out a straightforward way to build it: how often an incident happens, multiplied by how long production stays down, multiplied by what an hour of downtime costs. He focuses on the expensive tail of that range rather than the average. Each of the three terms is a lever you can fund against, and each maps to part of how we approach OT security:
- Fewer incidents. Privileged Remote Access gives vendors and contractors a brokered, recorded path to a single asset, so the most common way into a plant no longer leads to the network.
- Shorter disruptions. Deception puts decoys where legitimate users have no reason to go, so an intruder raises an alarm early.
- Smaller blast radius. Zero Trust Branch puts each OT device in its own network of one without VLAN readdressing or complex ACLs, so one compromised device can't take down a line. Start with the critical assets you've already priced.
The same approach covers the devices plant teams carry. Zscaler Cellular connects shop-floor tablets to private applications without a VPN, which surprised more than one IT team we met at the booth.
Want to start with your most critical assets? Request an OT architecture workshop.
Want the full risk model? Watch the on-demand webinar on OT risks in manufacturing.
FAQs
Manufacturers broadly agree on the OT security fundamentals: remote access, asset inventory, segmentation and incident response. What holds them back is funding, plant-floor trust and legacy systems that can't be patched on IT timelines.
Start with your most critical assets and quantify what their downtime costs in revenue, regulatory exposure and safety. Prioritize plants by business risk and take small, demonstrable wins rather than funding everything at once.
It governs what crosses into OT, but not lateral movement inside it. A compromised device on a flat OT network or shared VLAN can still reach every controller around it, which is why segmentation should start at the most critical assets.
このブログは役に立ちましたか?
免責事項:このブログは、Zscalerが情報提供のみを目的として作成したものであり、「現状のまま」提供されています。記載された内容の正確性、完全性、信頼性については一切保証されません。Zscalerは、ブログ内の情報の誤りや欠如、またはその情報に基づいて行われるいかなる行為に関して一切の責任を負いません。また、ブログ内でリンクされているサードパーティーのWebサイトおよびリソースは、利便性のみを目的として提供されており、その内容や運用についても一切の責任を負いません。すべての内容は予告なく変更される場合があります。このブログにアクセスすることで、これらの条件に同意し、情報の確認および使用は自己責任で行うことを理解したものとみなされます。


