Notifications
Clear all
Topic starter
10/07/2026 9:22 pm
TL;DR: Most microsegmentation projects fail because device diversity, silos, incomplete visibility, and immature enforcement tooling make policy hard to apply consistently across IT and OT environments, according to Elisity’s interview with RedSeal’s Joseph Ward. The practical answer is to validate exposure first, then enforce identity-aware network controls where agents and reboots are not viable.
NHIMG editorial — based on content published by Elisity: Why network segmentation projects fail and what OT changes
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory devices and trust zones first Map managed endpoints, servers, OT assets, cloud workloads, and unmanaged devices before drafting enforcement policy.
- Separate validation from enforcement Build a simulation or exposure model to test reachability paths before you turn on blocking rules.
- 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.
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
👉 Read Elisity’s analysis of why network segmentation projects fail in OT environments →
Network segmentation failures in OT: what teams keep missing?
Explore further
10/07/2026 9:44 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Why network segmentation projects fail and what OT changes
