Separate network zones joined by a small number of controlled teal bridges

Network segmentation

Give every connection a clear boundary.

Reduce unnecessary reach across your network with a design built around real business dependencies.

LIMIT UNNECESSARY REACH

A connection should have a purpose.

Segmentation separates parts of a network and controls the communication between them. Its value comes from enforced boundaries that match your applications and operating needs.

People

Users reach approved services through defined access paths.

Business applications

Application components communicate over documented, necessary routes.

Privileged administration

Management access follows a separate, tightly controlled path.

Recovery systems

Backup and recovery infrastructure has its own access boundaries.

Illustrative zones—not a proposed design for every organization. The appropriate boundaries depend on your infrastructure, business dependencies and management capabilities.

THE PROBLEM WITH BROAD CONNECTIVITY

One compromised device should not have every route.

Flat or loosely controlled networks can allow an attacker to explore systems beyond the initial entry point. A useful design reduces unnecessary reach while preserving legitimate business traffic.

The difficult part is often discovering what actually needs to communicate. Legacy applications, shared identity services, supplier connections and operational technology may depend on routes that are poorly documented.

We start with those dependencies. The objective is a manageable set of boundaries and rules, with clear ownership, evidence and a safe implementation sequence. Segmentation contributes to resilience alongside identity, endpoint protection and monitoring; it does not replace them.

A RULE THAT CAN BE EXPLAINED

Build a connection register.

Source → destination

Identify the initiating system or role and the service it must reach. Prefer specific, maintained groups over broad address ranges without a clear owner.

Business purpose

Explain what stops working if the connection is removed. “It has always been there” is a reason to investigate, not a durable justification.

Protocol & access conditions

Document the required service, authentication and access conditions. Network permission and application authorization solve different parts of the problem.

Owner & review date

Assign someone to approve continued access. Temporary supplier and project routes should have an expiry or a documented review decision.

Discuss your network boundaries

DESIGN AROUND OPERATIONS

Protect critical routes. Avoid surprise outages.

Map before enforcing

Collect application dependencies and available traffic evidence. Include identity, naming, time synchronization, monitoring and recovery services—not only the primary application.

Start with a bounded change

Choose a manageable zone or service, define expected traffic and agree the test window. Establish what will be monitored and who can approve a rollback.

Test legitimate workflows

Have service owners validate the tasks that matter. A successful connection test does not prove that an entire business process works across the new boundary.

Keep exceptions visible

Record why a temporary allowance is needed, its owner and its end date. Review the exception after the dependency is resolved rather than leaving a permanent bypass.

COMMON SHORTCUT

A VLAN label alone is not the outcome.

Separating addresses or naming a zone does not establish which communications are permitted. If broad routing and administrative access remain, the intended isolation may not exist.

A MORE USEFUL QUESTION

Which routes are enforced and how do we know?

Review the actual policy, the traffic it allows and the evidence from testing. Confirm that unauthorized routes are restricted and that legitimate applications still operate.

WHAT THE WORK LEAVES BEHIND

A design your team can operate.

Dependency map

A scoped picture of zones, critical services and required communications. Unknowns are identified so they can be investigated before enforcement.

Prioritized design

Proposed boundaries, rule changes and exceptions, with the business reason and implementation dependencies for each.

Validation plan

An agreed change sequence, acceptance checks, rollback criteria and ownership for ongoing rule maintenance.

For industrial or safety-sensitive environments, changes require the relevant operational owners and specialist controls. Testing and implementation must respect availability and safety constraints.

QUESTIONS, ANSWERED

A clearer next step.

Practical answers before you decide how to move forward.

Is segmentation the same as installing a firewall?

A firewall may enforce some boundaries, but segmentation is a design and operating practice. It also requires dependency mapping, policy ownership, testing and maintenance.

Will segmentation prevent every ransomware incident?

No. It can reduce unnecessary communication paths and help containment, but attackers may exploit allowed routes or compromised identities. It belongs within a broader security and recovery approach.

Can we start without redesigning the entire network?

Yes. A focused review can identify a critical service or high-risk boundary to address first. The scope should be small enough to understand and validate while supporting a broader direction.

What about legacy applications?

Identify their communication dependencies and constraints before changes. Where a requirement cannot be removed, document a justified exception and consider additional controls.

Does this include cloud networks?

Cloud network boundaries can be included when explicitly scoped. Identity permissions and application access must also be considered because network location alone does not establish trust.

How do we reduce the risk of outages?

Use evidence-led mapping, owner-approved change windows, defined acceptance tests and rollback criteria. Validate complete business workflows after important changes.

Who maintains the rules afterward?

Agree a rule owner and approval process as part of the design. New systems, supplier connections and application changes should trigger a review of the relevant boundaries.

What information helps us begin?

A high-level network diagram, critical application list and known connectivity concerns are useful. Sensitive configurations should be exchanged only through an agreed secure route.

FROM THE RANSOM SECURE BLOG

Keep building your understanding.

Practical reading to help your team turn the conversation into action.