Why Network Segmentation Projects Fail: A RedSeal CPTO View

Most network segmentation projects do not finish. They start with a clear charter, stall somewhere in the middle, and quietly become a line item nobody wants to revisit. That is the uncomfortable backdrop to any honest conversation about why network segmentation projects fail, and it is the same pattern Forrester documented years before the current wave of zero trust spending.

The reasons are rarely about budget or intent. They are about device diversity, organizational silos, inconsistent policy, and, for most of the last decade, technology that simply was not mature enough to enforce segmentation without breaking things. At the Elisity Video Studio at RSAC 2026, we sat down with Joseph Ward, Chief Product and Technology Officer at RedSeal, to talk through why segmentation has been so hard, and why the tooling has finally caught up.

Why do network segmentation projects fail? Network segmentation projects fail because the work spans too many systems and too many teams to coordinate with the tools most organizations have on hand. Forrester’s analysis in 2022 points to over-optimistic planning, improper execution, analysis paralysis, the lack of a nontechnical business driver, poor network visibility, and weak data discovery and classification. Underneath all of those is a simpler truth: enforcing one consistent policy across firewalls, switches, routers, endpoints, and unmanaged devices used to require stitching together data and controls that did not talk to each other. The technology to do that cleanly is recent.

Who is Joseph Ward, and why his perspective matters

Joseph Ward is the Chief Product and Technology Officer at RedSeal, an exposure management platform. He has spent more than 20 years building security products across detection and access-control companies, including Damballa and Ionic Security, which gives him an unusually long view of how segmentation has matured. That history matters here, because Joseph is not speaking as a segmentation evangelist; he is a product leader who has watched the category fail, stall, and finally become viable.

RedSeal’s role in that picture is specific. As Joseph put it, “RedSeal is an exposure management platform. What that basically means is that we find all of the different ways threat actors are going to try to get into your environment, and we help you shut them down before those threat actors are able to take advantage of those various paths.” That framing matters for the rest of this conversation, because exposure management and active enforcement are not the same job, and the distinction is where a lot of segmentation confusion lives.

Why network segmentation projects fail: devices, silos, and missing technology

When we asked Joseph what has been holding segmentation back, he did not reach for a vendor story. He recalled Forrester research suggesting that roughly 70% of segmentation projects fail, a figure he offered from memory that tracks with Forrester’s broader conclusion that most fail. Then he started with the difficulty of the problem itself.

“It’s hard. You’ve got all of these different devices, you’ve got all of these different systems trying to interact with each other, and you’ve got different organizational silos where the policies are different. To have proper segmentation policy enforcement, you have to combine all of that together. The technology for that hasn’t really been around for very long.”

That single answer maps cleanly onto Forrester’s failure causes, which stack up across four recurring problems. The device diversity point deserves the most emphasis, because a modern enterprise network carries managed laptops, servers, and cloud workloads alongside printers, cameras, building controls, medical devices, and industrial sensors. Many of those devices cannot host an agent and were never designed to be inventoried, which is why OT asset inventory and visibility is usually the first wall a segmentation project hits. You cannot write a policy for an asset you cannot see, and you cannot enforce one on a device you cannot touch.

• Device diversity: Managed and unmanaged assets coexist, and the unmanaged ones reject agents, which breaks any approach that assumes endpoint enrollment.
• Organizational silos: Network, security, and operations teams hold different policies and different risk tolerances, so a single enforceable rule set is a negotiation, not a default.
• Inconsistent policy: Without one place to define and reconcile intent, the same traffic gets allowed in one segment and blocked in another, and the inconsistency erodes trust in the whole project.
• Immature technology: For most of the last decade, combining data and enforcement across firewalls, switches, routers, and endpoints meant manual stitching that did not scale.

This is also where microsegmentation vs. network segmentation stops being a semantic debate and becomes an operational one. Coarse network segmentation divides an environment into a handful of zones. Microsegmentation narrows controls down to the workload, identity, or device, which is far more useful for stopping lateral movement and far harder to execute with legacy tooling. The gap between those two ambitions is where many projects died.

Two ways to attack the problem, both at the network layer

One of the more clarifying moments was Joseph laying out two distinct, complementary approaches to segmentation, candid that they solve different parts of the same problem.

“You’ve got two different options on how you can look at this. You can either pull data from every one of those systems, this is RedSeal’s approach, where we pull data from firewalls, switches, routers, endpoint agents, all of that, and then you can actually see if policies are being violated, because you have all of that in a single digital twin simulation. The other way is something that’s doing active enforcement, like you guys do with Elisity, where you’re actually pulling data from systems that know about these users and the context, and you’re able to enforce that centrally in one place very easily. That didn’t exist four, five, six years ago. The technology is just now showing up and actually being able to be used.”

Joseph drew a fair and precise line here. The first approach builds a digital twin of the network by ingesting configuration data from firewalls, switches, routers, and endpoint agents, then simulates that model to surface where policies are being violated and where exposure paths exist. That is the exposure management discipline RedSeal works in. It answers the question, “Given how everything is actually configured, what can reach what, and where are we exposed?”

The second approach is active enforcement. It pulls identity and context from the systems that already know who and what is on the network, then enforces policy centrally and continuously. That is the discipline Elisity works in. It answers a different question: “Right now, what is this user or device allowed to reach, and is the policy being applied?”

These are complementary, not competing. Joseph said it plainly: “In our case, we are looking at it from the network layer. You are too.” Exposure management tells you where your segmentation has gaps and validates that intent matches reality. Active identity-based enforcement narrows what any identity can reach and keeps the policy applied as conditions change. An organization serious about segmentation benefits from both the map and the guardrails. The reason both have become viable in the last few years is the same: they operate at the network layer rather than depending on agents on every device.

Watch the full conversation

Why OT and critical infrastructure change the rules

When the conversation turned to healthcare, manufacturing, and critical infrastructure, Joseph was clear that these environments are not just harder versions of IT. They operate under constraints that make the standard segmentation playbook unusable from the start.

“In a traditional IT environment, you can put an agent on those systems. In a traditional IT environment, you have 20, 30 years of best practices where people understand, okay, we’re going to block this off, we’re not going to allow access here. You can’t do that in an OT or IoT environment, and that’s what these different segments you mentioned all have in common. We’re talking about devices that, sure, they have some sort of operating system on them, but you may not have access to that operating system. You can’t put an agent on them. And also, uptime is absolutely 100% critical in these environments.”

This is the heart of why OT network segmentation demands a different model. Three constraints stack on top of each other in operational technology, and each one rules out a common IT assumption.

• No agents: The device may run an operating system you cannot access, so endpoint-based controls are off the table from the start.
• Uptime is absolute: As Joseph noted, if you run a power generation facility, “your generator can’t go down, which means your SCADA system can’t go down, which means you can’t interfere with those devices.”
• No reboots, no policy on the fly: You cannot change policies on a controller mid-operation, and you often cannot even afford the reboot that a change might require.

Joseph’s conclusion follows directly: “So you have to enforce it at another layer. In our case, we are looking at it from the network layer. You are too. And that actually allows those systems to be protected in ways that they couldn’t have been before.” Enforcing at the network layer is what makes it possible to contain a compromised imaging sensor, a building controller, or a SCADA endpoint without ever logging into the device. That same logic is why living-off-the-land attacks in OT environments are so dangerous: when an attacker abuses legitimate tools and protocols on devices you cannot patch or instrument, the only durable control is limiting what those devices can reach in the first place.

The point is not that OT is too fragile to secure. It is that the security has to meet the environment where it is, and the network layer is the one place these devices reliably share. That argument extends to any fleet of unpatchable devices, the same case we made in our analysis of AI-accelerated vulnerability discovery on devices that cannot be patched. When patching is not an option and agents are not an option, narrowing reach at the network layer is what is left.

The human layer: why OT engineers fear segmentation

The most candid part of the conversation was not about technology at all. When we suggested that segmentation projects might also stall because teams hold different philosophies and worry about disruption, Joseph went straight to the people.

“When you start talking to these OT engineers about, we’re going to make sure that people can’t access your controller, or whatever the case may be, an imaging sensor, whatever, they’re terrified. What they see is, you’re blocking access, therefore I’m not going to be able to control it, you’re going to have a false positive, you’re going to cause something that gives me downtime. And of course, that means their jobs go away too. So it’s terrifying.”

That fear is rational, and worth reporting as Joseph framed it rather than dismissing it. An OT engineer who has kept a line running for years has every reason to distrust a control that could introduce a false positive at the worst possible moment. The history of clumsy network controls in operational environments is real, and the people who own uptime have lived through it.

Which is why the resolution is not technical alone. It is people, process, and technology coming together. When segmentation is designed with the OT team rather than imposed on it, when policy is observed before it is enforced, and when the enforcement layer can be tuned without touching the device, the fear has somewhere to go. The engineer keeps control. The security team gets containment. And the trust between IT and OT, which is often the real blocker, starts to build.

Where segmentation goes from here

The through-line from Joseph’s RSAC 2026 read is hopeful in a specific, unhyped way. Segmentation did not fail because the idea was wrong. It failed because the tooling could not match the ambition, the device estate was too diverse to inventory by hand, the silos were too entrenched to reconcile, and the people closest to the risk were never brought into the design. Each of those barriers is now addressable in a way it was not five or six years ago.

Two complementary disciplines have matured in parallel. Exposure management, the work RedSeal focuses on, can build a faithful digital twin and show you exactly where your segmentation does not hold. Identity-based active enforcement can take what already knows about your users and devices and apply policy centrally, at the network layer, without agents on the endpoints. Elisity built its platform around that second job, which is why it extends across IT, OT, and IoT environments where putting an agent on every device was never going to work. The two answer different questions, and the organizations getting segmentation right are increasingly using both.

Joseph’s closing observation is the one to hold onto. The capability that makes segmentation succeed today, he said, “didn’t exist four, five, six years ago. The technology is just now showing up and actually being able to be used.” The projects that failed were not foolish. They were early. The teams returning to segmentation now are working with a different set of tools, and that changes the odds.

Frequently Asked Questions About Why Segmentation Projects Fail

Why do most network segmentation projects fail?

Most network segmentation projects fail because of a combination of planning, execution, and tooling problems rather than any single cause. Forrester’s research points to over-optimistic planning, improper execution, analysis paralysis, the absence of a nontechnical business driver, inventory opacity, and insufficient data discovery and classification. In one figure from that report, of 14 microsegmentation vendors who tried to secure their own private networks with limited segmentation or a NAC solution, 11 failed. The underlying issue is that enforcing one consistent policy across firewalls, switches, routers, endpoints, and unmanaged devices required tooling that has only recently matured.

What’s the difference between exposure management and microsegmentation?

Exposure management and microsegmentation solve different parts of the same problem. Exposure management, the discipline RedSeal works in, ingests configuration data from network and security systems to build a digital twin, then simulates it to find where policies are violated and where attack paths exist. It answers, “Where are we exposed?” Microsegmentation with active enforcement, the discipline Elisity works in, pulls identity and context to enforce policy centrally and continuously, narrowing what each user or device can reach. It answers, “What is allowed right now, and is the policy being applied?” The two are complementary, and both operate at the network layer.

Why can’t OT and critical infrastructure environments run endpoint agents for segmentation?

OT and critical infrastructure devices frequently run operating systems that administrators cannot access, which makes installing an endpoint agent impossible. On top of that, uptime in these environments is effectively absolute: a SCADA system at a power generation facility cannot go down, cannot be interfered with, and often cannot even tolerate a reboot. Because you can neither instrument the device nor risk disrupting it, segmentation has to be enforced at the network layer instead, where the device’s reach can be controlled without ever touching the device itself.

How do you do microsegmentation without causing downtime or false positives?

The path that avoids downtime and false positives is to observe before you enforce, enforce at the network layer rather than on the device, and bring the operations team into the design. Modern identity-based platforms can learn normal traffic patterns and model a policy before it is ever applied, so teams can validate it against real behavior first. Enforcing at the network layer means policy can be tuned or rolled back without rebooting or reconfiguring fragile OT devices. Done this way, segmentation narrows what a compromised asset can reach while leaving legitimate operations untouched. Our guide on how to implement microsegmentation walks through the observe-then-enforce sequence in more detail.

For security and operations leaders translating this into architecture, Elisity provides identity-based microsegmentation that enforces policy at the network layer across IT, OT, and IoT environments without requiring agents on endpoints, which is what makes it workable in the uptime-critical settings Joseph described.

Further reading:

• Why Zero Trust Requires Microsegmentation: A Former Forrester Analyst Weighs In (David Holmes)
• Joan Goodchild on CISO AI Uncertainty at RSAC 2026
• Cyber Resilience at RSAC 2026: An Interview With 7-Time CSO Roger Hale
• Andy Ellis on Preventing Lateral Movement in the Age of AI Agents
• OT Segmentation to Enhance OT Network Security
• Network Segmentation: The Key to Stopping Lateral Movement and East-West Attacks

Sources and references

1. Columbus, Louis. “Forrester’s best practices for zero-trust microsegmentation.” VentureBeat, 20 July 2022. venturebeat.com
2. Holmes, David. “Best Practices For Zero Trust Microsegmentation.” Forrester Research, 2022. forrester.com