Flat networks are great, if you enjoy blast radius

Everything can talk to everything.

User devices can reach servers, Servers can reach other servers, Printers roam freely like feral office livestock, but at least the Guest Wi-Fi is “separate”, probably. The warehouse has “its own bit”, and there is a switch in a cupboard nobody likes to open. Every firewall rule appears to have been created during either a crisis, a migration, or a Tuesday.

This is often described as flexible, which is technically true. But a bonfire is also flexible about what it consumes.

Why flat networks happen

Flat networks rarely begin as a deliberate long-term strategy, they happen because the business needs things to work.

• A new system gets added.
• A supplier needs connectivity.
• A warehouse device needs access to a server.
• A printer needs to print, because apparently society has decided we are still doing that.
• A migration is underway.
• A firewall rule is added quickly.
• A temporary exception becomes permanent.

Over time, the network becomes less of an intentional design and more of a historical record of urgent decisions.

Everything works, mostly.

So nobody wants to touch it, and that is how many networks become flat. Over-trusted, and quietly alarming.

The problem with “everything can talk to everything”

At first, a flat network feels convenient.

Troubleshooting is easier and Access is simpler.
Integrations work and nobody has to argue about firewall rules.
Nobody has to think too hard about which systems should be allowed to communicate.

But convenience is not the same as control.

The problem with a flat network is that it gives too much reach to too many things.

• If a user device is compromised, what can it access?
• If malware lands on one endpoint, where can it move?
• If a warehouse scanner is vulnerable, what else can it see?
• If guest Wi-Fi is not properly separated, what does “guest” actually mean?
• If a supplier connection is over-permissioned, what sits behind it?

These are not theoretical questions, they are the questions that determine whether an incident stays small or becomes a business-wide problem.

Blast radius, in plain English

Blast radius is simply the amount of damage one problem can cause.

If a compromised laptop can only access what that user genuinely needs, the blast radius is smaller.

If that same laptop can see file shares, servers, management interfaces, printers, databases, and a lonely NAS box from 2014 called BACKUP-OLD, the blast radius is much larger.

That is the point of segmentation.

Its not to make IT feel clever or to create network diagrams that look like someone lost a fight with a packet tracer.

But to contain problems. Because if something goes wrong, segmentation helps ensure it does not automatically go everywhere.

Why this matters for security

A flat network makes several bad things easier.

1. Lateral movement

Once an attacker or malware gets onto one device, the next step is often movement.

• What else can be reached?
• What credentials can be tried?
• What services respond?
• What shares are open?
• What management interfaces are exposed?

The flatter the network, the more options are available.

This is not ideal, unless your security strategy is based on being interesting to attackers.

2. Unnecessary exposure

Not every device needs to talk to every service.

• A finance laptop probably does not need direct access to network device management interfaces.
• A guest device does not need to see internal systems.
• A warehouse scanner does not need a guided tour of the server estate.
• A printer does not need to be treated as a trusted citizen of the republic.

Every unnecessary path is a possible route for misuse, error, or compromise.

3. Weak administrative protection

Administrative interfaces should not be casually reachable from general user networks.

Switches, firewalls, servers, hypervisors, backup systems, and management platforms need stronger boundaries.

If admin interfaces are broadly reachable, then password compromise, phishing, or malware becomes much more dangerous.

4. Harder incident containment

During an incident, one of the first questions is:

Can we isolate the affected area?

If the network is flat, that becomes harder. The options are often more disruptive because there are fewer clean boundaries.

Segmentation gives you levers.

Without levers, you get panic and unplugging.

Why this matters for the business

Network segmentation can sound deeply technical, but the business impact is straightforward.

Good segmentation protects:

• operational continuity
• customer data
• engineering systems
• quality and traceability systems
• finance processes
• warehouse operations
• remote access
• backups
• incident response capability

In other words, it helps stop one technical issue becoming a business-wide disruption.

That is the commercial point.

Segmentation is not an infrastructure preference, it is a resilience control.

The warning signs your network is too flat

You may have a segmentation problem if any of these sound familiar:

• user devices can reach most servers directly
• guest Wi-Fi is separated mainly by optimism
• administrative interfaces are reachable from normal user networks
• firewall rules exist but nobody is sure why
• warehouse or operational devices sit on the same network as office devices
• printers are treated as trustworthy
• VPN users land directly into broad internal access
• old rules are kept because “something might break”
• nobody is confident what traffic is actually required
• network diagrams are outdated, decorative, or technically fictional

That last one is always a treat.

A network diagram that is wrong is not documentation.

Segmentation does not mean making everything painful

This is the part worth saying carefully.

Segmentation does not mean blocking everything and watching the business suffer.

It asks:

• who needs access?
• to what?
• from where?
• for what purpose?
• through which controlled path?
• with what monitoring?
• and what should not be reachable at all?

What good looks like

A sensible segmented network usually has some clear separation between different types of systems and users.

User networks

Normal user devices should only access the services they need.

They should not have broad access to management interfaces or sensitive infrastructure.

Server networks

Servers should be grouped by role, sensitivity, or business function where appropriate.

Not every server needs to talk to every other server.

Management networks

Administrative access should be restricted.

Only authorised admin devices or jump points should reach management interfaces.

Guest networks

Guest access should be genuinely separate.

Guest should mean guest, not “internal network with a different Wi-Fi name and a vague sense of unease”.

Operational or warehouse networks

Warehouse, operational, or specialist devices may need their own treatment.

They often have different lifecycles, support constraints, and availability needs.

Backup and recovery systems

Backup systems should receive special care.

If malware can reach and damage backups as easily as it can reach user devices, recovery becomes a lot less relaxing.

How to improve segmentation without causing chaos

Do not start by redesigning the entire network in one heroic weekend.

That way lies pain, rollback, and someone quietly updating their CV.

Start with visibility.

Step 1: Map what exists

Document:

• networks and VLANs
• firewall rules
• VPN access paths
• server segments
• wireless networks
• guest networks
• warehouse or operational networks
• management interfaces
• backup systems

You do not need perfection on day one but you do need enough truth to make better decisions.

Step 2: Identify high-risk access paths

Look first for:

• user access to admin interfaces
• guest or unmanaged access to internal systems
• broad VPN access
• exposed legacy systems
• supplier access paths
• backup systems reachable from too many places
• firewall rules with no owner or business reason

Those are the spicy ones.

Step 3: Define zones

Start simple.

For example:

• users
• servers
• management
• guest
• warehouse / operational
• backup
• internet-facing services

You can refine later. Simple zones are better than an elegant design nobody can support.

Step 4: Restrict obvious unnecessary access

Do not boil the ocean.

Remove or block the paths that clearly should not exist.

For example:

• guest to internal systems
• users to network device admin pages
• broad access to backup platforms
• unmanaged devices to server networks

Step 5: Document and review firewall rules

Every inbound or inter-zone rule should have:

• purpose
• owner
• source
• destination
• service / port
• review date

If nobody can explain a rule, the rule is not necessarily wrong.

But it is definitely suspicious.

Step 6: Build change control around it

Segmentation will fail if exceptions are added casually forever.

Network access changes need to be requested, reviewed, approved, documented, and periodically revalidated.

Otherwise, today’s clean design becomes tomorrow’s mystery casserole.

The role of policy

This is where policy helps.

A good network access policy should make it clear that:

• access is granted by business need
• administrative interfaces are restricted
• guest and unmanaged devices are separated
• firewall rules require ownership and documentation
• high-risk systems need stronger boundaries
• exceptions are reviewed
• network changes follow change control

Final thought

Flat networks are easy until they are not.

They make setup easier, troubleshooting quicker, and integrations less annoying. But they also increase the damage a single compromised device, weak account, exposed service, or careless change can cause.