Blog da Zscaler

Receba as últimas atualizações do blog da Zscaler na sua caixa de entrada

Customer Stories

How Eaton Secured 100+ Manufacturing Facilities with Zscaler

image

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 down

For 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 enforce

My 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 everything

Because 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 traffic

Once 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 IP

Rules 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 advance

We 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 in

We 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 playbook

Our 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.

form submtited
Obrigado por ler

Esta postagem foi útil??

Aviso legal: este post no blog foi criado pela Zscaler apenas para fins informativos e é fornecido "no estado em que se encontra", sem quaisquer garantias de exatidão, integridade ou confiabilidade. A Zscaler não se responsabiliza por quaisquer erros, omissões ou por quaisquer ações tomadas com base nas informações fornecidas. Quaisquer sites ou recursos de terceiros vinculados neste post são fornecidos apenas para sua conveniência, e a Zscaler não se responsabiliza por seu conteúdo ou práticas. Todo o conteúdo está sujeito a alterações sem aviso prévio. Ao acessar este blog, você concorda com estes termos e reconhece que é de sua exclusiva responsabilidade verificar e utilizar as informações conforme apropriado para suas necessidades.

Receba as últimas atualizações do blog da Zscaler na sua caixa de entrada

Ao enviar o formulário, você concorda com nossa política de privacidade.