Our network is “flat” — what does that actually mean?

“We’ve got a flat network” is one of those phrases that can mean several different things. Sometimes it describes a genuine design choice. Sometimes it means nobody is quite sure which devices can talk to which. And sometimes it is a polite way of saying that everything is plugged into the same large, poorly documented network and we hope the firewall sorts it out.

That last version is where the trouble starts. A flat network can make it easier for a fault, an attacker or a misconfigured device to affect more of the organisation than it should. It can also make security monitoring less useful: when there is little separation between systems, there are fewer clear boundaries at which to detect suspicious activity.

Understanding what “flat” means is a useful first step towards practical segmentation basics. It is not an instruction to buy a particular product or create dozens of VLANs. It is a way to ask better questions about how the network is physically and logically built, what is allowed to communicate, and what happens at 2am when a link or switch fails.

What is a flat network?

A network is commonly called flat when many devices share the same, or very broadly connected, network environment, with limited separation between user devices, servers, operational technology (OT), printers, wireless clients and other systems. In a very simple case, they may all sit in one broadcast domain. In other cases, there may be several network segments, but traffic can move between them with few effective controls. The word “flat” is therefore a useful warning sign, not a precise design specification.

A broadcast domain is the part of a network where devices can receive certain local broadcast traffic from one another. Switches normally forward this kind of traffic within the https://seo.edu.rs/blog/what-is-poe-and-why-does-it-matter-for-network-design-11222 relevant VLAN; routers generally keep it from travelling into other IP networks unless specifically configured to do so. When a large number of devices share a broadcast domain, broadcasts and some types of local discovery traffic can reach more devices than necessary.

That does not mean every broadcast is dangerous, or that one broadcast domain automatically equals a security incident. The bigger concern is what the design says about boundaries. If workstations, servers and sensitive equipment are all on the same segment, a compromised device may have a much easier time discovering and reaching other systems.

“Flat” is about more than VLANs

It is tempting to think of network separation as a VLAN exercise: create a VLAN for one group of devices, another for the next, and call the job done. VLANs are important, but they are not a complete security policy. A VLAN separates Layer 2 traffic; it does not, by itself, decide whether two IP networks should be allowed to communicate. That decision depends on routing and the controls applied between those networks.

Good segmentation combines sensible boundaries with explicit rules for traffic crossing them. Depending on the design, those controls may include access control lists, firewalls, router policies and other enforcement points. A firewall can help restrict traffic between segments, but its presence alone cable management in racks does not prove that meaningful segmentation exists. If its rules allow broad “any to any” access, or important traffic bypasses it, the boundary may be mostly theoretical.

Switch capability and configuration matter too. The network needs to support the intended VLANs, routing or policy enforcement, management controls and resilience. A design drawn on a whiteboard is only real when the switches, routers, firewalls and cabling are configured consistently and can be operated safely. Products from vendors such as Cisco may be used in enterprise networks, while Garland and MOXA may be relevant in particular network or industrial environments. The important question is not the logo on the front: it is whether the equipment is suitable, configured correctly, supported and managed.

Why a flat network matters to security

Imagine an employee opens a convincing phishing attachment. An attacker gains control of that workstation. In a well-designed environment, the workstation should have access only to the services it needs. In a broad, flat environment, it may be able to scan or attempt connections to a much wider range of devices: file servers, administrative interfaces, printers, backup systems or equipment on an OT network.

Segmentation does not guarantee that an attack will stop. It can, however, reduce unnecessary paths, limit the reach of a compromised device and make suspicious traffic easier to spot. That matters because a security incident is not only about how an attacker gets in. It is also about how far they can move, which systems they can affect and how quickly the organisation can identify the activity.

Endpoint detection platforms can provide valuable visibility into behaviour on supported devices. Firewalls can enforce policies between network zones. Neither can compensate for every weakness in the underlying design. An endpoint tool may not cover an unmanaged switch or a specialist device, and a firewall cannot inspect traffic that does not pass through it. Good security uses multiple controls and understands what each one can—and cannot—see.

Physical infrastructure is part of cybersecurity

Cybersecurity conversations often focus on software and policy, but physical infrastructure is part of the security system. A switch that is placed somewhere accessible, an unused wall port left active or an undocumented connection between cabinets can create paths that were never included in the intended design.

Likewise, cabling and switching faults can create security blind spots as well as outages. Consider a mispatched cable that connects two network areas, a switch added under a desk to “get a few more ports”, or a trunk port configured to carry VLANs that were not intended to be available there. Each can undermine segmentation without anyone changing a firewall rule. Unmanaged switches in production are particularly hard to govern: they may provide no useful inventory, access control or central visibility, while quietly changing how devices are connected.

Then there are the ordinary physical-layer failures: damaged patch leads, failing transceivers, incorrect fibre types, poor terminations, power problems and loops. These can cause packet loss, intermittent connectivity or a storm of traffic. At the same time, the incident response team may be looking at endpoint alerts and firewall logs while the actual cause is a physical connection nobody has documented.

That is why I count mystery cables as a security smell. If nobody can say where a cable starts, where it ends or what service depends on it, you cannot reliably assess the risk of moving, unplugging or tracing it. A label maker is not a security product, but a labelled patch panel and accurate port records make it much easier to spot unexpected connections and restore service under pressure. Cabling is not “just plumbing”; it is part of how the security design is implemented.

Segmentation basics: start with purpose

Useful segmentation begins with understanding what you need to protect and how systems need to communicate. Creating segments before anyone has mapped the dependencies can break business processes—or result in rules so broad that the new boundaries achieve little.

Build an inventory. Identify key devices, their owners, their locations and their purpose. Include switches, wireless access points, firewalls, servers, printers, building systems and OT assets where relevant.
Map communication needs. Record which systems initiate connections to which services, and why. Distinguish required traffic from traffic that merely happens to work today.
Group by risk and function. Common boundaries might separate user devices, servers, guest access, management interfaces, payment systems or OT. The right groups depend on the organisation, not a universal template.
Define and enforce policy. Decide what is allowed between groups, apply controls at the appropriate routing or firewall points, and avoid broad rules that erase the separation.
Test, monitor and document. Confirm that permitted services work, prohibited paths are blocked, and alerts or logs provide useful visibility. Record the design and keep it current.

These are the segmentation basics, not a one-off project checklist. New devices, acquisitions, office moves and changes to applications can all introduce new paths. A network that was well segmented three years ago may be effectively flat today if temporary connections and permissive rules were never reviewed.

What should you look for?

You do not need to begin by redrawing the whole network. Start with practical questions. Can a standard user workstation reach switch management interfaces? Can guest wireless clients reach internal services? Are OT devices reachable from ordinary office networks? Do all switch ports have a known purpose? Are unused ports disabled or otherwise controlled? Do firewall rules have an owner and a reason?

Also check what is physically present. Compare diagrams and switch configurations with the patch panels, cabinets and cable routes on site. Look for unmanaged switches, unlabelled links and unexpected connections. Trace changes back to a change record where possible. If the records and the building disagree, treat that as a real operational risk rather than an administrative tidy-up.

Observation Why it matters Useful next step Users and sensitive servers share a broad network A compromised user device may have unnecessary paths to important systems Map required flows and assess appropriate boundaries Firewall rules permit wide, poorly explained access Logical separation may not provide meaningful restriction Review rules with service owners and test the intended policy Unmanaged switches or mystery cables are present Connections may bypass design assumptions and monitoring Identify, document and replace or govern the equipment Diagrams do not match the live network Changes and faults are harder to assess and recover from Reconcile records with switch configurations and physical checks

How ACSC guidance fits in

ACSC guidance is most useful when it is treated as part of a broader security programme, not a substitute for sound network engineering. Security controls depend on foundations: knowing what is connected, controlling access, managing configuration and being able to observe and respond to events. Network segmentation can support those outcomes, but it must be implemented and maintained in the real environment.

In other words, guidance assumes the organisation has enough visibility and control to make its protections work. If switch configurations are inconsistent, equipment is untracked or physical links are unknown, it becomes much harder to apply policy reliably or investigate an event. A written rule that “OT is isolated” does not make it so if a forgotten uplink provides another route in.

Ask the 2am question

A design is not finished when traffic passes a test during business hours. Ask what happens at 2am when a switch fails, a link flaps or someone moves a patch lead to restore a service. Can the on-call engineer identify the affected circuit? Is there a documented failover path? Will the backup path preserve the same security controls, or bypass them? Can responders tell whether the symptom is an attack, a configuration change or a physical fault?

Resilience and security need to be designed together. Redundant links are useful, but they must be configured and monitored deliberately. A hurried workaround that restores connectivity by bridging two segments can create a bigger incident than the original outage. Clear labels, tested procedures, controlled access to cabinets and an accurate network map are not glamorous, but they reduce the chance of that kind of decision being made blind.

Flat is a prompt to investigate, not a verdict

Calling a network flat should start a conversation, not a blame exercise. The term may point to one large broadcast domain, weak controls between network segments, physical connections that bypass the design, or simply a lack of reliable documentation. Finding out which is true requires looking at the live configuration and the physical infrastructure together.

Start with the systems that matter most, map their communication needs, and identify where unnecessary paths exist. Use capable switching and correctly designed enforcement points to put meaningful boundaries in place. Combine firewalls and endpoint detection platforms with accurate inventories, monitoring, controlled changes and sound physical practices.

A network does not have to be complicated to be secure. It does need to be understandable. When every connection has a purpose, boundaries are enforced rather than assumed, and someone can explain what happens at 2am, “flat” becomes a design problem you can actually solve.