CompTIA SY0-701: Secure Network Segmentation
Network segmentation limits which systems can communicate and how far an attacker or failure can move after one system is compromised. It can be implemented through VLANs, subnets, firewalls, security groups, VRFs, SDN policy, host firewalls, microsegmentation, identity-aware gateways, or combinations of those controls. The security value comes from enforcement between trust zones, not from drawing colored boxes on a network diagram.
NIST zero-trust guidance makes an important distinction: network location alone should not create implicit trust. Segmentation is still valuable, but modern architectures pair network boundaries with identity, device, application, and data controls. A “trusted internal VLAN” that can reach everything is segmentation in topology but not strong access control.
Segmentation belongs inside CompTIA Security Operations.
Segment around trust boundaries
Start with which assets have different risk, ownership, sensitivity, or business purpose.
Trust boundaries can separate internet-facing services, user devices, servers, management, backups, OT, guest networks, partner access, and regulated data.
A zone should have an explainable purpose and a policy for what is allowed to cross it.
Use default-deny between sensitive zones
Permitting only required flows is stronger than allowing broad east-west reachability and relying on endpoint security to stop lateral movement.
Network segmentation should express source, destination, protocol, service, and business reason narrowly enough that operators can review access later.
Default deny works best when application dependencies are understood before enforcement is tightened.
Separate management traffic
Administrative interfaces, hypervisor management, network-device control, backup consoles, and security tools deserve dedicated access paths.
Compromise of a user workstation should not automatically provide network reachability to the systems that can reconfigure the environment.
Use privileged access, management networks, bastions, or identity-aware administration according to platform capability.
Use microsegmentation for fine-grained control
Microsegmentation applies policy closer to individual workloads, identities, or applications rather than only at large network zones.
This is valuable in virtualized, cloud, and container environments where IP addresses change and many services share one broader subnet.
Microsegmentation adds policy volume, so asset identity and automation must be reliable enough to avoid creating an unmanageable rule base.
Do not trust segmentation by label
A VLAN tag, private IP, or “inside” interface does not prove the device is trustworthy.
Zero-trust access adds identity, device posture, authentication, and context to network controls.
Segmentation reduces reachability; authorization decides whether the subject should be allowed to use the service after it becomes reachable.
Protect shared services
DNS, directory services, update servers, logging, backup, and identity platforms often need access from many zones.
Shared reachability can turn them into lateral-movement hubs if every system can initiate arbitrary connections to them.
Allow only required protocols and directions and separate administrative access from normal service consumption.
Monitor denied and allowed traffic
Firewall and flow logs can show blocked connection attempts, unexpected east-west traffic, and applications still depending on old broad rules.
Logging should support both policy tuning and incident response.
A deny spike can indicate attack activity or a broken deployment; operators need enough context to tell the difference.
Test failure and bypass paths
Segmentation can fail through alternate routes, VPNs, cloud peering, wireless bridges, host routes, or misconfigured security groups.
Test whether systems in one zone can reach prohibited destinations through every major network path.
Negative tests are more valuable than assuming a firewall object exists because it appears in the configuration.
Keep segmentation aligned with architecture
For Security+ SY0-701, the durable model is trust zone → required flow → enforcement point → default deny → identity context → logging → periodic validation.
Zero-trust architecture does not eliminate segmentation; it removes the assumption that being inside one segment is enough to trust a user, device, or service.
Secure segmentation reduces blast radius while preserving only the connectivity the business actually needs.
Segmentation should begin from data flows, not organizational charts. Applications often cross team boundaries, and two servers owned by the same department may have very different sensitivity. Map who initiates connections, which protocol is required, where data moves, and whether the destination should ever initiate traffic back.
North-south and east-west traffic create different challenges. Internet-facing controls focus on ingress/egress, while lateral movement usually occurs east-west between internal workloads. Mature segmentation covers both so attackers cannot bypass a hardened perimeter after compromising one user device or application server.
Guest and unmanaged devices should be isolated from internal services by default. Internet access can be provided without route access to corporate management interfaces, file shares, or internal DNS zones. BYOD that needs business applications can use identity-aware application access rather than broad LAN membership.
Production and nonproduction separation reduces both security and operational risk. Development credentials, test services, and experimental software should not provide a route into production databases. Separate accounts, VPCs/VNets, VLANs, security groups, or other boundaries can enforce the distinction beyond naming conventions.
Backups deserve their own segment and administrative path. Ransomware commonly targets reachable backup infrastructure after compromising normal administrator credentials. Restrict network access, management ports, and deletion capabilities so workload compromise does not automatically include backup compromise.
OT and IoT environments often contain devices that cannot run modern endpoint agents or patch quickly. Segmentation can create compensating protection by limiting which systems can initiate connections to those devices and by routing required protocols through inspection or monitored gateways.
Cloud segmentation should use native constructs. AWS security groups, Azure NSGs, GCP firewall policies, Kubernetes network policy, service mesh authorization, and cloud-native private endpoints may provide stronger workload identity or metadata context than reproducing an on-premises VLAN model in the cloud.
Identity-aware segmentation can reduce reliance on IP addresses. Dynamic tags, workload identities, security-group references, directory groups, or device certificates can express policy that survives autoscaling and address changes. This is particularly useful in cloud and container environments where static addresses are poor identifiers.
Segmentation policy should include egress, not only inbound access. A compromised server that can connect to any internet destination can still exfiltrate data or retrieve payloads even if other internal segments are protected. Egress controls should follow business need while keeping software updates and SaaS access operational.
DNS is part of segmentation. Split-horizon DNS, private zones, resolver rules, and DNS filtering can influence whether systems reach public or private endpoints. A network rule that looks correct can be bypassed or broken when name resolution points the application to a different path.
Firewalls should use application/service context where appropriate, but policy should remain understandable. Hundreds of overlapping rules with ambiguous groups can make “segmented” networks effectively flat because nobody knows which rule grants access. Use naming, comments, ownership, and periodic cleanup.
Rule recertification should focus on high-risk paths: user-to-server administration, production-to-nonproduction, management-plane access, regulated-data zones, backup access, and partner connections. Expired exceptions should be removed rather than kept because deleting them feels risky.
Segmentation changes need application testing. Blocking an undocumented dependency can cause outages that pressure teams to add emergency broad rules. Pilot policies, observe traffic, confirm with application owners, and then enforce the narrow set of required flows.
Incident response can use segmentation dynamically. A compromised device or subnet can be quarantined, a malicious egress destination blocked, or one management path disabled while investigation continues. Predefined quarantine groups and procedures are safer than inventing emergency firewall rules during an incident.
Success should be tested with both positive and negative flows. Confirm applications can reach required dependencies and cannot reach prohibited zones. A policy that blocks attacks but also blocks business traffic will be bypassed; a policy that allows everything business needs plus everything else has not reduced blast radius.
Segmentation also needs identity for administrative access. A management subnet with strong firewall rules can still be abused if every administrator shares one privileged account. Combine network reachability with strong authentication, device trust, and session controls so the management path is narrow in both network and identity terms.
Cloud and container platforms can enforce policy at workload identity rather than only IP. Security-group references, Kubernetes network policy, service mesh authorization, and cloud-native tags can move segmentation closer to the application. This is important because autoscaling and ephemeral infrastructure make static address lists difficult to maintain accurately.
Business partner connections deserve their own zones. A vendor VPN or private circuit should expose only the systems and protocols required for the relationship, with logs and expiry tied to the contract. Treating a partner network as “trusted internal” turns one supplier compromise into an enterprise lateral-movement path.
Segmentation is mature when one compromised workstation, server, or cloud workload does not automatically have a route to every other sensitive asset. The architecture should make that claim testable through firewall policy, route tables, service authorization, and negative connectivity tests.
Network segmentation should also account for authentication infrastructure. Domain controllers, RADIUS/TACACS servers, PKI, and identity proxies often serve many zones, but ordinary workloads should not be able to administer them. Separate service consumption from management and restrict administrative paths to hardened identities and devices.
Cloud route tables can undermine segmentation just as firewall rules can. A new Transit Gateway, VNet peering, service endpoint, or VPN connection can create reachability that bypasses the original boundary. Review routing and security policy together whenever hybrid connectivity changes.
Segmentation policy should be documented at the intent level: who initiates, what destination/service is required, which data is involved, and which owner approved it. Intent makes later recertification faster than reading raw firewall syntax and guessing why a rule exists.
For critical environments, test segmentation during incident exercises. Attempt lateral movement from a compromised workstation or application subnet and verify that controls block administrative protocols, database access, backup systems, and management planes. The result demonstrates whether the architecture actually limits blast radius.