BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 20, 2026

Quick answer: Network segmentation divides a network into separate zones with enforced boundaries that control what traffic can flow between them. Its primary security value is blast radius limitation: when an attacker gains a foothold in one part of the network, segmentation prevents them from reaching the rest of it without crossing a boundary that requires explicit authorization. Organizations whose networks are not properly segmented give attackers unrestricted lateral movement once any device is compromised. Organizations with properly enforced segmentation force the attacker to work harder to reach high-value targets and give the security team more opportunities to detect and contain the intrusion before critical systems are reached.

Key Takeaways

• Segmentation on paper is not segmentation in practice. A network design document that shows VLANs, firewall zones, and segment boundaries means nothing if those boundaries are not enforced by actual firewall rules, switch configurations, and access control lists that match the intended design. Validation of segmentation means verifying that traffic that should not cross segment boundaries cannot, not just that the design document says it should not.
• Flat networks are not the result of neglect; they are the cumulative result of years of adding devices, extending access, and making exceptions that seemed reasonable individually. Each decision to allow a specific cross-segment connection for a specific business reason, without reviewing the aggregate security effect, produces a network where the enforced boundaries no longer match the intended design.
• For organizations with OT or ICS environments, the IT/OT boundary is the most consequential segmentation boundary in the entire network. Attackers who compromise the corporate IT network and can reach OT systems without crossing an enforced boundary can cause operational disruption, safety incidents, and physical damage to equipment. The zone-and-conduit model defined in ISA/IEC 62443 provides the framework for designing and enforcing this boundary correctly.
• Micro-segmentation extends the segmentation concept to the workload level: individual applications, databases, and services communicate only with the specific other workloads they need to reach, rather than having broad access within a network segment. Micro-segmentation limits lateral movement within a segment, not just between segments, and is increasingly relevant in cloud and container environments where the traditional network perimeter does not exist.
• Segmentation validation is a testing discipline, not a documentation review. Confirming that segmentation is enforced requires attempting traffic flows that the design says should be blocked and confirming that they are blocked. This validation catches misconfigurations, firewall rule exceptions, and routing anomalies that the design documentation does not reveal.

Why Flat Networks Are So Common

Most enterprise networks were not designed as flat networks. They were designed with segmentation in mind, with VLAN assignments, firewall zones, and access control policies intended to create meaningful boundaries between different parts of the environment. Flat networks emerge over time through the accumulation of exceptions, additions, and changes that individually seemed reasonable but collectively erode the intended segmentation.

A server needs to communicate with a database in a different segment: a firewall rule is added to allow that specific traffic. The rule is written to allow the specific port from any source in the first segment rather than from the specific server, because that is easier and the administrator expects the first segment to be controlled. A new business application requires access to multiple segments: rather than designing least-privilege access for each connection the application needs, a broad rule is added that allows the application’s server to reach the required segments on all ports. A vendor remote access connection needs to reach OT systems for maintenance: a VPN pathway is created, and over time additional vendor personnel are given the same access without reviewing whether the access scope is still appropriate.

Each of these changes is logged in a change management system, approved through the appropriate process, and implemented correctly. The aggregate effect of thousands of such changes over years is a network where the firewall rule sets have grown to hundreds or thousands of entries, where the VLAN assignments no longer match the intended segmentation model, and where traffic flows between segments that were supposed to be isolated. The network is not flat in the sense that no segmentation was ever intended; it is flat in practice because the accumulated changes have made the intended segmentation unenforceable. This is the same gap between the diagram and the running network that a network architecture review is designed to surface.

What Proper Segmentation Enforcement Requires

Zone design based on trust levels and communication requirements

Effective segmentation begins with a zone design that groups systems based on their trust level, their communication requirements, and the sensitivity of the data and functions they support. A typical enterprise zone design includes an internet-facing zone (DMZ) for systems that accept traffic from the public internet, a corporate user zone for employee workstations, a server zone for application and database servers, an administrative zone for privileged access and management interfaces, and a guest or contractor zone for external parties with limited access requirements. Each zone boundary is defined by the traffic that should and should not cross it.

For organizations with OT environments, the zone design extends to include the OT network layers following the Purdue Model: the enterprise network at the top levels (Levels 4 and 5), the manufacturing operations and supervisory control layer in the middle (Levels 3 and 2), and the process control and field device layer at the bottom (Levels 1 and 0). The boundary between the corporate IT network and the OT environment is governed by an industrial demilitarized zone at Level 3.5, which contains the systems allowed to communicate with both sides: historians, data integration systems, and jump hosts through which remote access to OT systems is channeled. No direct connectivity between the corporate IT network and the OT control layer is permitted in a properly segmented architecture.

Firewall rules that enforce the zone design

Zone boundaries are enforced by firewalls with rule sets that explicitly define what traffic is permitted to cross each boundary and deny everything else. The default-deny posture, which blocks all traffic not explicitly permitted, is the baseline for any effective segmentation implementation. Rule sets that have accumulated thousands of entries over years of changes frequently contain rules that permit traffic not contemplated in the current zone design, rules that apply to systems that no longer exist, and rules that were intended to be temporary but were never removed.

Firewall rule set review and cleanup is one of the most impactful elements of a network architecture engagement. Removing rules that permit traffic beyond what the current zone design intends, tightening rules that are written too broadly, and consolidating redundant rules that have accumulated from multiple rounds of changes produces a rule set that is auditable, understandable, and actually enforces the intended zone design. A firewall rule set that no one can audit is not a security control; it is an opaque policy whose actual effect on traffic is unknown.

VLAN configuration that matches the zone design

VLANs (Virtual Local Area Networks) are the Layer 2 mechanism that places devices into network segments. A VLAN configuration that matches the zone design ensures that devices assigned to one segment cannot communicate with devices in another segment at the Layer 2 level, requiring traffic between segments to traverse the firewall and be subject to the zone boundary rules. VLAN misconfigurations, including devices assigned to the wrong VLAN, trunking configurations that allow VLAN traffic to cross boundaries it should not, and native VLAN settings that create unintended communication paths, can bypass firewall-level segmentation entirely.

Validating VLAN configuration requires comparing the switch configuration for every port and trunk link against the intended VLAN design, confirming that devices are connected to the segments they are supposed to be in and that inter-VLAN traffic is routed through the firewall rather than bypassing it. This validation is straightforward in a small, static network and becomes progressively more complex as the network scales and as changes accumulate over time.

Segmentation in OT and ICS Environments

OT and ICS network segmentation follows the ISA/IEC 62443 zone-and-conduit model, which defines security zones as groupings of assets with shared security requirements and conduits as the communication pathways between zones. Each conduit is protected by security controls appropriate to the risk of the communication it carries: a conduit between the corporate IT network and the OT operations layer carries higher risk than a conduit between two OT zones with similar security requirements, and the controls applied to it must reflect that risk.

The Purdue Model provides the hierarchical reference architecture for how zones should be organized within an OT environment, with strict limits on what communication is permitted between levels. The IT/OT boundary at Level 3.5, the industrial demilitarized zone, is the most tightly controlled boundary in the architecture, and traffic that would reach down toward the process control and field device layers is the most carefully restricted, because commands or changes that reach lower-level systems can have direct physical consequences in industrial environments. Data historians, which aggregate process data from the control layer for enterprise-level reporting and analysis, are typically placed in the demilitarized zone at the boundary between the operations layer and the enterprise layer, allowing process data to flow upward for reporting without creating direct connectivity between enterprise systems and control systems.

Armour Cybersecurity applies ISA/IEC 62443 zone-and-conduit principles and the Purdue Model to every network protection engagement that includes OT or ICS environments, using non-intrusive assessment methods that do not risk operational disruption.

Frequently Asked Questions

What is a DMZ and when do we need one?

A DMZ (Demilitarized Zone) is a network segment placed between two zones of different trust levels, typically between the internet and the internal network, that hosts systems which need to be accessible from the less trusted zone (the internet) without creating direct connectivity into the more trusted zone (the internal network). Web servers, email gateways, and VPN concentrators are common DMZ inhabitants. The DMZ allows external parties to reach these systems while ensuring that a compromised DMZ system cannot reach internal systems without crossing a firewall boundary. In an OT context, the industrial DMZ at Level 3.5 between the IT network and the OT operations layer serves the same purpose, hosting historians and data integration systems that need to communicate with both sides while preventing direct connectivity between them.

What is micro-segmentation and how is it different from traditional network segmentation?

Traditional network segmentation divides the network into zones at the network level, controlling which traffic can flow between zones using firewalls and routing policies. Micro-segmentation extends this concept to the workload level, controlling which specific workloads can communicate with which other specific workloads, regardless of which network segment they are in. A database server in the application zone that should only be accessed by a specific application server can be micro-segmented so that traffic from any other source, including other servers in the same zone, is blocked at the workload level rather than only at the zone boundary. Micro-segmentation is particularly relevant in cloud and container environments where traditional network-level segmentation is difficult to enforce because workloads share infrastructure and IP addresses change dynamically.

How do we handle vendor remote access in a segmented network?

Vendor remote access should be channeled through a dedicated vendor access zone with access restricted to the specific systems the vendor needs to reach, not broad access to entire network segments. Each vendor relationship should have its own access credentials that can be revoked independently, with session logging that records what the vendor accessed during each session. MFA should be required for all vendor remote access, and sessions should be time-limited and require re-authentication rather than persisting indefinitely. The vendor access zone is separated from both the corporate IT network and the OT environment by firewall boundaries, with rules that permit only the specific traffic the vendor needs for their specific function. A vendor access registry that documents all active vendor remote access relationships, the systems each vendor can reach, and the review cycle for each relationship is the governance control that prevents vendor access from accumulating beyond its intended scope.

How much does firewall rule set sprawl actually matter?

Firewall rule set sprawl matters for two reasons. The first is security: a rule set with thousands of entries that no one has fully audited almost certainly contains rules that permit traffic beyond what the current security policy intends, including traffic that bypasses segment boundaries in ways the security team is unaware of. The second is operational risk: a rule set that is too complex to understand is a rule set that cannot be safely modified. Changes to a complex rule set carry the risk of unintended consequences that take down business services or inadvertently open security gaps, which creates pressure to avoid making changes even when changes are needed for security reasons. A clean, auditable rule set with clear documentation of the business reason for each rule is both more secure and more manageable than one that has accumulated thousands of entries over years without systematic review. Confirming that the surviving rules actually enforce the intended boundaries is a job for segmentation validation testing, which attempts the traffic flows the design says should be blocked and proves they are.

The Bottom Line

Segmentation is the control that decides how far a breach spreads. Done properly, it forces an attacker who lands on one device to cross an enforced boundary to reach anything of value, buying the security team time and detection opportunities. The problem in most organizations is not the absence of a segmentation design; it is that the design lives on paper while the running network has drifted flat through years of individually reasonable firewall exceptions, broad application rules, and accumulated vendor access. Real enforcement requires four things working together: a zone design built on trust levels and communication needs, firewall rule sets on a default-deny posture that are clean enough to audit, VLAN configurations that match the zones rather than quietly bypassing them, and, for OT environments, an ISA/IEC 62443 zone-and-conduit design with a properly enforced Level 3.5 IT/OT boundary. None of it counts until it is validated by testing that the traffic which should be blocked actually is. Armour Cybersecurity designs, validates, and hardens segmentation as part of its network protection engagement, for both IT and hybrid IT/OT environments, using non-intrusive methods that will not disrupt operations.