Ask any security team whether they should microsegment the network and the answer is instant. Of course. Flat networks are how one compromised laptop becomes forty compromised hosts. You segment so that when — not if — something gets popped, the attacker can't walk sideways to the domain controller and the database and the backup server. Contain the blast radius. Stop lateral movement. Nobody argues the other side of this. It's been the right answer for twenty years.
And almost nobody does it well. Not because they don't understand it. Because to write a single segmentation rule you honestly believe in, you need to know what actually talks to what — and no one has that.
A segmentation rule is a claim about reality. "This app tier talks to that database on 5432 and nothing else needs to reach it." To write that and mean it, you need an accurate map of real traffic and real dependencies: which services depend on which hosts, on which ports, in which direction, including the ugly stuff nobody documented — the batch job that reaches across three subnets at 2am, the monitoring agent that touches everything, the one legacy box half the company quietly depends on.
That map is the whole ballgame. And you don't have it. You have a diagram someone drew during a compliance push in 2021, a spreadsheet that's wrong, and a lot of tribal knowledge in the heads of people who've since left.
The map is hard for the same reason the asset inventory is hard, which is to say it's the same problem wearing a different coat. It changes constantly. Deployments shift dependencies. Someone stands up a new service and wires it to three others without telling anybody. Ports open and close. And nobody owns keeping it current — it's everyone's job, which means it's no one's.
So the honest options are bad. Watch traffic long enough to build the map from real flows, and you're staring at weeks of noisy data trying to tell a real dependency from a one-off. Or ask the teams, and you get answers that are optimistic, incomplete, and confidently wrong about the exact edge cases that break things.
Now suppose you get lucky and the map is genuinely good. You've still got the second wall, and it's taller.
Enforcing new segmentation means changing a live network. The moment you move from "monitor" to "enforce," every rule you got slightly wrong becomes an outage — and you find out which ones by watching production break. Worse, there's no clean way back. Pulling a firewall policy or a security-group change back out of a running environment isn't a button; it's another change, made under pressure, while something's already down and people are yelling.
So the rational move — the same one I wrote about with the IAM ticket that never closes — is to not touch it. Doing nothing is the only choice that's safe for the person making it. The segmentation design gets built, reviewed, agreed to, and then it lives on a slide. Everybody knows it's right. Nobody can make it real without betting production on a map they don't trust and a change they can't easily undo.
Microsegmentation isn't a knowledge problem. It's the two things underneath it: you can't write the rules without a current map of what actually talks to what, and you can't enforce the rules on a live network without a safe way back when you get one wrong. Fix those two, and segmentation stops being a slide and starts being a control. Leave them, and it stays exactly where it's been for two decades — obviously correct, and mostly undone.
If you've run a segmentation project that stalled — or one that shipped — I'd like to hear where it got stuck.