Why Segmentation Programs Wither on the Vine
Many networks are still flat, or close enough to it that it doesn't matter. A compromised laptop in a conference room can talk to a domain controller. A vendor's HVAC controller can reach the same subnet as a finance server. An automated guided vehicle (AGV) rolling across a plant floor can sit on the same flat network as the machine vision system inspecting the parts it's carrying, and both can reach a domain controller across the building, or a cloud SaaS platform across the internet, with nothing in between to stop them. This isn't news to anyone who's read a breach post-mortem in the last five years.
Lateral movement across an under-segmented network is one of the most consistent patterns in how a small incident becomes a headline.
So organizations decide to fix it. And that's usually where things get harder than anyone expected, because "segment the network" isn't a single technical decision. It's a choice between fundamentally different approaches, each with its own tradeoffs, and in most real environments, some combination of all of them.
This post walks through three ways organizations actually do segmentation, in roughly the order you'd move through them on a maturity curve. There's the elegant end state everyone wants, the practical middle ground most land on, and the unglamorous reality of getting an existing environment to either one. Before getting into the details of each, though, it's worth being honest about what all three have in common, and why none of them are as easy as the vendor pitch makes them sound.
Three postures, at a glance
Tag-based, identity-driven segmentation assigns access dynamically based on who or what a device is, using policy engines such as Cisco ISE, Arista's Multi-Domain Segmentation Service (MSS), or other network vendor based segmentation strategies paired with mechanisms like RADIUS Change of Authorization (CoA), to move a device into the right segment the moment it's identified, with no manual VLAN reassignment required.
Device-type segmentation groups things by what they are rather than who they belong to, using profiling and visibility tools to fingerprint devices, especially the OT, IoT, and medical devices that can't run an agent or authenticate cleanly, and assign policy based on device class.
Brownfield brute-force segmentation is what it sounds like. It means taking an existing, tangled environment and manually re-architecting routing, addressing, and access to get it segmented, because the environment is too old, too undocumented, or too mission-critical to simply drop a clean identity or profiling layer on top of it.
Most mature environments end up running a blend of all three. Here's the reality check to keep in mind before looking at each one in detail.
A reality check
Segmentation is not easy, and it isn't solved by any single tool or technology, no matter how good the platform's marketing slide looks. Before a single policy gets written, someone has to know what's actually out there, how it behaves, and what each application needs to function. That means knowing which specific traffic flows have to be permitted just to keep the thing running. It takes real expertise across the infrastructure, including WAN, wireless controllers, LAN, WLAN, virtualization, firewalls, IPAM, authentication, and Active Directory, among others. Missing any one of those is usually how a "completed" segmentation project turns into a cautionary tale.
The framing matters more than it sounds like it should, too. You are not segmenting devices. You're segmenting systems and applications, and everything they depend on to function. A device is easy to place in a segment. An application that quietly depends on six other systems spread across four of those segments and/or external services is the actual problem.
Six questions before you start
Six questions are worth asking honestly before a program starts, and revisiting throughout, not just at kickoff.
What do I have? A real, current inventory, not the spreadsheet from two reorgs ago. And this question needs to be asked continuously throughout the program as devices break and are replaced, added, and removed while you are trying to inventory. Plan for it.
Where does it go? What segment, zone, or policy group each system actually belongs in, given what it does and what it talks to.
How does it behave? What traffic it generates and depends on right now, observed rather than assumed.
Will vendors be needed? Some systems (legacy platforms, proprietary OT equipment, niche line-of-business applications) need the vendor or a specialist in the room, not just the internal network team.
What services does it need? Translating behavior into an explicit, defensible policy. That means specifying exactly what has to be permitted, and nothing else.
What tests will validate functionality? Functional testing to confirm everything still works the way it did before, and adversarial testing, real penetration testing, to confirm the new boundary actually holds, not just that it's assumed to. Both defined in advance, so that if something breaks, unplanned outages are kept to a minimum and service gets restored quickly instead of becoming a multi-day scramble.
Nobody knows what their apps need
Question three is usually the one organizations underestimate most. Almost nobody actually knows what their applications need from a firewall policy. Years of flat access hide real dependencies until someone maps them. There's the reporting job that quietly reaches a database three subnets away, the vendor integration nobody documented, the legacy service three other systems depend on without anyone remembering why.
There's a harder truth underneath that, and it's worth saying plainly. Most organizations simply don't have the application expertise to answer this on their own. Walk into a client site and ask what protocols a given application needs to function, and the honest answer is usually a blank stare, not because anyone is hiding anything, but because the people running and using that application are manufacturing experts, or clinical experts, not IT experts. Their expertise is in what the application does for their job, not in the ports, protocols, and dependencies that make it work on the network. That's not a knowledge gap anyone should be embarrassed about; it's simply the reality of who owns the application versus who owns the network, and it's exactly why guessing at policy from a wiki or an old network diagram doesn't hold up. This is where observability and flow-analysis tooling stops being optional. It turns "how does it behave" from a guess into evidence. And worth noting, the same flow data collected to answer that question is also the input network automation needs later, if that's on the roadmap. It's not a separate initiative, just a natural extension of work already done.
The standardization myth
Question one deserves the same skepticism. Few enterprises are starting from zero, and most mature organizations have tried some version of segmentation before. Maybe it's an old VLAN scheme built for a different reason at the time, a NAC deployment that only ever got partway rolled out, or a microsegmentation pilot that stalled after phase one. The natural assumption going into a new program is that the environment is standardized the way everyone thinks it is. It rarely is. Naming conventions drift by site, the standard everyone references turns out to have only ever been enforced on half the network, or an earlier segmentation effort is still partially in place and nobody remembers exactly where. That's how a program that budgeted for new work ends up absorbing old technical debt it didn't plan for, in the middle of execution rather than at kickoff when there was still time to scope around it.
The single biggest mistake
That history points to something else worth stating plainly. The single biggest mistake an organization can make once a new program is underway is running two different segmentation approaches side by side, indefinitely. That might mean the old VLAN-based scheme kept alive alongside a new identity-driven platform, a legacy NAC deployment layered under a new device-profiling tool, a private VLAN or VRF isolation strategy. Each one made sense on its own, at the time. Together, they create a patchwork where nobody can say with confidence which policy actually governs a given device, and where the boundary the new program was supposed to establish gets quietly undermined by rules nobody remembers writing. Retiring the old approach, rather than layering a new one on top of it, is the right move, but it's a genuinely big bite to take, which is exactly why many organizations don't do it, and end up supporting a patchwork instead.
These six questions matter just as much when the identification and tagging are being done by a vendor platform as when they're done manually. A segmentation program takes a village. Good tools can be invaluable, but there is no easy answer. No single platform or approach replaces doing this work. Keep that in mind as we walk through each posture below.
Tag-based, identity-driven segmentation
This is the approach most security teams point to as the ideal. A device or user authenticates, an identity engine (Cisco ISE, Arista MSS, etc.) evaluates who or what just connected, and policy gets applied dynamically, often down to the level of "this user, on this device type, in this location, gets this access, and nothing else." When something changes (a device fails a posture check, a user's role changes, a threat is detected), CoA lets the system push a new authorization to the switch or wireless controller in real time, without waiting for someone to log in and move a port to a different VLAN.
More than just Cisco
Cisco ISE is the name most people reach for, but it isn't the only option. Arista's Multi-Domain Segmentation Service (MSS) does much the same job on its own stack. It pulls identity from NAC systems, CMDBs, virtualization platforms, and IPAM tools to dynamically tag endpoints and workloads, maps existing traffic to recommend policy, and enforces it at wire speed on Arista switches or by redirecting flows to a third-party firewall. In fact, most top-tier network and security vendors now ship some version of a segmentation solution. That's genuinely useful to know. It's also worth being clear-eyed about the limits of it, particularly scalability. A vendor platform is a piece of the puzzle, not the puzzle solved.
Identify. Tag. Then what?
Here's why. Even the most mature version of this approach, running exactly as designed, mainly tries to do two things well. Idetify ("profile") what's connecting, and it tag it correctly. That's real, hard, valuable work. But then what? Identification and tagging tell you what something is; they don't tell you what it's allowed to talk to, or why. Someone still has to write that policy in the specific, defensible sense described above, and someone still has to test that it holds once it's enforced. The platform doesn't do that part. It's still the organization's job, not the tool's.
The catch
The appeal beyond that is obvious. It's dynamic, it's granular, and once it's running, it scales (you hope) without much manual intervention. The catch is what it takes to get there. It assumes clean, reliable identity data. That means a functioning 802.1X deployment, accurate device inventories, and authentication infrastructure that's actually enforced everywhere, not just on the easy segments of the network. Most organizations don't have that on day one, which is usually why "we'll just roll out ISE" (or MSS, or whichever platform) turns into a multi-quarter (or multi-year) effort before a single new policy actually changes anyone's access.
Device-type segmentation
Not everything can authenticate. This is particularly true of IoT and OT. Think of a building's badge reader, an ultrasound machine, or a warehouse motion sensor. These devices often can't run 802.1X, can't be agent-managed, and in some cases can't tolerate being touched at all without risking downtime or a support contract violation. Manufacturing environments push this problem the hardest, since so much of what's running on the plant floor is operational technology (OT) rather than conventional IT. That includes programmable logic controllers (PLCs) running a production line, automated guided vehicles (AGVs) moving material across the floor, machine vision systems inspecting parts in real time, robotic work cells, and the SCADA and HMI systems supervising the whole process. For this class of device, segmentation usually starts with visibility and profiling tools (platforms like ForeScout, ORDR, and Nozomi Networks are common examples) that passively fingerprint devices on the wire and classify them by type, then apply policy based on that classification rather than an identity handshake.
The security and IP stakes
Manufacturing OT also raises the stakes in ways a typical IT segmentation conversation doesn't fully capture. Ransomware that reaches a PLC or an AGV fleet doesn't just encrypt files, it can stop a production line outright, with real safety and revenue consequences. And the control logic, recipes, process parameters, and calibration data running on that equipment are often the intellectual property that makes a manufacturing process competitive in the first place. A compromised machine vision system or an exposed HMI isn't just a security event; it's a potential path for a competitor, or an adversary, to walk off with years of process engineering, or to disrupt the line entirely. That's a strong argument for segmenting OT away from the rest of the network by default, not as an afterthought once IT segmentation is "done."
The precision tradeoff
This is a genuinely practical middle ground. It doesn't require the identity infrastructure that tag-based segmentation depends on, and it directly addresses the OT/IoT problem that pure identity-based approaches tend to struggle with. The tradeoff is precision. Device-type policy is coarser than identity-based policy by nature, and a device that's misclassified, deliberately or not, can end up in the wrong segment with the wrong access. It's a strong complement to identity-based segmentation, but rarely a full replacement for it in environments that also have a lot of user and application traffic to manage.
Brownfield brute-force segmentation
Then there's the environment that doesn't have clean identity infrastructure, doesn't have consistent device profiling in place, and can't simply have either bolted on overnight, because it's been growing organically for a decade or more, and nobody currently has a full picture of what depends on what. For this environment, segmentation isn't a policy engine decision. It's a hands-on re-architecture.
The infrastructure blast radius
The infrastructure blast radius here is wider than most people expect going in. It's not just routing and addressing, although IP address management, DNS, and DHCP absolutely come into play, since segmenting a network usually means re-carving address space and re-pointing name resolution across it. It also pulls in WAN (paths and access change once flat routing goes away), wireless (SSID and VLAN mapping, roaming behavior across newly segmented zones), virtualization (VM placement, virtual switch and port-group policy, and the east-west traffic between virtual machines that used to be completely invisible), Change Management, and authentication infrastructure itself, since even a brute-force segmentation effort eventually needs an AAA layer to sustain it. None of those teams signed up to be part of "the segmentation project," but each of them is going to get an ask.
More than a technical ask
And the ask isn't only technical. Every one of those verticals means coordinating a maintenance window at whatever site or location is being segmented, which means someone has to accept planned outages. The work doesn't end at cutover, either. Every application and service at that site needs to be validated afterward to confirm it still functions the way it did before segmentation changed its network path. That's effectively its own project in miniature, repeated at every site in scope.
This is the approach organizations use least by choice and most by necessity, and it's usually the one that reveals how big the effort really is.
It has to start from the top
Everything above, the inventory work, the vendor coordination, the cross-team execution across WAN, wireless, IPAM, virtualization, and authentication, the planned outages, the validation testing, competes for the same scarce time and budget as every other initiative already on the roadmap. None of it happens on its own, and none of it happens because a network engineer asked nicely.
No clout, no program
Segmentation programs succeed or fail based on whether they have real executive sponsorship, not just a name on a project charter. That sponsorship is what gives the program the clout to pull people off their day jobs, to get a site to actually agree to a maintenance window, and to hold that window when something else, a product launch, a quarter-end close, another fire, tries to bump it. Without that clout, the motivation to divert resources and to take planned outages simply isn't there. The program withers on the vine. It starts strong, racks up a few easy wins, and then quietly stalls the first time it asks a business unit to take downtime it doesn't see the value in.
This is worth saying plainly because segmentation tends to get pitched as a technical project. It isn't one. It's an organizational commitment that happens to have a lot of technical work inside it, and it needs a sponsor with the authority to make trade-offs stick across departments that don't report to each other and don't share the same priorities. A segmentation program takes a village, but a village still needs someone with the authority to call the meeting.
Post-segmentation isn't the finish line
Cutover isn't the end of the program. It's the start of a new operational model, one the organization now actually has to run day to day. Policies need maintenance as new devices, applications, and exceptions get introduced. Segments drift over time as teams request access exceptions to solve an immediate problem, and those exceptions need periodic review or they quietly erode everything the project accomplished. Re-validation, both functional and adversarial, needs to happen on a cadence, not just once.
Define the operating model before cutover
The mistake most programs make is waiting until after go-live to figure out how sites are supposed to operate in the newly segmented environment. Those processes and procedures need to be decided before cutover, not improvised after it, and they need to answer the ordinary questions a site will ask on day one. How does someone add a new device to a segment. How does a policy get changed once it's live, and who's allowed to request that change. How does a new zone get established when the business adds a new use case six months from now. Without documented answers to those questions going in, sites either escalate everything to the network team, creating a bottleneck, or find their own workarounds outside the process, which puts the organization right back into the kind of unmanaged drift the segmentation program was built to eliminate.
Review existing policies for leverage, not just future operations
The existing change management, access request, and firewall rule procedures shouldn't only be reviewed to figure out how they'll function after segmentation goes live. They're also worth mining for ways to make the program itself move faster. Most environments have accumulated exceptions, manual approval chains, and workarounds that make change slow today, and cutover is the moment to strip those out rather than carry them into the new environment unexamined. What testing tools can be handed to application owners so they can validate their own segment before go-live, instead of waiting on the network team to do it for them. What rule exceptions can be pre-approved for common, low-risk scenarios so routine requests stop requiring full review. What self-service capabilities can a site earn once its segment is stood up and stable, so finishing the migration gets them something back, whether that's faster changes, fewer tickets, or less waiting, instead of just more controls to live under. Programs that only communicate what segmentation restricts tend to generate resistance and shadow workarounds. Programs that also show sites what they stand to gain once they've made the transition tend to get people moving toward it instead of around it.
The real differentiator
Whichever posture, or combination of postures, an organization chooses, the program-level asks are the same regardless. There's a real inventory, a policy specific enough to build from, visibility into what's actually happening on the network, cross-team execution across WAN, wireless, IPAM, virtualization, and authentication, and two kinds of validation before anyone calls it done. That's what separates the efforts that quietly succeed from the ones that become a shock to the system, a scramble of broken applications, blown maintenance windows, and teams that didn't know they were part of this project until it broke something they owned.
Understanding this scope going in is the difference between a program and a crisis.
This is exactly the kind of cross-functional, multi-vertical effort EIA is built to run, from getting a stalled segmentation project off the ground to operationalizing one across a global environment, backed by the network automation and observability capabilities that make it possible to see what's actually happening before a single policy gets written. Learn more at www.eianow.com.