Microsegmentation divides a network or environment into very small zones, often one workload or a small group, each guarded by its own access controls, so a compromised system cannot freely reach the others. NIST SP 800-207 describes it as one of three approaches to building a zero trust architecture.
What does NIST say?
In SP 800-207, the micro-segmentation approach places individual or small groups of resources on a unique network segment protected by a gateway security component. The gateway might be an intelligent switch or router, a next-generation firewall or a special-purpose device. NIST also describes host-based micro-segmentation, using software agents or firewalls on the endpoint. Gateways grant access dynamically to individual requests from a client, asset or service.
Two cautions stand out. The approach needs an identity governance program to work fully, so you must know who and what should be talking. And NIST says it is possible to build some micro-segmentation with simpler gateways or even stateless firewalls, but calls that a very poor choice because of administration cost and how hard it is to adapt to change.
How is it different from ordinary segmentation?
Traditional segmentation splits a network into a few big zones: users, servers, guest Wi-Fi. Traffic inside a zone moves freely. Microsegmentation shrinks the zone to the workload, so the default between two servers in the same rack is also "no."
NIST control SC-7(5) states the principle: deny network communications traffic by default and allow it by exception, which ensures only essential and approved connections exist. It applies to inbound and outbound traffic.
Why does it matter?
Constructed example. An attacker lands on a marketing web server through a vulnerable plugin. In a flat network, that server can talk to the database host with customer data, the build server and the domain controller. The attacker maps all three in minutes. With microsegmentation, the web server may reach only the application tier on one port, and nothing else. The initial flaw still happened. The attacker is boxed in.
The same logic applies in container clusters. NIST SP 800-190 observes that by default in most container runtimes, containers can reach each other and the host over the network, and that poorly separated traffic is a named orchestrator risk.
Why is it hard?
You cannot write allow rules for flows you do not understand. Dependencies hide in batch jobs, backups, monitoring agents and rarely used admin paths. Rules also rot: a team opens a port for an incident and never closes it.
So start with visibility and enforce gradually.
How to start
- Map the flows for one application: who talks to whom, on which port, how often.
- Pick a small, high-value target, such as the payment system or the domain controllers.
- Write allow rules for the observed, legitimate flows, in monitor-only mode first.
- Review blocked-would-have-been logs for a few weeks, fix the rules, then enforce.
- Add identity: tie rules to workload or service identity where possible, not only IP addresses.
- Lock down management paths, such as admin ports and backup agents, which attackers like.
- Set an owner and a review date for every rule, and remove rules with no traffic.
- Test by simulating a compromised host and confirming it cannot reach what it should not.
What does a bad first project look like?
Constructed example. A team decides to segment the whole data center in one quarter, imports six months of flow logs, and generates four thousand rules automatically. On enforcement day, the nightly backup fails, a payroll job stalls and the monitoring system goes blind. The change is rolled back and the project loses sponsorship.
The better pattern is boring: one application, one owner, one rule set, measured results, then the next. Each success also teaches the team which flows hide in the corners of your environment.
What is the trade-off?
More rules mean more things to break. Segmentation done carelessly causes outages and then gets switched off. Expect a slow start and measure progress by flows covered, not by the number of rules written.
Quick check
Is microsegmentation the same as zero trust?
No. NIST lists it as one approach to zero trust, alongside identity governance and network-based approaches. A full design usually uses elements of all three.
Do I need special products?
Not necessarily. Cloud security groups, host firewalls and Kubernetes network policies can all enforce fine-grained rules. NIST warns that managing it with weak tools becomes costly.
Sources
- NIST SP 800-207, Zero Trust Architecture
- NIST SP 800-53 Rev 5 control catalog, OSCAL (SC-7, SC-7(5))
- NIST SP 800-190, Application Container Security Guide
Last reviewed: 18 October 2026.
