In three of the five microsegmentation projects that I have audited over the past year and a half, within the created segments there was the “permit any any” rule. Formally, there is a segmentation of the network, in the report for the leadership, the architecture of zero trust is beautifully drawn - and the attacker moves horizontally without a single obstacle. In 2025, CISA released a separate document “Microsegmentation in Zero Trust Part One”, which directly says: policy errors at the design stage reset all investments in the Zero Trust architecture. With an average data breach cost of $4.88 million (IBM Cost of a Data Breach Report 2024), a significant proportion of damage falls on organizations where the horizontal movement of the attacker has not been stopped by the network’s microsegmentation.
Why Classic Network Segment Doesn't Stop the Elaboration
Traditional network segmentation is built on VLAN and ACL. To separate broadcast domains and control of forward-south traffic - what goes from client to server through the perimeter - this is enough. The problem is another: the main volume of traffic of modern data centers and cloud environments - east-west, between workloads inside the perimeter. According to Palo Alto Networks, east-west communications make up most of the traffic of data centers, and perimeter means of protection simply do not see this traffic. Everything inside the perimeter is implicitly considered trusted.
The attacker, which has received initial access through compromised accounting data (T1078, Valid Accounts), begins exploration: detection of network services (T1046), search for neighboring systems (T1018), analysis of network connections (T1049) and network configurations (T1016) Then - horizontal movement through Remote Services (T1021) and, if you are lucky, Network Boundary Bridging (T1599) to go beyond the current network segment. The classic VLAN-segmentation will not interfere with any of these steps if the attacker is already inside the “trusted” perimeter.
Reassemble the VLAN structure under the new requirements is a task that draws a change in the physical or logical network architecture. According to Palo Alto Networks, the re-architecture of VLAN and the reconfiguration of VLAN under security requirements are a long and expensive process. That is why the microssegmentation of the Zero Trust network is not “VLAN smaller”, but a fundamentally different approach to controlling east-west traffic, built on software-defined perimeters around each workload.
Three Approaches to Network Microsegmentation
According to the Palo Alto Networks classification, microsegmental controls are divided into three categories. The choice of approach determines the architecture, budget and timing of implementation - the decision must be made before the purchase of specific microsegmental tools.
Agent Decisions
The software agent is placed directly on the workload - host, VM, container - and provides granular insulation at the host level. The agent can use the built-in airfield (iptables, Windows Firewall) or its own enforcement mechanism. Policies are built on the basis of the identity of the workload and its attributes, not IP addresses. For dynamic environments, this is fundamental.
The main advantage is complete independence from the network infrastructure. The agent works the same in an on-premise center, a public cloud and a hybrid environment. The visibility of east-west traffic is complete, including communication between processes on one host. The reverse side - the agent needs to be put, configured and updated on each host. In environments with thousands of nodes, this is a tangible operating load, and chaos will begin without mature processes of configuration management.
Network (SDN) Solutions
Control goes through the software-definable network: virtual switches, overlay networks, distributed firewalls at the hypervisor level. Politicians are used in a network factory without installing agents on workloads. In the case of VMware NSX, each virtual port receives its own Firewall, which inspects east-west traffic before it gets into the physical network.
Plus - centralized management and lack of an agency load. Minus - binding to the vendor of a network platform and a headache in heterogeneous environments, where several hypervisors, bare-metal servers and container orchestrators coexist.
Cloud Native Controls
Built-in mechanisms of cloud providers: AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall. Manage through the provider’s API, integration “out of the box”.
Plus - zero costs for additional tools. Minus – works only inside a particular cloud, does not cover on-premise or multi-cloud scenarios.

For most enterprise environments with hybrid infrastructure, the optimal combination is optimal: an agent solution for cross-platform enforcement plus cloud-native controls for cloud-native workloads. In the coming years, most enterprises introducing the Zero Trust will use several segmentation methods at the same time – and this is not redundancy, but the reality of the hybrid world.
Microsegmental Tools: Comparison for Your Infrastructure
Choosing a specific product is one of the first questions asked by CISO or IT director. Below is a comparison of the solutions I worked with in projects on Zero Trust transformation.

Illumio and Akamai Guardiore consistently receive high scores on Gartner Peer Insights and PeersPopot - an agent-generating approach for network insulation tasks of workloads really matured.
Tools for the Russian market
For subjects of critical information infrastructure and organizations under 187-FZ and the requirements of FSTEC the choice of microsegmental tools is limited. By Order FSTEC No76, the means of information protection must correspond to a certain class and pass certification. According to the Order of FSTEC No9 of 09.02.2016, firewalls are classified by types (A - network level, B - logical network boundary, B - level of the node, G - level of the web server, D - industrial), and the required level of trust (OUD) depends on the class of protection of a particular ME.
In Russian realities for microsegmental tasks apply:
• UserGate NGFW - Certified by MEE with L7-filtration, applicable for segmentation between zones and control of east-west at the subnet level
• PT NGFW (Positive Technologies) - NGFW with integration into the PT ecosystem, including MaxPatrol SIEM to correlate segmentation events with other sources
• Network policies Kubernetes (NetworkPolicy) - for container media; do not require separate certification if perimeter protection is certified
• RUNOS and Astra Infrastructure Cloud - SDN-solutions for the Russian market, but their capabilities of microsegmentation at the enterprise level are still noticeably inferior to foreign counterparts
I will honestly say: none of the Russian decisions today does not give an agent microsegmentation of the level of Illumio or Guardicore. For CII subjects, this means the need to combine certified IE with manual workout policies - it is longer, more difficult, but there are no other options yet.
Formation of policies: from monitoring to enforcement
The most responsible phase. A typical error is to immediately enable the lock. The right approach is three consecutive stages.
Stage 1 - Detection (2-4 weeks). The tool works in the monitoring mode and passively collects data on real communications. No traffic is blocked. At the output - a map of all east-west streams and automatically generated recommendations on politicians.
Stage 2 - Policy testing (2-4 weeks). Rules are created on the basis of the collected data. The tool shows what traffic would be blocked when activated, but actually misses everything. The goal is to identify false positives and undocumented relationships between services. It is here that the same “and we forgot that the backup agent goes to all servers on the port 9090.”
Stage 3 - Enforcement (stepped). Policies are transferred to blocking mode from the least critical segments: test environments, development environments. Critical production systems - in the last, after full verification.
Po NIST SP 800-53AC-1 (Access Control) requires the development of policies that define goals, roles and responsibility in access management. For microsegmentation, these are three rules:
• Default - baseline: all east-west traffic is prohibited, except for the explicitly permitted. The exact opposite of the classic model, where internal traffic is allowed by default
• Least privilege - permits are issued at the minimum level required: a specific port, a specific protocol, a specific direction
• Time-bound access - Temporary solutions with automatic rollback are used for administrative connections, service windows and service tasks
The principled point: microsegmental policies should be based on the identity and attributes of workloads, and not on IP addresses. In cloud and container environments, IP addresses ephemeral (Palo Alto Networks write about this directly) - containers appear and disappear in seconds, and the IP-based rules become unmanageable. Instead of the rule allow 10.100.0.10 tcp/80 The policy looks like env=prod, app=billing -> env=prod, app=database, port=5432. Changes in infrastructure automatically update policies without human intervention.
An example of a default deny policy for Kubernetes:
Typical Errors When Implementing Network Microsegment
According to a Zero Networks survey, 88% of CISO reported serious difficulties in the implementation of Zero Trust (the methodology and sample are not disclosed, so that the figure is perceived with the reservation). Microsegmentation is one of the most complex components, and errors here are beaten by budget and timing directly.
1. "Permit any" within the segment. The most common and most destructive mistake. The organization creates segments, but within each - complete freedom of communication. The attacker, trapped in the segment, moves on it without restrictions. Microsegmenting only works at default in the segment. Otherwise, it is VLAN with a new name.
2. Big bang deployment. Trying to translate all segments into enforcement at the same time. The result is massive incidents with accessibility, the panic of users, the strong-willed decision of the management to roll back everything. The project is “frozen” for an indefinite period. The correct way is a step-by-step input, starting with test media.
3. IP-addressed policies. IP addresses change when scaling, migrating VM, in cloud environments. Rule allow 10.0.1.0/24 -> 10.0.2.0/24 breaks at the first reorganization of the address space. Labels and attributes of workloads are resistant to infrastructure changes.
4. Lack of monitoring after the deck. Politicians created, translated into enforcement - and forgot. Without constant monitoring, there is no new legitimate dependencies that are blocked; attempts to bypass or disconnect the means of segmentation (T1686, Disable or Modify System Firewall); configuration drift. Integration with SIEM is mandatory - microsegmentation events should correlate with other sources.
5. Ignoring east-west within the same level of trust. Typical picture: segment "accounting from the IT department", but do not segment the database servers between each other within a single data center. This is how Network Boundary Bridging works (T1599) - the attacker moves between systems at the same level of trust, where control is minimal.
Checklist for the implementation of microsegment of the network
Ready list of actions for transfer to the team - from planning to operation.
1. Conduct an inventory of all workloads (servers, VM, containers, network equipment) indicating the owner and the level of criticality
2. Collect the tsi-alt-west communications - NetFlow/sFlow or agency data for at least 2 weeks of working activity
3. Determine protect surfaces: critical data, applications, infrastructure services
4. Classify assets by level of risk and regulatory requirements (187-FZ for GOKII, 152-FZ for the STI, industry standards)
5. Choose an approach to microsegmentation (agent / network / cloud / combined) based on current infrastructure
6. For subjects of CII - check the compliance of the selected tool with the requirements of FSTEC (protection class, OOD, IE protection profile)
7. Deploy the tool in monitoring mode (without blocking) on the pilot group - at least 2 weeks
8. Form policies based on real traffic: default deny + explicit permissions for tags and attributes
9. Test Policies in Intent-only Mode - fix all false positives and undocumented dependencies
10. Convert to enforcement pilot segment, monitor accessibility incidents for at least 1 week
11. Gradually expand enforcement - from less critical segments to more critical
12. Configure integration with SIEM to correlate microsegmentation events with other telemetry sources
13. Set a regular cycle of policy revision: once a quarter or at every change in the application architecture
14. Document all exceptions and temporary permits indicating the duration of the person responsible
15. Conduct tabular exercises: simulate the compromising the node inside the protected segment and check whether the microsegment of the lateral movement stops
Why Classic Network Segment Doesn't Stop the Elaboration
Traditional network segmentation is built on VLAN and ACL. To separate broadcast domains and control of forward-south traffic - what goes from client to server through the perimeter - this is enough. The problem is another: the main volume of traffic of modern data centers and cloud environments - east-west, between workloads inside the perimeter. According to Palo Alto Networks, east-west communications make up most of the traffic of data centers, and perimeter means of protection simply do not see this traffic. Everything inside the perimeter is implicitly considered trusted.
The attacker, which has received initial access through compromised accounting data (T1078, Valid Accounts), begins exploration: detection of network services (T1046), search for neighboring systems (T1018), analysis of network connections (T1049) and network configurations (T1016) Then - horizontal movement through Remote Services (T1021) and, if you are lucky, Network Boundary Bridging (T1599) to go beyond the current network segment. The classic VLAN-segmentation will not interfere with any of these steps if the attacker is already inside the “trusted” perimeter.
Reassemble the VLAN structure under the new requirements is a task that draws a change in the physical or logical network architecture. According to Palo Alto Networks, the re-architecture of VLAN and the reconfiguration of VLAN under security requirements are a long and expensive process. That is why the microssegmentation of the Zero Trust network is not “VLAN smaller”, but a fundamentally different approach to controlling east-west traffic, built on software-defined perimeters around each workload.
Three Approaches to Network Microsegmentation
According to the Palo Alto Networks classification, microsegmental controls are divided into three categories. The choice of approach determines the architecture, budget and timing of implementation - the decision must be made before the purchase of specific microsegmental tools.
Agent Decisions
The software agent is placed directly on the workload - host, VM, container - and provides granular insulation at the host level. The agent can use the built-in airfield (iptables, Windows Firewall) or its own enforcement mechanism. Policies are built on the basis of the identity of the workload and its attributes, not IP addresses. For dynamic environments, this is fundamental.
The main advantage is complete independence from the network infrastructure. The agent works the same in an on-premise center, a public cloud and a hybrid environment. The visibility of east-west traffic is complete, including communication between processes on one host. The reverse side - the agent needs to be put, configured and updated on each host. In environments with thousands of nodes, this is a tangible operating load, and chaos will begin without mature processes of configuration management.
Network (SDN) Solutions
Control goes through the software-definable network: virtual switches, overlay networks, distributed firewalls at the hypervisor level. Politicians are used in a network factory without installing agents on workloads. In the case of VMware NSX, each virtual port receives its own Firewall, which inspects east-west traffic before it gets into the physical network.
Plus - centralized management and lack of an agency load. Minus - binding to the vendor of a network platform and a headache in heterogeneous environments, where several hypervisors, bare-metal servers and container orchestrators coexist.
Cloud Native Controls
Built-in mechanisms of cloud providers: AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall. Manage through the provider’s API, integration “out of the box”.
Plus - zero costs for additional tools. Minus – works only inside a particular cloud, does not cover on-premise or multi-cloud scenarios.

For most enterprise environments with hybrid infrastructure, the optimal combination is optimal: an agent solution for cross-platform enforcement plus cloud-native controls for cloud-native workloads. In the coming years, most enterprises introducing the Zero Trust will use several segmentation methods at the same time – and this is not redundancy, but the reality of the hybrid world.
Microsegmental Tools: Comparison for Your Infrastructure
Choosing a specific product is one of the first questions asked by CISO or IT director. Below is a comparison of the solutions I worked with in projects on Zero Trust transformation.

Illumio and Akamai Guardiore consistently receive high scores on Gartner Peer Insights and PeersPopot - an agent-generating approach for network insulation tasks of workloads really matured.
Tools for the Russian market
For subjects of critical information infrastructure and organizations under 187-FZ and the requirements of FSTEC the choice of microsegmental tools is limited. By Order FSTEC No76, the means of information protection must correspond to a certain class and pass certification. According to the Order of FSTEC No9 of 09.02.2016, firewalls are classified by types (A - network level, B - logical network boundary, B - level of the node, G - level of the web server, D - industrial), and the required level of trust (OUD) depends on the class of protection of a particular ME.
In Russian realities for microsegmental tasks apply:
• UserGate NGFW - Certified by MEE with L7-filtration, applicable for segmentation between zones and control of east-west at the subnet level
• PT NGFW (Positive Technologies) - NGFW with integration into the PT ecosystem, including MaxPatrol SIEM to correlate segmentation events with other sources
• Network policies Kubernetes (NetworkPolicy) - for container media; do not require separate certification if perimeter protection is certified
• RUNOS and Astra Infrastructure Cloud - SDN-solutions for the Russian market, but their capabilities of microsegmentation at the enterprise level are still noticeably inferior to foreign counterparts
I will honestly say: none of the Russian decisions today does not give an agent microsegmentation of the level of Illumio or Guardicore. For CII subjects, this means the need to combine certified IE with manual workout policies - it is longer, more difficult, but there are no other options yet.
Formation of policies: from monitoring to enforcement
The most responsible phase. A typical error is to immediately enable the lock. The right approach is three consecutive stages.
Stage 1 - Detection (2-4 weeks). The tool works in the monitoring mode and passively collects data on real communications. No traffic is blocked. At the output - a map of all east-west streams and automatically generated recommendations on politicians.
Stage 2 - Policy testing (2-4 weeks). Rules are created on the basis of the collected data. The tool shows what traffic would be blocked when activated, but actually misses everything. The goal is to identify false positives and undocumented relationships between services. It is here that the same “and we forgot that the backup agent goes to all servers on the port 9090.”
Stage 3 - Enforcement (stepped). Policies are transferred to blocking mode from the least critical segments: test environments, development environments. Critical production systems - in the last, after full verification.
Po NIST SP 800-53AC-1 (Access Control) requires the development of policies that define goals, roles and responsibility in access management. For microsegmentation, these are three rules:
• Default - baseline: all east-west traffic is prohibited, except for the explicitly permitted. The exact opposite of the classic model, where internal traffic is allowed by default
• Least privilege - permits are issued at the minimum level required: a specific port, a specific protocol, a specific direction
• Time-bound access - Temporary solutions with automatic rollback are used for administrative connections, service windows and service tasks
The principled point: microsegmental policies should be based on the identity and attributes of workloads, and not on IP addresses. In cloud and container environments, IP addresses ephemeral (Palo Alto Networks write about this directly) - containers appear and disappear in seconds, and the IP-based rules become unmanageable. Instead of the rule allow 10.100.0.10 tcp/80 The policy looks like env=prod, app=billing -> env=prod, app=database, port=5432. Changes in infrastructure automatically update policies without human intervention.
An example of a default deny policy for Kubernetes:
This policy allows only a falsity with a mark app=billing Refer to the database on the port 5432. All other incoming communications to the database are blocked - deny default.YAML:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: billing-to-db
namespace: production
spec:
podSelector:
matchLabels:
app: database
ingress:
- from:
- podSelector:
matchLabels:
app: billing
ports:
- protocol: TCP
port: 5432
policyTypes:
- Ingress
Typical Errors When Implementing Network Microsegment
According to a Zero Networks survey, 88% of CISO reported serious difficulties in the implementation of Zero Trust (the methodology and sample are not disclosed, so that the figure is perceived with the reservation). Microsegmentation is one of the most complex components, and errors here are beaten by budget and timing directly.
1. "Permit any" within the segment. The most common and most destructive mistake. The organization creates segments, but within each - complete freedom of communication. The attacker, trapped in the segment, moves on it without restrictions. Microsegmenting only works at default in the segment. Otherwise, it is VLAN with a new name.
2. Big bang deployment. Trying to translate all segments into enforcement at the same time. The result is massive incidents with accessibility, the panic of users, the strong-willed decision of the management to roll back everything. The project is “frozen” for an indefinite period. The correct way is a step-by-step input, starting with test media.
3. IP-addressed policies. IP addresses change when scaling, migrating VM, in cloud environments. Rule allow 10.0.1.0/24 -> 10.0.2.0/24 breaks at the first reorganization of the address space. Labels and attributes of workloads are resistant to infrastructure changes.
4. Lack of monitoring after the deck. Politicians created, translated into enforcement - and forgot. Without constant monitoring, there is no new legitimate dependencies that are blocked; attempts to bypass or disconnect the means of segmentation (T1686, Disable or Modify System Firewall); configuration drift. Integration with SIEM is mandatory - microsegmentation events should correlate with other sources.
5. Ignoring east-west within the same level of trust. Typical picture: segment "accounting from the IT department", but do not segment the database servers between each other within a single data center. This is how Network Boundary Bridging works (T1599) - the attacker moves between systems at the same level of trust, where control is minimal.
Checklist for the implementation of microsegment of the network
Ready list of actions for transfer to the team - from planning to operation.
1. Conduct an inventory of all workloads (servers, VM, containers, network equipment) indicating the owner and the level of criticality
2. Collect the tsi-alt-west communications - NetFlow/sFlow or agency data for at least 2 weeks of working activity
3. Determine protect surfaces: critical data, applications, infrastructure services
4. Classify assets by level of risk and regulatory requirements (187-FZ for GOKII, 152-FZ for the STI, industry standards)
5. Choose an approach to microsegmentation (agent / network / cloud / combined) based on current infrastructure
6. For subjects of CII - check the compliance of the selected tool with the requirements of FSTEC (protection class, OOD, IE protection profile)
7. Deploy the tool in monitoring mode (without blocking) on the pilot group - at least 2 weeks
8. Form policies based on real traffic: default deny + explicit permissions for tags and attributes
9. Test Policies in Intent-only Mode - fix all false positives and undocumented dependencies
10. Convert to enforcement pilot segment, monitor accessibility incidents for at least 1 week
11. Gradually expand enforcement - from less critical segments to more critical
12. Configure integration with SIEM to correlate microsegmentation events with other telemetry sources
13. Set a regular cycle of policy revision: once a quarter or at every change in the application architecture
14. Document all exceptions and temporary permits indicating the duration of the person responsible
15. Conduct tabular exercises: simulate the compromising the node inside the protected segment and check whether the microsegment of the lateral movement stops