Network segmentation is the practice of dividing a network into separate zones and controlling what may pass between them, so that a compromise in one place cannot spread freely. Micro-segmentation applies the same idea at a much finer grain, down to individual workloads or applications. The hard part is rarely the technology. It is making a change that restricts traffic without cutting off a system someone depends on. This guide covers how to start network segmentation step by step with that risk in mind, based on guidance from CISA and NIST.

What segmentation does

CISA describes segmentation as a physical or virtual architectural approach that divides a network into multiple segments, each acting as its own subnetwork with additional security and control. It limits access to devices, data, and applications and restricts communication between networks. CISA's January 2022 infographic, Layering Network Security Through Segmentation, lists what happens without it: with unsegmented IT and OT networks, OT is exposed to vulnerabilities in connected IT networks, threat actors move laterally more easily, and detecting them is harder because of the volume of traffic.

Macro-segmentation versus micro-segmentation

  • Macro-segmentation: the traditional approach of a few large zones such as users, servers, DMZ, development, and production. CISA says it gives high-level control over traffic between areas of the network and is simpler to manage
  • Micro-segmentation: divides those boundaries further, so that for example servers communicate only with the servers they need for their business function. CISA notes microsegments can be defined dynamically or statically, and may subdivide or cross former trust zones
  • Identity- or workload-based: NIST SP 800-215 describes policies based on service or application identities instead of IP addresses, which makes them independent of where the workload runs. It requires every application or service to have a unique, verifiable identity

Neither replaces the other. CISA states that microsegmentation does not replace defense-in-depth or the management of data, assets, configuration, and vulnerabilities; it augments them. A common path, and the one in CISA's first example scenario, is to get macro-segmentation in order first and then add microsegments around the highest-value systems. NIST SP 800-215 names two difficulties of the traditional approach: mapping application security needs onto network segments, and keeping that mapping in sync as workloads move.

INFOGRAPHIC
Segmentation granularity: more control, more work
Flat network
any host can reach any host
Macro: large zones
users, servers, DMZ, OT
Per-application zones
web, app, database apart
Micro: per workload
talk only as the function needs
Identity-based policy
not tied to IP or location
Easy to spread, little effortHard to spread, more effort

Why segmentation projects cause outages

Segmentation projects tend to cause outages for predictable reasons. NIST SP 800-207 notes that few enterprise policy sets are complete in their first iteration, so important accounts such as administrators may be denied access to resources they need. CISA advises building in opportunities to revert updated policies. The usual causes are below.

  • Hidden dependencies: a backup job, a monitoring probe, a DNS or NTP lookup, or a batch process nobody remembered
  • Enforcing too early: rules written from a diagram instead of from observed traffic
  • No communication: system owners and users first hear about it when something breaks
  • No way back: no tested rollback or emergency exception path

A phased approach that avoids outages

CISA's Microsegmentation in Zero Trust Part One (July 2025) recommends a phased approach, one application, workflow, asset, or environment at a time, with four phases that are repeated rather than done once.

  • 1. Identify candidate resources: list applications, workflows, data, and environments, then prioritize by criticality and ease. CISA suggests the first round can favor ease of transition, and later rounds the high-value assets
  • 2. Identify dependencies: for each candidate, find everything it needs and everything that needs it. Start from observed communications, then validate the list is complete with stakeholders
  • 3. Determine the policy: choose the segmentation option and the rules that let the business function work, with users involved
  • 4. Test and deploy: run the policy in a permissive mode that flags violations to reveal missed dependencies, then enforce with monitoring in place, documentation of the change, and a feedback channel
INFOGRAPHIC
CISA's repeatable four-phase cycle
1
Pick a candidate
one app or environment
2
Map dependencies
start from observed traffic
3
Set the policy
involve the users
4
Run permissive
flag violations, no blocking
5
Enforce and monitor
feedback channel and rollback

NIST SP 800-207 gives the same advice for zero trust: operate in an observation and monitoring mode first, because few policy sets are complete at the start. A reporting-only mode lets you compare logs of actual connections with the drafted policy and learn baseline communication patterns. CISA's first example scenario did this: new policies ran in a permissive mode that alerted on violations, were honed over time, and then moved to production, with a pilot group of users testing each resource.

INFOGRAPHIC
What to segment first, and what to leave for later

Leave for later

  • Shared services everything usesmany dependents, big blast
  • Systems nobody ownsno one can confirm dependencies
  • OT and agentless legacynetwork-based, plan carefully

Good early candidates

  • New apps or cloud movesbuild it in from the start
  • Easy-to-transition systemsCISA's suggestion for round one
  • Clearly owned systemsowner can confirm dependencies

Choosing where to enforce

CISA's table of segmentation types groups the ways to enforce policy, and each has trade-offs.

  • Network-based (firewalls, routers, switches): reuses existing infrastructure and works where agents cannot be installed, but has more limited visibility into endpoints, identities, and applications, and a full transition can be hard to maintain
  • Endpoint or host-based (agents, host firewalls): integrates better with identities and applications and follows roaming devices, but needs an agent on every endpoint and may not work with OT, IoT, or legacy devices
  • Hypervisor, container, and cloud-native: fits virtualized, container, and cloud estates, but is often specific to a platform, which limits portability
INFOGRAPHIC
Segmentation policy can be enforced in several places
Segmentation policy
most enterprises combine several
Network
firewalls, routers, switches
Endpoint
agents and host firewalls
Hypervisor / container
tied to the platform
Cloud-native
the cloud provider's controls

CISA expects most enterprises to combine several of these rather than use one throughout. NIST SP 800-207 adds that stateless firewalls can implement some features of micro-segmentation, but the administration cost and the difficulty of adapting to change make that a very poor choice.

Special cases: OT, legacy systems, and user devices

  • OT, IoT, and legacy systems: CISA says agent-based tools may not be available, so network-based segmentation is needed, and these systems often have limited protections, which raises the need to segment them. A common first step is to separate OT from IT and permit only the traffic needed for business functions. See Zero Trust for OT: Adapting It Without Disrupting the Plant
  • Roaming user devices: network-based segmentation works on-premises, but remote devices may need agent-based or application-based approaches
  • Remote access: CISA's infographic recommends allowing only specific users and devices to connect remotely into the DMZ to reach high-value servers
  • Cloud migrations: CISA recommends using a migration as the chance to build segmentation in with a cloud-native approach instead of a lift and shift

Common mistakes

  • Enforcing before observing: write rules from observed traffic and run them in a permissive mode first
  • Starting with the whole network: do one application or environment at a time. CISA says the phases are repeated
  • Jumping straight to micro-segments: set the main zones first, such as users, servers, DMZ, management, and OT
  • Segments with no monitoring: CISA advises understanding how an adversary could bypass the segmentation so the bypass can be monitored or blocked
  • Forgetting the management network and admin paths: CISA notes the management network often holds a particularly trusted position, so it should be under stringent controls and monitoring
  • Treating it as a one-time project: CISA says the changeover is not a single transition; revalidate when applications, environments, or threats change
  • No rollback plan: know who can revert a rule, how long it takes, and how, before enforcement starts

Start today

  • Draw the real map: name the five systems whose compromise would hurt most and who talks to them
  • Turn on flow logging at the firewall or key servers to see who really talks to whom before writing a single deny rule
  • Check the zones that should be separate: guest or IoT, management, backup, servers, users, and OT, and whether rules control traffic between them
  • Pick one application and run the four phases on it, in a permissive mode, with a pilot group of users
  • Write the rollback: who can revert a rule, how fast, and how
  • Rehearse in a lab. See Network and Cyber Security Simulators: Types and Uses

To see where segmentation fits in your zero trust plan, read Zero Trust Architecture: Components and Roadmap and try the self-assessment. For the role firewalls play as enforcement points, see NGFW vs UTM vs WAF: What Each One Protects.

For OT systems, zones and conduits have a standard to refer to; see IEC 62443 Explained: Industrial Control System Security.

In Kubernetes, Pod-level network segmentation is done with NetworkPolicy; see the steps in the article on container and Kubernetes security.

References and further reading