Why network segmentation projects fail and what OT changes

At a glance

What this is: This is an analyst take on why segmentation projects stall, with OT, IoT, and policy enforcement constraints emerging as the main reasons.

Why it matters: It matters because IAM and security teams increasingly have to govern identities and reachability across managed, unmanaged, and operational environments without relying on endpoint agents.

By the numbers:

• Of the 14 microsegmentation vendors referenced in that Forrester report who tried to secure their private networks with limited segmentation or by adopting a NAC solution, 11 failed.

👉 Read Elisity’s analysis of why network segmentation projects fail in OT environments

Context

Network segmentation fails when policy intent cannot be translated consistently across firewalls, switches, routers, endpoints, and unmanaged devices. In practice, the hardest problems are visibility, coordination, and enforcement, not just the initial design of the zones.

The identity angle is real but indirect: segmentation increasingly depends on knowing which users, devices, workloads, and operational assets are allowed to reach what. That puts identity context, access policy, and lifecycle governance into the same control conversation as network architecture.

Key questions

Q: What breaks when segmentation depends on endpoint agents in OT environments?

A: Segmentation breaks when it assumes every asset can host an agent, reboot safely, or tolerate frequent policy changes. OT and IoT systems often cannot meet those conditions, so teams end up with controls that look consistent on paper but fail in operational reality. The better approach is to enforce at the network layer and reserve agents for the assets that can support them.

Q: Why do segmentation projects struggle in environments with mixed device types?

A: They struggle because mixed estates combine managed endpoints, unmanaged appliances, and fragile operational devices under one policy model. That creates visibility gaps, inconsistent enforcement, and competing team priorities. When the asset base is heterogeneous, policy design has to start with what can actually be observed and controlled, not with an idealised architecture diagram.

Q: How do you know if segmentation policy is actually working?

A: You know it is working when the policy can be validated against observed traffic, the paths it should block are no longer reachable, and legitimate operational flows still function. In practice, this means measuring real reachability, not just policy intent. If exposure analysis and live enforcement tell the same story, the control is behaving as designed.

Q: Who is accountable when segmentation failures leave lateral movement paths open?

A: Accountability usually sits across network, security, and operations leadership because segmentation is a shared control, not a single-team task. Governance should define who owns the policy model, who validates exposure, and who approves exceptions for fragile environments. Without clear ownership, the project becomes a recurring debate instead of an enforceable control.

Technical breakdown

Why microsegmentation projects stall in heterogeneous environments

Microsegmentation is the attempt to narrow east-west access to the smallest practical scope, often by workload, device, or user context. It becomes difficult when the environment includes managed laptops, servers, cloud workloads, printers, cameras, OT devices, and other assets that cannot all be instrumented the same way. The failure mode is not the policy concept itself but the mismatch between policy ambition and operational reality. Visibility gaps, inconsistent ownership, and uneven data classification create analysis paralysis before enforcement begins.

Practical implication: build an asset and traffic inventory first, then scope segmentation to the devices and flows you can actually observe.

Exposure management versus active enforcement

Exposure management and active enforcement solve different layers of the same problem. Exposure management builds a digital twin from firewall, switch, router, and endpoint data so teams can simulate where policy is being violated and where paths exist. Active enforcement uses identity and context to apply policy centrally in real time. The former validates what is exposed, while the latter narrows what is allowed. They are complementary because one explains the topology of risk and the other constrains reach in operation.

Practical implication: use simulation to validate policy design, then use identity-aware enforcement to stop lateral movement at runtime.

Why OT segmentation cannot rely on endpoint controls

Operational technology and IoT environments change the rules because uptime is non-negotiable and endpoint agents are often impossible to deploy. Many controllers, sensors, and industrial devices run systems administrators cannot safely reconfigure, and a reboot can be unacceptable. That means segmentation must happen at the network layer, where reach can be restricted without touching the device. In these environments, the control objective is containment without disruption, not perfect endpoint visibility.

Practical implication: place compensating controls at the network boundary and avoid designs that depend on agents, reboots, or frequent device changes.

Threat narrative

Attacker objective: The attacker wants to expand lateral reach inside the environment so a single foothold can turn into broader operational access or disruption.

1. Entry occurs through over-permissive reachability or a weakly segmented path that lets an attacker move laterally between otherwise separate zones.
2. Escalation follows when the attacker uses legitimate protocols or trusted internal paths to traverse devices and systems that were never intended to communicate.
3. Impact is the expansion of the blast radius, including access to OT systems, sensitive workloads, or operational services that segmentation was meant to contain.

NHI Mgmt Group analysis

Policy failure is usually a governance failure before it is a tooling failure. Segmentation projects stall when no one owns the translation from intent to enforceable policy across network, security, and operations teams. The article’s Forrester references reinforce that analysis paralysis, inventory opacity, and inconsistent policy are recurring blockers, not isolated mistakes. Practitioners should treat segmentation as a cross-domain governance programme, not a one-time network project.

OT changes the control model because uptime replaces flexibility as the primary design constraint. In IT, teams can often tolerate agents, reboots, and iterative policy tuning. In OT and IoT, those assumptions break immediately, which means the architecture has to enforce containment without touching the device. That is why network-layer controls matter: they protect fragile environments without depending on endpoint presence. Practitioners should design for non-intrusive containment from the outset.

Identity context is becoming a routing control, not just an access-review input. The article shows that effective segmentation increasingly depends on understanding who or what is on the network at the moment of access, especially when users, workloads, and devices share infrastructure. That makes identity lifecycle, device context, and policy enforcement part of the same control plane. Practitioners should align segmentation with IAM, not treat it as a separate layer.

Exposure mapping and enforcement are now complementary disciplines, not competing ones. One tells you where policy is broken in the real estate you already have, while the other narrows what can be reached in real time. Organisations that only map exposure will keep finding gaps without closing them; organisations that only enforce may miss hidden pathways. Practitioners should pair simulation with live control if they want lasting reduction in lateral movement.

Device diversity debt: mixed estates of managed, unmanaged, and unpatchable devices create a persistent gap between segmentation policy and actual reachability. The article’s strongest underlying concept is not microsegmentation itself but the operational debt created when one policy model has to fit very different device classes. That debt accumulates until projects stall or get watered down. Practitioners should reduce the scope of the first policy wave to the asset classes they can govern end to end.

What this signals

Segmentation is increasingly an identity-governance problem disguised as a network project. As more environments depend on device, workload, and user context to drive reachability, teams need stronger linkage between IAM, inventory, and policy enforcement. The practical signal is that segmentation programmes will fail if identity data and asset data stay in separate operational silos.

The next phase of segmentation will reward organisations that can prove policy against live traffic, not just document intent. That means security teams should expect more demand for simulation, exception tracking, and continuous validation across network layers such as those described in NIST SP 800-207 Zero Trust Architecture.

Device diversity debt: environments with unmanaged and unpatchable assets will keep pushing teams toward network-layer containment rather than endpoint-centric control. Where agents are not viable, the real programme question is whether policy can be enforced without disrupting operations.

For practitioners

• Inventory devices and trust zones first Map managed endpoints, servers, OT assets, cloud workloads, and unmanaged devices before drafting enforcement policy. Use the inventory to identify where segmentation can be applied without agents and where compensating network controls are required.
• Separate validation from enforcement Build a simulation or exposure model to test reachability paths before you turn on blocking rules. This reduces the chance of breaking OT flows and gives operations teams a controlled way to review policy intent.
• Anchor segmentation to identity context Feed user, workload, and device identity into network policy so the rule set can distinguish between legitimate operational access and unnecessary lateral reach. This is especially important where multiple teams share the same infrastructure.
• Design for non-agent environments Assume some assets cannot host agents, cannot reboot safely, and cannot tolerate intrusive change. Put containment at the network boundary and define exception handling for OT and IoT assets up front.

Key takeaways

• Segmentation fails most often when visibility, policy ownership, and enforcement do not line up across mixed device estates.
• OT and IoT environments change the architecture because uptime and device fragility make agent-based controls unreliable or unusable.
• The most durable programmes combine exposure mapping with identity-aware enforcement so they can reduce lateral movement without breaking operations.

Key terms

• Microsegmentation: Microsegmentation is the practice of reducing internal network reach so systems can talk only to the assets and services they actually need. It is usually enforced at the workload, device, or identity level, making lateral movement harder and policy precision much higher than broad zone-based segmentation.
• Exposure Management: Exposure management is the discipline of mapping and simulating how an environment is actually connected so teams can see where policy gaps and attack paths exist. It does not enforce blocking by itself. Its value is in turning hidden reachability into something that can be measured, prioritised, and remediated.
• Operational Technology: Operational technology is the class of systems that control physical processes, such as industrial equipment, building systems, or critical infrastructure. These environments usually prioritise uptime and safety over frequent change, which makes endpoint-based security controls and disruptive policy changes much harder to use.

What's in the full article

Elisity's full post covers the operational detail this post intentionally leaves for the source:

• How the RedSeal and active-enforcement approaches differ in practice when you are validating policy across firewalls, switches, routers, and endpoint agents
• The OT-specific constraints that make network-layer enforcement preferable to endpoint-based controls in uptime-critical environments
• The practical reasons segmentation work stalls in large enterprises, including policy inconsistency, visibility gaps, and team silos
• The video conversation with Joseph Ward about where segmentation tooling has matured and where it still needs careful deployment

👉 The full Elisity post covers the RedSeal perspective, OT constraints, and the tooling split between exposure mapping and enforcement.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and workload identity. It is designed for practitioners who need to connect identity controls to broader security architecture and operational risk.