A flat network — one where most systems can reach most other systems — is the operational starting point for the majority of enterprises. It happened organically: IT teams added VLANs for management purposes, not security purposes, and the security controls that were supposed to provide interior protection never got deployed or weren't maintained.
Moving from this starting point to meaningful segmentation is a multi-month project that requires careful planning. Done wrong, it breaks applications and erodes organizational trust in the security team. Done right, it dramatically reduces lateral movement risk while maintaining operational continuity.
This is the practical roadmap.
Phase 1: Inventory and Discovery (Weeks 1-4)
You can't segment what you haven't mapped. Before writing a single firewall rule, you need a comprehensive picture of your environment.
Asset Discovery
Start with what you know: CMDB data, Active Directory, vulnerability scanner output. Layer on what the network knows: DHCP lease history, ARP tables, and most importantly, flow data. Flow data surfaces systems that exist on the network but aren't in any authoritative inventory — the forgotten test server, the unmanaged IoT device, the old workstation that someone left plugged in.
The output of this phase should be a complete asset list with:
- IP address and hostname
- System type (server, workstation, network device, IoT/OT)
- Business function/application ownership
- Current VLAN/subnet placement
- Security posture status (managed, unmanaged, unknown)
Communication Mapping
Enable flow data collection on your core/distribution switching infrastructure if it isn't already in place. Let it run for at least two weeks — long enough to capture a full weekly cycle and any recurring batch processes.
From the flow data, build a communication matrix: which systems talk to which, over what protocols and ports. Pay particular attention to:
- Systems that communicate broadly across subnets (potential pivots or administrators)
- Systems with unexpected external communication
- Systems that initiate connections to unusual combinations of internal destinations (potential scanning behavior)
Phase 2: Define the Target Architecture (Weeks 3-6)
With a clear picture of the current state, design the target segmented architecture.
Segment Design Principles
Group by function, not by location. The most meaningful segments align with business function and risk tier: production application servers, development, user workstations, management infrastructure, IoT/OT. Grouping by switch port or physical location produces segments that don't mean anything from a trust perspective.
Define trust tiers. Not all segments need equal restriction. A common framework:
- Tier 0: Domain controllers, PKI, privileged access workstations — maximum restriction, minimal trust
- Tier 1: Production application servers — permit specific flows, deny everything else
- Tier 2: Internal services (file shares, email, print) — permit business-required access
- Tier 3: User workstations — permit outbound to known services, deny lateral workstation-to-workstation
- Tier 4: IoT/OT, guest, unmanaged — maximum restriction, no lateral access
Design for what you'll enforce. A beautifully designed segmentation architecture that requires firewall rules on every switch port will never get implemented. Design a target state that's achievable with your actual enforcement capabilities — typically L3 ACLs, VLAN-based segmentation, or a network security platform.
Policy Design from Flow Data
Use the communication matrix from Phase 1 to define the explicit allow list for each segment boundary. Every communication path that's required for business operations becomes an explicit permit rule. Everything else is denied.
This is where many segmentation projects encounter surprises: dependencies that weren't documented, legacy integrations that are still active, infrastructure communication requirements that weren't in the architecture docs. The flow data is the source of truth — trust it over the documentation.
Phase 3: Pilot Implementation (Weeks 6-10)
Don't implement segmentation across the entire environment simultaneously. Start with a bounded pilot:
- Choose a segment with relatively well-understood communication requirements (often: the DMZ, a development environment, or a specific application cluster)
- Implement the segmentation controls in audit mode (log what would be blocked)
- Run the audit for 2-3 weeks, reviewing logged "would-block" events
- Add missing allow rules for legitimate communication you missed
- Switch to enforcement mode
- Monitor for 1-2 weeks in enforcement mode before declaring success
What the Pilot Teaches
The pilot will reliably reveal:
- Forgotten application dependencies that weren't in any documentation
- Legacy integrations from decommissioned applications that are still active
- Infrastructure services (DNS, NTP, certificate revocation) that aren't obvious in application docs
- Monitoring tools that use network protocols not everyone remembered
- Backup agents with unconventional communication patterns
Each discovery is an input to improve the policy before scaling to higher-stakes production environments.
Phase 4: Rollout and Steady State (Months 3-12)
Scale the segmentation implementation from the pilot to the full environment, starting with lower-risk segments and working toward higher-risk ones. Each segment follows the same audit-then-enforce pattern from the pilot.
The timeline for a complete rollout depends on environment complexity, but most organizations can complete the core segmentation of production infrastructure in 6-12 months.
Maintaining Segmentation Over Time
Segmentation isn't a project you complete — it's a state you maintain. Applications change, new systems are deployed, and communication requirements evolve. The segmentation policy needs to evolve with them.
The keys to maintaining segmentation health:
Continuous flow monitoring. Ongoing flow collection surfaces communication that doesn't match the current policy — either legitimate new requirements that need policy updates, or unauthorized lateral movement that needs investigation.
Change process integration. New systems and application changes should trigger a segmentation policy review as part of the change approval process.
Regular policy review. Quarterly or semi-annual review of active segmentation rules, retiring rules for decommissioned systems and communication paths.
FlowSight supports the full segmentation lifecycle: initial communication mapping from flow data, ongoing monitoring in audit mode, continuous validation after enforcement, and alerting on policy deviations. The flow data that drives the initial policy design continues to drive the validation that keeps the policy current.
The Long View
Segmentation is one of the most durable security investments an organization can make. It doesn't require constant signature updates, it doesn't have alert fatigue problems, and it doesn't go obsolete when the threat landscape shifts. A network where lateral movement is genuinely constrained is a network where breaches are contained rather than catastrophic.
The path from flat to segmented is a marathon, not a sprint. Plan it carefully, start with data, validate before enforcing, and maintain it continuously. The security posture at the end of the journey is worth the effort.