Official intent
Use logical segmentation to contain a compromised account or device and limit adversary lateral movement. The official source remains authoritative.
Read the official campaign ↗A flat network turns one compromised laptop into access to everything. Logical segmentation — VLANs, host firewalls, identity-based access, and separated management planes — breaks the network into zones so an intruder who lands in one place cannot freely reach the rest. Start by isolating the crown jewels and the riskiest devices.
Who this applies to: Any organization with more than a single flat network, and every organization handling controlled information. The design scales down: three zones done properly beats twelve on a diagram.
Why it matters
Adversaries rarely land where they want to end up; they land somewhere and move. Segmentation raises the cost of that movement, buys your defenders time, and shrinks the blast radius of any single compromise. It is also foundational to protecting CUI and to a zero-trust direction of travel.
Risks this reduces
- Lateral movement from one compromised laptop to the rest of the estate
- Direct reachability of management interfaces from the user network
- Uncontrolled exposure of systems that hold controlled or proprietary data
- High-risk devices — legacy, IoT, guest — sharing a network with everything else
Who owns it
Network administrator
IT leader, Security lead, MSP
High
Medium to high
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: IT-02 — Asset inventory
- A current inventory that shows what is on the network and where sensitive data lives
- Documented knowledge of which systems legitimately need to talk to each other
- Change control that can stage firewall and routing changes safely
Action timeline
- Identify your most sensitive systems and where CUI lives
- Confirm management interfaces are off the user network
- Confirm management interfaces are unreachable from the standard user network and fix any that are
- Move high-risk devices — legacy systems, IoT, guest Wi-Fi — off the general user segment
- Define zones by function and trust level
- Isolate high-risk devices (legacy, IoT, guest) onto their own segments
- Enforce controls between zones with default-deny
- Add identity-aware access to sensitive systems
- Monitor and log east-west traffic between zones
- Test that a device in one zone cannot reach another
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Map where sensitive data and critical systems live and who legitimately needs to reach them.
- Define network zones by function and trust — user, server, management, CUI, guest, and high-risk devices.
- Enforce controls between zones (firewalls, ACLs, host firewalls) with a default-deny posture.
- Move privileged management traffic to a separate, tightly controlled plane.
- Log and monitor traffic that crosses zone boundaries so unexpected movement is visible.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
One flat network; anything can reach anything.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A zone design exists on paper with the intended boundaries and the traffic that should cross them.
Is the intent written down, with a named owner and a scope? - Configured
VLANs and firewall rules exist for the designed zones, but not everything has been moved into them.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Systems sit in their intended zones, inter-zone rules are default-deny, and management traffic is on a separate plane.
Does it cover everything in scope, with the exceptions written down? - Measured
Inter-zone traffic is logged and reviewed, and segmentation is periodically tested rather than assumed.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
The zone model is owned, reviewed, and reconciled against the inventory; broad permit rules are treated as exceptions with expiry dates.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- From a standard user device, attempt to reach a server-zone or management interface — it must be blocked.
- Confirm CUI systems are not directly reachable from the general user or guest network.
- Review firewall/ACL rules for any “any-any” permit that undoes the segmentation.
Evidence to retain
Network segmentation design and zone policy
Firewall/ACL rule exports enforcing inter-zone controls
Logs of inter-zone traffic and investigated anomalies
Segmentation test results showing blocked cross-zone access
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Any-any rules | Firewall or ACL rules permitting unrestricted traffic between zones. | Zero outside a dated, owned exception. |
| Segmentation test result | Blocked cross-zone attempts ÷ attempts in the periodic test. | 100% of the paths the design says should be blocked. |
| Assets in the correct zone | Inventory rows whose network placement matches the zone design. | Above 95%, with the remainder investigated. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
VLANs created but left routable to each other, management interfaces reachable from user Wi-Fi, and a broad “any-any” rule that quietly re-flattens the network. Segments without enforced boundaries are just labels.
Two sized paths
Three zones is a real improvement: users, servers and sensitive data, and everything untrusted (guest, IoT, legacy). Use the firewall and switches you already own, put management interfaces somewhere users cannot reach, and test it by trying to reach a server from a laptop. Micro-segmentation is not the small-business answer.
Drive toward identity-aware, least-privilege access between zones with continuous evaluation rather than static rules, monitor east-west traffic, and reconcile the zone model against the asset inventory automatically so drift surfaces as an event.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Segmentation changes break undocumented dependencies more often than anything else on this list. Log first in permit mode to discover real traffic, then enforce; stage by zone; keep a rollback; and schedule cutovers where an outage is survivable.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The CMMC practices inherit the 800-171 requirement text directly.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: Secure network architecture and segmentation by trust level describe the same design activity.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.1.3CUI flow controlPartial implementation supportModerate
Why: Network zones with deny-by-default paths between them are a primary mechanism for enforcing where CUI may travel: segmentation makes the approved flows the only flows the network permits, which is the enforcement half of this requirement.
What this does not claim: Flow authorization also runs through channels segmentation never inspects — email, cloud sharing, removable media, application-layer transfers within a permitted network path. And the requirement presumes documented approved authorizations to enforce; segmentation implements a flow decision but does not itself produce the approval record an assessor will ask for.
Review status: Pending NIST SME review.
Open the 3.1.3 page →3.12.4System security planContextual relationshipModerate
Why: Segmentation is where the boundary the SSP describes becomes physical: zone design, deny-by-default edges, and documented cross-zone paths are the material behind the plan's boundary and interconnection sections. A segmented environment gives the plan defensible edges to draw.
What this does not claim: The practice shapes what the SSP describes; it does not draft, maintain, or update the plan, which remains deliberate governance work with an owner and a cadence. Nor does segmentation settle boundary scope by itself — CUI flow analysis, external-service relationships, and enclave decisions are inputs the practice does not provide.
Review status: Pending NIST SME review.
Open the 3.12.4 page →3.13.1Boundary communications protectionDirect implementation supportHigh
Why: Logical segmentation's core work — defining zones, placing enforcement points between them, and deciding what crosses — is boundary protection at the key internal boundaries this requirement names. The practice builds the monitored chokepoints the requirement expects communications to pass through.
What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. The requirement also covers the external boundary — internet edge, partner connections — and the monitoring of communications, not only their restriction; an assessor evaluates both halves across the full defined boundary, not just the internal zones the segmentation effort drew.
Review status: Technical review complete.
Open the 3.13.1 page →3.13.5Public-access subnetworksDirect implementation supportHigh
Why: Placing publicly accessible components in their own subnetwork, separated from internal networks, is a specific application of the zoning this practice implements — a DMZ is a segmentation zone with a particular job.
What this does not claim: Supports implementation of the requirement rather than establishing it single-handedly. The requirement holds only when every publicly accessible component is separated: one web server, VPN appliance, or vendor portal left on the internal network reopens the gap however well the rest of the estate is zoned, and discovering everything that is publicly reachable is its own work the zone design does not do.
Review status: Technical review complete.
Open the 3.13.5 page →3.13.6Deny-by-default network trafficPartial implementation supportModerate
Why: Deny-by-default is the traffic policy segmentation zones are meant to run on: the practice's enforcement points between zones are where a default-deny stance gets implemented, and drawing the zones forces the traffic analysis that makes permit-by-exception writable at all.
What this does not claim: May partially address the requirement — deny-by-default is a design decision the segmentation effort enables, not one it settles. Zone boundaries deployed with broad allow rules advance the practice while leaving this requirement untouched, and the requirement also reaches the external boundary and host-level filtering beyond the internal zone map.
Review status: Pending NIST SME review.
Open the 3.13.6 page →NIST SP 800-171 Rev. 3
03.01.03Information Flow EnforcementPartial implementation supportModerate
Why: Network segmentation is a flow-enforcement mechanism: zone boundaries with deny-by-default policy are one of the concrete ways approved CUI flows get enforced and unapproved ones get blocked.
What this does not claim: Segmentation enforces flows at the network layer only, and only where zones were drawn with CUI in mind. Application-layer flows — email, cloud sharing, SaaS integrations — cross zones legitimately and need flow policy of their own, and the approved-authorization side of the requirement (documenting which CUI flows are approved at all) is analysis the practice does not perform.
Review status: Pending NIST SME review.
Open the 03.01.03 page →03.13.01Boundary ProtectionDirect implementation supportHigh
Why: Zone design with default-deny boundaries, reviewed inter-zone rules, and a separated management plane is monitored-and-constrained communication at key internal boundaries — the core of this requirement — and Rev. 3's consolidated scope (public-access subnetworks, separation of management functionality) matches the practice's zone model closely.
What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. The requirement also governs the external boundary — managed interfaces to the internet and to external systems arranged per an organizational security architecture — which internal segmentation work touches only partly, and its monitoring half means watching what crosses the boundaries, not merely permitting or denying it. Split-tunneling prevention, now folded into this requirement, is remote-access configuration the zone model does not reach.
Review status: Technical review complete.
Open the 03.13.01 page →03.13.06Network Communications — Deny by Default, Allow by ExceptionPartial implementation supportHigh
Why: The practice's deployed state is inter-zone default-deny: traffic between zones is refused unless a reviewed rule permits it, which is precisely the deny-all, permit-by-exception posture this requirement names.
What this does not claim: The requirement applies to network communications traffic generally — including the external perimeter and egress — while the practice enforces the posture between internal zones. Hosts within a single zone still communicate freely unless host-level policy extends the model, and every permit rule needs a recorded justification for the by-exception framing to survive an assessor's sampling.
Review status: Pending NIST SME review.
Open the 03.13.06 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |