Subscribe to the Non-Human & AI Identity Journal
Home FAQ Why do segmentation projects stall in large enterprises?

Why do segmentation projects stall in large enterprises?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated July 10, 2026

They stall because the control burden grows faster than the team can author, test, troubleshoot, and change policy. Large environments contain IT, OT, IoT, and cloud-connected assets with different constraints, so one rule model does not fit all. If discovery is incomplete or the architecture depends on agents everywhere, the rollout stops at the hardest assets.

Why This Matters for Security Teams

Segmentation is rarely just a network design exercise. In large enterprises, it becomes a control system that has to survive asset discovery gaps, legacy protocols, operational exceptions, and constant change. That is why it often stalls: the policy model must be precise enough to reduce blast radius, but simple enough for teams to operate across IT, OT, IoT, and cloud-connected workloads. Current guidance from the NIST Cybersecurity Framework 2.0 treats segmentation as part of broader risk reduction, not a one-time architecture project.

For identity-heavy environments, segmentation also intersects with Non-Human Identity governance. When service accounts, API keys, and machine-to-machine pathways are not mapped, security teams end up segmenting traffic without understanding which identities are actually moving it. That is a common failure mode in environments where credential sprawl and network sprawl grow together. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes it hard to enforce meaningful boundaries.

In practice, many segmentation programmes fail only after the first exception path has become the real architecture, rather than through intentional design.

How It Works in Practice

Successful segmentation starts with a trust and dependency map, not a firewall rule set. Teams need to identify business services, communication paths, privileged management routes, and the identities that authenticate each flow. That usually means combining asset inventory, traffic analysis, application owner input, and policy enforcement points across cloud, datacentre, and operational technology zones. For a useful reference on identity and machine access risk, NHIMG’s Ultimate Guide to NHIs is directly relevant because segmentation often fails when service accounts are not visible or governed.

In mature environments, policy should be expressed in layers:

  • business intent, such as which applications may communicate
  • enforcement rules for east-west and north-south traffic
  • identity-aware exceptions for administrators, automation, and third-party access
  • validation and monitoring so blocked traffic and permitted bypasses are reviewed continuously

Operationally, teams should expect segmentation to be iterative. Start with high-value zones, critical crown-jewel systems, and remote administration paths. Then prove the control with logging, controlled testing, and rollback procedures before expanding scope. This aligns with the broader NIST CSF emphasis on asset understanding, protective controls, and ongoing monitoring, rather than treating segmentation as a static perimeter.

Where the approach breaks down is in mixed legacy environments with brittle OT protocols, undocumented dependencies, or applications that require broad multicast, peer discovery, or flat management networks to function.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance blast-radius reduction against business continuity, change velocity, and support cost. That tradeoff becomes sharper in large enterprises because one policy pattern rarely fits datacentre apps, SaaS, plant-floor systems, and contractor access. Best practice is evolving toward zoned design, identity-aware exceptions, and progressive enforcement rather than “big bang” microsegmentation.

There is no universal standard for how much exception handling is acceptable. In some OT and IoT settings, the safest design may be coarse zones with strong monitoring, while in cloud-native workloads, finer-grained application segmentation may be feasible. The deciding factor is not elegance, but how much visibility and change control the organisation can sustain.

Security teams also need to account for the hidden identity layer. If machine credentials are long-lived, overprivileged, or embedded in code, a network boundary may slow lateral movement but still leave trusted pathways open. That is why segmentation should be reviewed alongside NHI lifecycle controls and secrets governance, not treated as a standalone cure. NHIMG notes that 97% of NHIs carry excessive privileges, which helps explain why network controls alone often underperform. Even strong designs become fragile when exception sprawl, incomplete discovery, or unmanaged automation identities dominate the environment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-5Segmentation and network separation are core to limiting access paths.
MITRE ATT&CKT1018Hidden internal discovery is a common precursor to lateral movement in flat networks.
OWASP Non-Human Identity Top 10NHI-02Overprivileged machine identities undermine network boundaries and exception handling.
NIST Zero Trust (SP 800-207)SC-7Zero Trust requires explicit trust boundaries and enforced segmentation policies.

Monitor internal discovery activity to validate whether segmentation is actually constraining attackers.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org