Most security leaders already know their factory environments are at risk. Many have tried to address it with VLANs, network access control (NAC), or air-gapping. But these approaches were built for IT, and not for plant floors with thousands of legacy devices that don’t support agents or certificates. And when something changes inside the plant, teams must rewrite policies. Visibility into east-west OT traffic is often limited, and segmentation ends up as written policy more than enforced control. That was precisely the reality we faced at Eaton.Eaton was founded in 1911, sits on the S&P 500, and did about $24.9 billion in revenue in 2024, up more than 7% over the year before. We employ roughly 94,000 people and sell into more than 175 countries. Intelligent power management is our business now: the electrical gear behind data centers, utilities, aerospace, and the big gray boxes you see humming on the street.The security challenge we face is the physical footprint. We run 216 manufacturing facilities in dozens of countries, each with its own machines, its own network, and its own history of how things got wired. And our company is still growing into electrification, data centers, and AI demand, which means more of those sites, not fewer. The pain: broad zones, unmanageable devices, and machines nobody can power downFor years our OT network was flat. Everything was placed into one broad subnet, with machines able to reach each other because they happened to share a VLAN. My goal was to turn that one big network into something controllable and secure.The exposure I worried about most was east-west traffic. Inside a plant, machine-to-machine traffic is most common. It’s also exactly the path ransomware takes once it lands. Our aim was limiting the blast radius and getting down toward the single host. That way, one compromised device couldn’t take the floor down with it.Another consideration: standard network access control assumes you can install a supplicant on the endpoint. But in OT environments, that assumption falls apart. A lot of these devices are happier running Telnet. You can’t drop an 802.1X client on a controller and call it secured. I had a name for the workaround: the “NAC tax,” or the extra layer of complexity you take on just to get access control working. The NAC tax is the reason a lot of segmentation projects stall before they start.Then there’s the equipment nobody is allowed to power down. I always put both sides of it together: you hear “this is super critical, we can’t touch it,” and the other side of that same coin is that it’s running Windows XP and you can’t get hardware for it anymore. Both things are true at once, and a security plan that ignores either one dies on contact with the plant floor. Our approach: watch first, then enforceMy team didn’t start by writing rules. We started by looking. The mental model was sequential: see what exists, understand what it talks to, then decide what to allow. This drove our entire rollout. What made it workable across 216 sites was that the work compounds. The same device types show up everywhere, so a policy written at the first plant carries to the next. You build a body of work that lets you move faster as you go. We started last year and are at about 85 sites now, in various stages from monitoring to full enforcement.Underneath the technology was a human strategy. Segmenting a live production floor changes how it works, and anytime you move somebody’s cheese, you have to have a conversation. Our security group had built a reputation for protecting the business first, and that goodwill carried us through the harder conversations.Step 1: See everythingBecause the profiling is agentless, a device gets identified the moment it joins the network: what it is, who makes it, and more. We wired in our existing tools to go deeper.CrowdStrike was the big one: I integrated the environment against our CrowdStrike database, so a device shows up with its security score attached. If it falls below a certain health threshold, our policy can say this device isn’t healthy anymore and shouldn’t be allowed to talk. Dragos is next on our roadmap. It’s built specifically to understand OT devices and the threats against them, and once that integration lands, I expect to write a policy against a device’s Dragos risk score—trusting a machine not just for what it is, but what’s enabled on the device.The visibility caught real issues right away. Someone had plugged an Xbox into the OT network. I saw it in the asset list, blocked the MAC address in seconds, and never had to send anyone to the plant to hunt for a cable.Step 2: Watch the trafficOnce you know what exists, you look at what it does. The visualizer shows the flows of what a given HMI is talking to, what’s reaching out to the internet, what was allowed, and what was denied. Here is a real example: a new handheld scanner came onto a network and started communicating differently than the model it replaced. One flow showed up blocked. I could see it immediately, check the vendor documentation, confirm the new device legitimately needed that path, and open it instead of chasing a mystery outage.Step 3: Write policy on the device, not the IPRules are written against the profile of a device, not its IP address. When I want voice equipment to talk to certain systems, I write a policy that says a Polycom voice device gets that permission. If something else gets plugged into that jack that doesn’t match the profile, it can’t talk. It’s blocked. Sometimes that generates a support ticket, which I treat as a feature: it forces a direct conversation with site staff about putting only authorized devices on the network.Our rollout method was deliberately gradual. We started with an open-ish “gray list” to allow what clearly isn’t risky, blocked the ports that keep you up at night (SMB, Telnet, SSH, FTP), and let the rest run so we could learn. We watched what fell through to the catch-all, decided what deserved a formal policy, then flipped to enforcement and dropped the rest.Step 4: An incident-response plan you set in advanceWe built our ransomware response directly into the policies as a four-state control switch: red, orange, yellow, green. The point is to make the hard calls while writing policy and not in a room at 2 a.m. while an indicator of compromise (IOC) is spreading.Red cuts lateral movement and blocks traffic while continuing to collect telemetry on what’s trying to communicate.Orange opens just enough to remediate, letting endpoints reach CrowdStrike or a patching server.Yellow brings critical business processes back online.Green is a normal run state.Every policy carries a checkbox for which mode it lives in, so the whole plant can change posture with a single control.Step 5: Get vendors in without flying them inWe branded our remote access service internally as Eaton Rapid Remote Access, or “ERAS.” It’s clientless, time-boxed, and running at over 100 sites now. A vendor enters through a ticket, gets approved, and lands on a bastion host adjacent to the OT network with nothing to install. Access can be scheduled ahead and capped at 72 hours.Early on, a vendor in Germany was facing a $9,000 flight and days of downtime to fix a plant; they did it remotely in a couple of hours instead. Across the year, ERAS has been used about 450 times, saving us north of $500,000 in travel alone.ERAS has also changed how we absorb acquisitions: drop the box in, and there’s a secure Eaton beachhead at the new facility on day one so the business can move faster. Conclusion: use a simple playbookOur playbook isn’t exotic. What made it work was sequencing and trust as much as technology. If you run a plant, a warehouse, a distribution center, or any OT environments, the honest first question isn’t which product to buy. It’s whether you can see what’s actually on your network right now. If you can’t answer that, start there. Ready to learn more?Watch the on-demand webinar: How Eaton Secured Its Manufacturing Facilities with ZscalerLearn about Eaton’s journey: Eaton Secures Global Operations with AI-Powered Segmentation
[#item_full_content] Most security leaders already know their factory environments are at risk. Many have tried to address it with VLANs, network access control (NAC), or air-gapping. But these approaches were built for IT, and not for plant floors with thousands of legacy devices that don’t support agents or certificates. And when something changes inside the plant, teams must rewrite policies. Visibility into east-west OT traffic is often limited, and segmentation ends up as written policy more than enforced control. That was precisely the reality we faced at Eaton.Eaton was founded in 1911, sits on the S&P 500, and did about $24.9 billion in revenue in 2024, up more than 7% over the year before. We employ roughly 94,000 people and sell into more than 175 countries. Intelligent power management is our business now: the electrical gear behind data centers, utilities, aerospace, and the big gray boxes you see humming on the street.The security challenge we face is the physical footprint. We run 216 manufacturing facilities in dozens of countries, each with its own machines, its own network, and its own history of how things got wired. And our company is still growing into electrification, data centers, and AI demand, which means more of those sites, not fewer. The pain: broad zones, unmanageable devices, and machines nobody can power downFor years our OT network was flat. Everything was placed into one broad subnet, with machines able to reach each other because they happened to share a VLAN. My goal was to turn that one big network into something controllable and secure.The exposure I worried about most was east-west traffic. Inside a plant, machine-to-machine traffic is most common. It’s also exactly the path ransomware takes once it lands. Our aim was limiting the blast radius and getting down toward the single host. That way, one compromised device couldn’t take the floor down with it.Another consideration: standard network access control assumes you can install a supplicant on the endpoint. But in OT environments, that assumption falls apart. A lot of these devices are happier running Telnet. You can’t drop an 802.1X client on a controller and call it secured. I had a name for the workaround: the “NAC tax,” or the extra layer of complexity you take on just to get access control working. The NAC tax is the reason a lot of segmentation projects stall before they start.Then there’s the equipment nobody is allowed to power down. I always put both sides of it together: you hear “this is super critical, we can’t touch it,” and the other side of that same coin is that it’s running Windows XP and you can’t get hardware for it anymore. Both things are true at once, and a security plan that ignores either one dies on contact with the plant floor. Our approach: watch first, then enforceMy team didn’t start by writing rules. We started by looking. The mental model was sequential: see what exists, understand what it talks to, then decide what to allow. This drove our entire rollout. What made it workable across 216 sites was that the work compounds. The same device types show up everywhere, so a policy written at the first plant carries to the next. You build a body of work that lets you move faster as you go. We started last year and are at about 85 sites now, in various stages from monitoring to full enforcement.Underneath the technology was a human strategy. Segmenting a live production floor changes how it works, and anytime you move somebody’s cheese, you have to have a conversation. Our security group had built a reputation for protecting the business first, and that goodwill carried us through the harder conversations.Step 1: See everythingBecause the profiling is agentless, a device gets identified the moment it joins the network: what it is, who makes it, and more. We wired in our existing tools to go deeper.CrowdStrike was the big one: I integrated the environment against our CrowdStrike database, so a device shows up with its security score attached. If it falls below a certain health threshold, our policy can say this device isn’t healthy anymore and shouldn’t be allowed to talk. Dragos is next on our roadmap. It’s built specifically to understand OT devices and the threats against them, and once that integration lands, I expect to write a policy against a device’s Dragos risk score—trusting a machine not just for what it is, but what’s enabled on the device.The visibility caught real issues right away. Someone had plugged an Xbox into the OT network. I saw it in the asset list, blocked the MAC address in seconds, and never had to send anyone to the plant to hunt for a cable.Step 2: Watch the trafficOnce you know what exists, you look at what it does. The visualizer shows the flows of what a given HMI is talking to, what’s reaching out to the internet, what was allowed, and what was denied. Here is a real example: a new handheld scanner came onto a network and started communicating differently than the model it replaced. One flow showed up blocked. I could see it immediately, check the vendor documentation, confirm the new device legitimately needed that path, and open it instead of chasing a mystery outage.Step 3: Write policy on the device, not the IPRules are written against the profile of a device, not its IP address. When I want voice equipment to talk to certain systems, I write a policy that says a Polycom voice device gets that permission. If something else gets plugged into that jack that doesn’t match the profile, it can’t talk. It’s blocked. Sometimes that generates a support ticket, which I treat as a feature: it forces a direct conversation with site staff about putting only authorized devices on the network.Our rollout method was deliberately gradual. We started with an open-ish “gray list” to allow what clearly isn’t risky, blocked the ports that keep you up at night (SMB, Telnet, SSH, FTP), and let the rest run so we could learn. We watched what fell through to the catch-all, decided what deserved a formal policy, then flipped to enforcement and dropped the rest.Step 4: An incident-response plan you set in advanceWe built our ransomware response directly into the policies as a four-state control switch: red, orange, yellow, green. The point is to make the hard calls while writing policy and not in a room at 2 a.m. while an indicator of compromise (IOC) is spreading.Red cuts lateral movement and blocks traffic while continuing to collect telemetry on what’s trying to communicate.Orange opens just enough to remediate, letting endpoints reach CrowdStrike or a patching server.Yellow brings critical business processes back online.Green is a normal run state.Every policy carries a checkbox for which mode it lives in, so the whole plant can change posture with a single control.Step 5: Get vendors in without flying them inWe branded our remote access service internally as Eaton Rapid Remote Access, or “ERAS.” It’s clientless, time-boxed, and running at over 100 sites now. A vendor enters through a ticket, gets approved, and lands on a bastion host adjacent to the OT network with nothing to install. Access can be scheduled ahead and capped at 72 hours.Early on, a vendor in Germany was facing a $9,000 flight and days of downtime to fix a plant; they did it remotely in a couple of hours instead. Across the year, ERAS has been used about 450 times, saving us north of $500,000 in travel alone.ERAS has also changed how we absorb acquisitions: drop the box in, and there’s a secure Eaton beachhead at the new facility on day one so the business can move faster. Conclusion: use a simple playbookOur playbook isn’t exotic. What made it work was sequencing and trust as much as technology. If you run a plant, a warehouse, a distribution center, or any OT environments, the honest first question isn’t which product to buy. It’s whether you can see what’s actually on your network right now. If you can’t answer that, start there. Ready to learn more?Watch the on-demand webinar: How Eaton Secured Its Manufacturing Facilities with ZscalerLearn about Eaton’s journey: Eaton Secures Global Operations with AI-Powered Segmentation
