At A Glance
- Legacy microsegmentation requires mapping every connection before you deploy a single segment. An allow-by-default network turns any gap in that map into an outage.
- 99% of security leaders are implementing or planning microsegmentation, but over 90% have protected less than 80% of their critical systems.
- NetFoundry’s dark-by-default model removes the mapping prerequisite entirely: workloads are unreachable until explicitly authorized, so you can segment one workload today and expand from there.
- Access changes become policy updates, not firewall tickets, with no change windows and no accumulating rule sprawl.
Microsegmentation earned its place on every security roadmap for a good reason. Flat networks let attackers move laterally, one compromised workload becomes a beachhead for the entire environment, and auditors increasingly expect least-privilege boundaries around critical systems. The goal has never been controversial: a 2025 Omdia survey of security decision-makers found that 99% of security leaders are implementing or planning microsegmentation. The execution tells a different story. In that same survey, more than 90% of organizations had protected fewer than 80% of their critical systems, and nearly half had experienced lateral movement within the previous twelve months. Nearly everyone wants microsegmentation, and almost nobody finishes it. The problem lies in how legacy approaches force you to begin.
The Legacy Approach: Map Everything Before You Segment Anything
Traditional microsegmentation, whether built on internal firewalls, VLANs and ACLs, or agent-based enforcement layered onto an allow-by-default network, carries a brutal prerequisite. Before you deploy a single segment, you must understand every connection that crosses the boundary you intend to draw, including every application dependency, every service-to-service call, every backup job, every monitoring agent, and every integration some team stood up years ago and never documented.
The underlying network permits everything by default. The moment you insert a segment, you invert that posture for the traffic crossing it, and anything you failed to discover breaks. Miss the nightly replication job between the database tier and the disaster recovery site, and you find out at 2 a.m. Miss the licensing server callback, and the ERP system stops working during quarter close. On an allow-by-default network, an incomplete map produces an outage, not a partially segmented environment.
So organizations respond rationally. They launch discovery projects, deploy flow-collection tools, gather NetFlow and packet captures for months, interview application owners, and build dependency maps that sprawl across conference room whiteboards. The map is obsolete before anyone finishes drawing it, because applications change while the analysis runs. Teams end up chasing a moving target, and the segmentation deployment date slides quarter after quarter. Many projects never make it past the mapping phase at all, because the perceived risk of enforcement outweighs the appetite to flip the switch.
The Ongoing Cost of Firewall Change Requests
Suppose the project survives discovery and the segments go live. Now the real long-term burden begins: keeping the rules current in an environment that never stops changing.
Every new application, every migrated workload, every added integration, and every decommissioned server translates into a firewall change request. Each request enters a queue, waits for review, waits for a change window, and gets implemented by a team that has no context on the application it affects. A routine access change takes days or weeks. Multiply that across hundreds of applications and the rule base grows into the thousands, and because nobody can say with confidence what a given rule still protects, nobody dares delete anything. The rule set only grows, and every manual change carries risk of its own: Gartner predicted that through 2025, policy misconfigurations, not firewall flaws, would remain the cause of 99% of firewall breaches and bypasses. Audits take longer, troubleshooting takes longer, and the segmentation that was supposed to reduce risk becomes a source of operational drag and configuration drift.
The pattern repeats across industries: enormous upfront planning, fragile go-live, and a permanent tax on every change afterward. It’s the inevitable consequence of building least privilege on top of a network that trusts everything by default.
The NetFoundry Approach: Dark by Default
NetFoundry’s Zero Trust microsegmentation inverts the starting point. Instead of an open network you must progressively close, you get a network that is dark by default: no workload is reachable by anything until an explicit policy authorizes the connection. Workloads expose no open inbound ports, listen on nothing, and remain invisible to port scans and unauthorized peers. Deny-all is simply the native state of the fabric.
That single inversion eliminates the mapping prerequisite. You no longer need to understand every flow in the environment before you protect anything, because deploying a segment cannot break traffic that was never implicitly allowed in the first place. You can start with exactly one workload: put it on the NetFoundry fabric, define the identities and services authorized to reach it, and it is fully segmented today, not after a six-month discovery effort. The rest of the environment continues operating exactly as it did. When you are ready, you bring the next workload onto the fabric, and the next, expanding least privilege at whatever pace your teams and your change tolerance allow.
Granting Access Is Now Just a Policy Update
Change management transforms just as dramatically. In the NetFoundry model, granting or revoking access is a policy change: you associate an identity with a service, and the authorization takes effect across the fabric effectively instantly. There are no firewall rules to write, no ACLs to reconcile, no change windows to schedule, and no tickets aging in a queue. When an application team needs a new integration, the person who understands the application grants precisely that access in minutes, scoped to identities and services rather than IP addresses that will change the next time the workload moves.
Revocation works the same way. Decommission an application or offboard a partner, and removing the policy removes the access everywhere at once, with no orphaned rules left behind to accumulate as risk. The policy set stays legible because every entry maps to a real identity and a real service, which means audits become a matter of reading intent rather than reverse-engineering thousands of five-tuple rules.
How to Start Segmenting Without the Mapping Marathon
The practical difference shows up in the first week. A legacy project spends that week scoping a discovery tool deployment. A NetFoundry project spends it putting a real workload (a crown-jewel database, an exposed admin interface, a sensitive API) behind real Zero Trust policy and demonstrating value immediately. Each workload you add compounds the coverage, and none of it requires touching a firewall.
Microsegmentation was always the right goal. It simply needed a network designed for it: dark by default, governed by identity, and changeable at the speed of a policy update. NetFoundry’s approach to microsegmentation makes this the starting point, not the finish line of a discovery project.
Ready to segment your most critical workloads without a discovery marathon or a single firewall change? Talk to us about where to start.
Frequently Asked Questions
What is dark-by-default microsegmentation?
Dark-by-default microsegmentation means no workload can be reached by any other system until an explicit policy authorizes the connection. NetFoundry builds this in as the network’s native state, rather than requiring a team to close off an already-open network segment by segment.
Do I need to map my entire network before I can start microsegmenting?
No, not with a dark-by-default architecture. Traditional microsegmentation requires discovering every connection before you deploy, because the underlying network is open by default and any missed connection breaks when you close it off. NetFoundry doesn’t have that requirement: since nothing is reachable until authorized, you can segment a single workload immediately without first mapping everything around it.
How is this different from firewall-based or agent-based microsegmentation?
Firewall-based and agent-based approaches still start from an allow-by-default network, so every access change is a firewall rule or ACL update that has to be written, reviewed, and scheduled through a change window. NetFoundry treats access as an identity-based policy: granting or revoking it takes effect across the fabric in minutes, with no rule sprawl to manage over time.
Can I roll this out gradually, or do I need to migrate everything at once?
You can start with one workload. Because deploying a new segment can’t break traffic that was never implicitly allowed in the first place, there’s no all-or-nothing cutover. Teams typically bring workloads onto the fabric one at a time, starting with their highest-priority systems.
