Network segmentation used to mean VLANs and firewall rules. That worked when users stayed in the office and applications lived in one data centre. Today, your finance team connects from home, your ERP runs in three clouds, and your production floor has sensors talking to systems in ways nobody fully documented.
The flat network is a liability. When attackers breach a single endpoint, they move laterally until they find something valuable. Recent data shows nearly 90% of organisations detected security incidents involving lateral movement in the past year, with each incident causing over seven hours of downtime on average. The traditional perimeter is gone, but the need to control who reaches what has never been more pressing.
This guide covers what network segmentation looks like in 2026, why the old approaches fall short, and how to build a practical segmentation strategy that fits European mid-market realities. You will get concrete patterns, a step-by-step implementation plan, and guidance on meeting NIS2 requirements without turning your IT team into full-time firewall administrators.
What network segmentation actually means today
Network segmentation divides your environment into zones with controlled access between them. The goal is simple: limit the blast radius when something goes wrong. If ransomware hits one workstation, segmentation prevents it from encrypting your entire file server estate.
Traditional segmentation relied on VLANs and firewall rules tied to IP addresses and ports. You carved up the network by department or floor, created rules for allowed traffic, and hoped the configuration stayed accurate as people moved around. This approach has three problems:
- IP addresses change constantly. Dynamic addressing, cloud workloads, and remote workers mean your rules go stale faster than you can update them.
- VLANs group traffic but do not enforce policy. Without additional access controls, anyone in the same VLAN can reach anything else in that segment. Attackers who land in a broad segment have room to explore.
- Firewall rule sprawl becomes unmanageable. Mid-market teams lack the capacity to maintain thousands of rules across multiple sites. Audits reveal exceptions nobody remembers creating, and incident response teams waste hours tracing which rule allowed suspicious traffic.
Modern segmentation flips the model. Instead of defining what traffic is blocked, you define what access is allowed based on identity, device posture, and application context. Everything else is denied by default.
Why segmentation matters more than ever
Three forces have converged to make segmentation a priority for 2026.
Lateral movement is the attacker’s favourite technique. Once inside, adversaries spend time mapping your network before striking. The 2025 Illumio report found that 60% of successful breaches involve lateral movement. Containing that movement early is the difference between a contained incident and a business-critical outage.
Compliance demands demonstrable controls. NIS2 requires organisations to prevent unauthorised access and lateral movement, with evidence in the form of network diagrams, configuration baselines, and access reviews. Flat networks cannot satisfy this requirement. Segmentation provides the audit trail regulators expect.
Hybrid work and cloud adoption have dissolved the perimeter. Users connect from anywhere, applications span multiple environments, and IoT devices proliferate in ways your asset inventory does not capture. Segmentation must follow the user and the workload, not the physical location.
The evolution from VLANs to identity-based segmentation
Network segmentation has moved through several generations. Understanding where you are helps you plan where to go.
| Generation | Approach | Limitation |
|---|---|---|
| VLAN-based | Static segments by department or floor | IP churn breaks rules; no identity context |
| Firewall zones | Perimeter and internal firewalls | Rule sprawl; complex management |
| Software-defined | Central controller pushes policies | Still often IP-centric; agent sprawl |
| Identity-based | Access tied to user, device, and app | Requires unified platform; cultural shift |
The shift to identity-based segmentation aligns with Zero Trust principles. Instead of asking “is this IP allowed to reach that port,” you ask “is this user, on this device, authorised to access this application right now.” The network becomes invisible to attackers because they never see resources they are not explicitly permitted to reach.
Five principles for effective segmentation
Before you touch a single policy, anchor your approach in these principles.
Start from identity, not IP. Build policies around who or what is connecting. Users, service accounts, devices, and workloads are first-class objects. IP addresses are implementation details.
Enforce least privilege by default. Grant only the minimum access required for a task. If someone needs access to the AP invoice system, they get access to the AP invoice system, not the entire finance subnet.
Validate device posture before granting access. A valid user on a compromised device is still a risk. Check OS version, encryption status, and endpoint protection before allowing connections to sensitive resources.
Cover devices that cannot run agents. Printers, cameras, IoT sensors, and industrial controllers are common blind spots. Use inline isolation to control what they can reach without requiring software installation.
Plan for incremental rollout. Big-bang migrations fail. Start with a pilot segment, prove value, then expand. Your team learns the tooling, your users adapt to new access patterns, and your documentation improves iteratively.
Segmentation patterns that work in mid-market environments
Three patterns cover most segmentation needs for organisations with 50 to 500 users.
Pattern A: Identity-centric access for users and admins
Users connect through a Zero Trust access layer that authenticates identity and checks device posture, then grants access to specific applications. No broad network access, no VPN tunnel to the entire data centre.
Administrative access uses separate roles with stronger requirements. Step-up MFA, time-limited sessions, and recorded connections for audit purposes. Administrators reach only the systems they need to manage, and their sessions are logged for compliance.
This pattern fits hybrid work, SaaS access, and remote support scenarios. Users experience fast, direct connections to applications. IT gains granular visibility into who accessed what and when.
Pattern B: Application-centric segments for data centre and cloud
Group services into small logical segments, then allow only the required east-west flows. A web server talks to its application tier, which talks to its database. Nothing else is permitted.
Use labels based on application tier, environment, and data classification. Avoid IP-centric rules that age badly. When you spin up a new container, it inherits the policy of its application group rather than requiring a new firewall exception.
This pattern works for VM and container environments across private and public cloud. It requires a solid asset inventory and consistent labelling, but the payoff is precise control over internal traffic.
Pattern C: Inline isolation for agentless and industrial devices
Place a network isolation component between unmanaged devices and the rest of the network. Printers reach print servers. Sensors reach data collectors. Nothing else gets through.
This pattern is essential for industrial environments where production equipment cannot run agents and downtime is not an option. The isolation device enforces policy at the network level, creating a bridge between IT and OT without exposing either side to unnecessary risk.
Step-by-step implementation plan
Follow this sequence to move from flat network to segmented environment. Each step produces documentation that supports NIS2 compliance.
1. Define scope and success metrics
Pick one business process and two supporting applications. Write down target outcomes: number of permitted paths, time to provision access, number of incidents contained within a segment. These metrics prove value to leadership and guide future phases.
2. Inventory identities, devices, and data
List users, admin roles, service accounts, managed devices, and agentless devices. Add data classification for each application. This inventory becomes your source of truth for policy decisions. Keep it lightweight and version-controlled.
3. Map minimal communication paths
Whiteboard the smallest set of flows the process requires. Distinguish human access from machine-to-machine traffic. Include DNS, NTP, update servers, and identity services. These supporting services are often forgotten until something breaks.
4. Choose enforcement points
Select your Zero Trust access layer for users, your application segmentation control for east-west traffic, and your inline isolation for agentless devices. The fewer consoles you need to manage, the lower your operational overhead.
5. Deploy policies in monitor mode
Write explicit allow rules for the minimal flows and keep a global deny rule. Run in monitor mode for one or two change cycles. Collect logs, compare with your inventory, and close gaps before enforcing.
6. Switch to enforcement and add just-in-time paths
Turn on blocking for anything not in your allow list. Provide a request process for exceptions with a named owner and automatic expiry. Document every exception for audit purposes.
7. Validate against compliance requirements
Record evidence that least privilege is enforced and blast radius is limited. Link your change tickets and approvals. This documentation satisfies NIS2 expectations for network security controls and access governance.
8. Automate recurring tasks
Use API calls or policy-as-code to version rules. Automate posture checks and access approvals where possible. Reduce manual work so your team can focus on incidents rather than routine maintenance.
Common mistakes and how to avoid them
- Starting with the entire network.
Pick one process, prove value, then expand. Trying to segment everything at once leads to rule conflicts and project fatigue. - Using IP addresses instead of identity.
Policies anchored to IP ranges break when addresses change. Tie access to users, roles, and device certificates. - Ignoring device posture.
A valid credential on an unpatched laptop is still a risk. Gate access on baseline device requirements. - Leaving legacy paths open.
Old VPN gateways and exposed admin portals are prime attack targets. Decommission or secure them before going live with new segmentation. - Treating segmentation as a one-time project.
Networks change. Review policies quarterly, audit exceptions, and update your inventory as new applications come online.
Meeting NIS2 requirements through segmentation
NIS2 requires organisations to implement measures that prevent unauthorised access and lateral movement. Segmentation directly addresses these obligations.
- Risk analysis and system security. Your asset inventory and communication map form the basis of risk assessment. Documented policies show how you control access to sensitive systems.
- Incident handling. Segmentation limits blast radius, making containment faster. Logs from your access layer provide forensic evidence for reporting.
- Network and information system security. Explicit allow rules demonstrate that access is proportionate and controlled. Policy versioning shows continuous improvement.
- Supply chain security. Contractor and vendor access flows through the same identity-based controls, with time-limited sessions and recorded activity.
- The key is documentation. Every policy change, every exception, every access request should be traceable. Auditors want to see not just that segmentation exists, but that it is actively managed and reviewed.
Practical examples in Belgium and Europe
Local government with distributed sites.
A Belgian municipality replaced flat network access with identity-based policies tied to role. Finance staff reach finance applications. Facilities devices like cameras and access control panels sit behind inline isolation with strict outbound rules. Central IT manages all policies from one console and produces audit-ready reports for oversight bodies.
Manufacturing plant with mixed IT and OT.
A Benelux manufacturer connected HMIs and sensors through industrial network controllers. Operators authenticate to a secure portal and receive least-privilege access to specific equipment. Maintenance access is time-limited and logged. Production stability improved because segmentation prevented test traffic from reaching live systems.
Healthcare provider with cloud EHR and on-prem imaging.
Clinicians reach EHR and imaging through posture-aware access. Imaging devices communicate only with PACS servers and update hosts. Any suspicious traffic is contained within a tiny segment, reducing the potential impact of ransomware targeting medical systems.
How Jimber supports network segmentation
Jimber delivers Real SASE in one cloud-managed platform. The architecture supports all three segmentation patterns without requiring multiple consoles or complex integrations.
- Zero Trust Network Access provides identity-based application access. Users see only the resources they are authorised to reach. Device posture gates every connection.
- Secure Web Gateway and Firewall-as-a-Service enforce consistent policy for outbound traffic, blocking malicious destinations and enforcing acceptable use.
- SD-WAN connects sites with secure, resilient links. Traffic flows through the policy engine, ensuring segmentation follows users across locations.
- NIAC hardware creates an IT-OT bridge for devices that cannot run agents. Printers, IoT sensors, and industrial equipment sit behind inline isolation with explicit allow rules.
- Single management console reduces operational overhead. One interface for policies, visibility, logging, and reporting. API-first design supports automation and multi-tenant operations for partners.
The result is segmentation that scales with your organisation. No rule sprawl, no agent conflicts, no separate tools for each environment.
Ready to move beyond flat networks and firewall rule sprawl? Book a demo and see how identity-based segmentation works in practice for organisations like yours.
Metrics to track before and after
Measure these outcomes to demonstrate value.
- Number of reachable services per role. Lower is better.
- Mean time to provision new access. Faster indicates a working process.
- Number of east-west blocks that prevented lateral movement. Evidence of segmentation in action.
- Percentage of agentless devices behind inline isolation. Shows coverage of blind spots.
- Tickets related to broad access versus per-application access. Trend should shift toward granular requests.
- Audit findings related to least privilege. Should decrease over time.
Frequently asked questions
Is network segmentation only for large enterprises?
No. Mid-market teams can start with identity-centric access for one application and inline isolation for agentless devices. The principles scale down as well as up.
Do I need new hardware to implement segmentation?
Not necessarily. A Zero Trust access layer and software-defined policies can deliver strong segmentation without a hardware refresh. Inline isolation appliances are required only for devices that cannot run agents.
How does segmentation support NIS2 compliance?
NIS2 requires controls that prevent lateral movement and demonstrate proportionate access. Segmentation provides the technical foundation. Documentation of policies, exceptions, and logs provides the audit evidence.
What about devices that cannot run agents?
Use inline isolation. The device sits behind a network component that enforces policy without requiring software installation. Traffic is restricted to explicit allow rules.
How do we handle contractors and temporary staff?
Apply the same identity-based policies with additional constraints. Time-limited access, device posture checks, and recorded sessions. When the engagement ends, access expires automatically.
