Network segmentation decays unless you test the boundaries
Separate network zones can become connected by inherited firewall rules, vendor access and shared management systems. Segmentation needs maintained policies, understood dependencies and evidence that its boundaries still work.
A network can look neatly segmented on a diagram and still contain far more trust than its design intended.
The problem usually develops gradually. A supplier needs temporary remote access. An application inherits an old firewall rule. A shared management platform is allowed to reach systems in several environments. A site-to-site connection remains in place because nobody wants to risk interrupting a poorly understood dependency.
Each decision may have made sense at the time. Taken together, they can quietly reconnect systems that were supposed to remain separated.
The Australian Signals Directorate's (ASD) network segmentation and segregation overview, published in September 2026, explains why controlling communication between zones helps limit the spread of compromise and protect critical business services. Its companion anti-patterns guidance identifies the recurring configuration and operational choices that weaken these boundaries over time.
The practical lesson is that segmentation is not a drawing. It is a set of deliberately controlled, observable and tested communication boundaries.
A VLAN is not a trust decision
VLANs and separate IP subnets are useful tools for organising infrastructure. They do not, by themselves, determine which users, devices or applications should be trusted.
An environment can be divided into numerous VLANs while broad routing policies, permissive firewall rules or shared administrative access still allow extensive communication between them.
There is an important distinction between segmentation, which divides infrastructure into zones, and segregation, which enforces rules governing communication between hosts and services.
The value comes from combining the two. Systems should be grouped according to their role and criticality, while the communications permitted between those groups should reflect genuine business requirements.
Consider a corporate user network, an application environment and a management network. Placing them in separate VLANs is a starting point. If any user workstation can still reach server-management interfaces through a permissive inter-VLAN rule, the intended administrative boundary may provide little protection.
The question is not how many VLANs exist. It is whether the infrastructure enforces the right access between them.
Dependencies change after commissioning
Networks rarely stay the same after a project is delivered.
Applications move, systems are retired, cloud services are introduced and suppliers change. Temporary exceptions are sometimes left in place because the original request is forgotten or the team is uncertain about what will fail if a rule is removed.
A segmentation design can therefore be appropriate when commissioned and materially weaker two years later, even if nobody has deliberately disabled a firewall or removed a security control.
Documentation helps, but the documentation is not proof that the production network still behaves as designed.
Teams need to compare the intended communication model with the live environment, including authorised traffic, rules that are no longer used, unexpected cross-zone activity and alternative paths that may bypass the normal controls.
This is where monitoring, configuration records and periodic review become more valuable than the network diagram alone.
A useful assurance question is: can we demonstrate that communication across important boundaries is limited to what the business still requires?
Third-party and management access need special attention
Remote support and administrative access can cross precisely the boundaries an organisation is trying to maintain.
An always-on supplier VPN may be convenient, but a connection that reaches an entire internal network can provide much broader access than the specific equipment or service requiring support.
Shared monitoring, backup, remote management and administrative platforms deserve similar scrutiny. They often need access to many systems, which can make them valuable operational tools but also potential bridges between otherwise separated environments.
ASD's segmentation anti-patterns guidance highlights these concerns, including implicit trust based on network location, broad third-party connectivity and management infrastructure with excessive cross-zone reach.
The objective is not to eliminate useful remote support or create unnecessary barriers for engineers. It is to make access intentional.
Supplier connections should be linked to identifiable users, devices and services, constrained to the systems required, and reviewed when responsibilities change. Shared management paths should have clear owners and appropriate authorisation, logging and boundary controls.
A supplier relationship should not create an undocumented route through several critical environments.
Test the boundary, not just the firewall configuration
A rule review can confirm what a firewall is configured to permit. It does not always establish what is actually reachable.
For example, traffic may follow an alternate router, inherited tunnel, host-based connection or management path. Policy intent can also be undermined by broadly scoped address groups, exceptions added for troubleshooting or services using unexpected ports.
Boundary testing is therefore different from simply inspecting rule tables.
For important zones, an organisation should be able to establish:
- which systems and services are expected to communicate across the boundary;
- which identities or administration paths can reach sensitive interfaces;
- whether unapproved or unnecessary access is blocked in practice;
- whether alternate paths bypass the intended controls;
- whether relevant traffic and policy changes are recorded; and
- how the boundary can be tightened or a compromised zone isolated when necessary.
Testing must be planned carefully in business-critical environments. Active reachability checks, policy changes and simulated containment should be scoped and authorised so they do not disrupt live applications.
A controlled validation process can combine documentation review, observed network traffic and targeted tests appropriate to the systems involved.
The aim is evidence that the boundary works, rather than confidence based only on how it was originally configured.
Segmentation must remain operable
An overcomplicated design can be difficult to maintain. A very permissive design may be easy to operate but fail to contain a problem.
The right balance depends on the services being protected, their dependencies and the organisation's ability to support the controls over time.
Critical systems may justify stronger segregation and more frequent assurance. Less sensitive environments may be adequately protected through simpler zones with well-defined access policies.
Exceptions are sometimes necessary. They should have a reason, an accountable owner and a review point. When the business requirement ends, the access should not remain indefinitely through inertia.
It is also important to preserve the ability to manage and recover systems if a network zone is restricted during an incident. Segmentation should support containment and recovery, not make every emergency action dependent on uncontrolled shared infrastructure.
ASD's Information Security Manual networking guidance recommends segregating networks according to the criticality of their services and data, including separating administrative infrastructure and service-provider networks.
The principle is straightforward: design controls that operations teams can understand, maintain, observe and validate.
Six questions for a segmentation review
Before relying on network segmentation as a security or resilience control, an organisation should be able to answer six questions:
- Which business services are the boundaries intended to protect? Prioritise systems by importance and the consequences of compromise.
- What communication is actually required? Identify necessary application, identity, backup and administration dependencies.
- Who can cross each boundary? Include users, service accounts, vendors, jump hosts and management tools.
- What exceptions have accumulated? Check temporary rules, broad address groups and connections with no current owner.
- How do we know the controls work? Use live evidence and appropriately scoped tests rather than diagrams alone.
- What happens during an incident? Confirm that isolation and recovery arrangements remain practical when access is restricted.
If those answers are unclear, the organisation may have a segmentation design without the evidence needed to rely on it.
Make boundary assurance part of normal infrastructure ownership
Segmentation becomes harder as organisations accumulate additional sites, inherited systems, cloud networks, remote users and supplier connections.
A structured Infrastructure Review can help establish the current communication model, identify broad trust relationships and expose gaps between the documented design and live operation.
Where architectural changes are justified, Infrastructure Design & Delivery can help implement maintainable boundaries that accommodate genuine business dependencies. Ongoing Infrastructure Monitoring can contribute the visibility needed to detect configuration drift and unexpected communication.
The objective is not maximum isolation or the largest possible collection of firewall rules. It is infrastructure in which access is deliberate, understandable and proportionate to business need.
A useful network boundary is one the operations team can explain, maintain and test. If it exists only on the diagram, it is not providing the assurance the business expects.