The real challenge begins when clean architecture meets messy infrastructure, unknown dependencies, and the pressure to keep everything running.
Network segmentation projects rarely fail because teams misunderstand segmentation’s security value. They fail because the network being segmented is less understood, more interconnected, and harder to change than the architecture assumes.
Discovery exposes undocumented dependencies. Enforcement creates outage risk. Exceptions accumulate to preserve connectivity. The project can then reach deployment while leaving the most important traffic paths broader than intended.
That is the problem behind the claim that “the flat network is dead.” The architectural case against flat networks is strong. The operational work required to replace them is much harder.
Poor visibility produces permissive policy
Segmentation looks straightforward on paper: identify assets, understand which systems need to communicate, define policy, and restrict everything else.
The problem is that enforcement requires confidence. IT may know that a device exists without knowing what it does, who owns it, or which systems depend on it. That uncertainty extends beyond servers and endpoints to printers, cameras, building controls, IoT devices, OT systems, and years of accumulated legacy technology.
When teams lack confidence in the asset inventory, blocking unknown traffic feels reckless. The practical response is to preserve more connectivity than the security model intended. The network becomes segmented on paper while broad rules and exceptions preserve much of the access segmentation was supposed to remove.
Undocumented dependencies block enforcement
Knowing what is connected is only the first problem. Teams also have to determine which communication is legitimate.
Mature environments contain undocumented east-west traffic, old integrations, service accounts, management paths, shared services, and application behavior that no current owner fully understands. A traffic map can show that two systems communicate, but it cannot tell the team whether that communication is required, obsolete, or simply misconfigured.
Each uncertain flow creates a decision: block it and risk an outage, or permit it and weaken the boundary. Under production pressure, availability usually wins until someone can prove that the traffic is unnecessary.
This is where segmentation stops being a policy exercise and becomes an exercise in reverse-engineering the environment.
Discovery changes the project
Segmentation projects often begin with a defined set of applications, networks, or device groups. Discovery then reveals systems missing from the inventory, dependencies crossing supposedly separate environments, and shared services that make the proposed boundaries impractical.
The consequence is not simply more work. Each discovery can introduce another owner, test case, exception, and outage scenario. The assumptions used to estimate the project no longer match the network being segmented.
If the deadline does not move with the scope, something else usually gives. Teams reduce testing, broaden policy, postpone difficult segments, or declare completion before the intended controls are fully enforced. This is how segmentation mistakes can survive a technically completed project.
Some environments make enforcement riskier
Campus, OT, and IoT environments make the same problem more severe because the cost of an incorrect policy can be high while visibility and control are limited.
Campus networks contain changing populations of corporate devices, personal devices, contractors, guests, phones, printers, wireless infrastructure, and building systems. A policy mistake can disrupt large numbers of users and devices whose access patterns are difficult to predict.
OT introduces a different constraint. A production controller cannot be treated like an office laptop. Maintenance windows may be limited, documentation incomplete, and tolerance for testing extremely low. Many IoT devices also lack the management capabilities expected from conventional endpoints.
When an incorrect rule can interrupt production or access to a critical system, preserving existing communication becomes the safer operational decision. The result can be a partial deployment that preserves connectivity but never establishes the intended security boundaries.
Policy has to survive after deployment
A segmentation project can succeed at launch and fail six months later.
Applications move. Devices are added. Integrations change. New business requirements create new communication paths. If every change requires manual investigation, rule updates, approvals, and testing, the policy base becomes increasingly expensive to maintain.
Eventually, teams become reluctant to remove old rules because their impact is uncertain. New requests receive broader access because precise changes take too long to validate. What began as tightly controlled segmentation gradually becomes a collection of exceptions and tribal knowledge.
More granularity does not solve this problem. Every additional boundary creates more policy to understand and maintain. Segmentation stops improving security when its precision exceeds the organization’s ability to operate it reliably.
Governance decides where the compromises land
The hardest segmentation decisions cannot be solved by firewall syntax or another management platform.
Security wants tighter boundaries. Application owners want stable connectivity. Operations wants predictable change. When an application owner rejects a tighter rule because dependencies are uncertain, someone has to decide whether to accept broader access, delay enforcement, fund more discovery, or accept the outage risk required to test the boundary.
Cisco’s research into 400 failed segmentation projects found that more than 70% of proposed remedies concerned general IT project management rather than segmentation-specific fixes. Technical controls still matter, but they cannot resolve conflicts over scope, ownership, risk, and production availability.
The flat network is dying slowly for a reason
The security case against flat networks is strong. The mistake is assuming that once everyone agrees on the need for segmentation, implementation becomes a technical exercise.
The difficult work sits between those two states: discovering what is actually connected, deciding which communication is legitimate, enforcing boundaries without breaking production, and keeping those boundaries intact as the environment changes.
Segmentation works when the policy is restrictive enough to reduce unnecessary access but simple and well understood enough that operators will still enforce it when something changes under pressure.
A flat network may be the wrong idea, but replacing it with segmentation that exists mainly on diagrams is not much of an improvement.
Sources
About NetworkTigers
NetworkTigers is the leader in the secondary market for Grade A, seller-refurbished networking equipment. Founded in January 1996 as Andover Consulting Group, the company originally built and re-architected data centers for Fortune 500 firms. Today, NetworkTigers provides consulting and network equipment to global government agencies, Fortune 2000 companies, and healthcare companies. Visit www.networktigers.com
