Source: Gartner - Written by Adam Hils, Andrew Lerner
10 June 2025 - ID G00811205
Gartner’s latest research reveals why so many segmentation initiatives fall short and outlines six essential principles security and risk leaders need for success in hybrid and multicloud environments.
Modern enterprises are under mounting pressure to reduce risk, contain lateral movement, and secure hybrid networks. Yet network segmentation projects continue to fail at alarming rates due to complexity, outdated approaches, tool sprawl, and overambitious project scopes.
This Gartner research provides clarity. You’ll learn what leading organizations are doing differently and how alignment, design discipline, and automation are transforming segmentation outcomes.
Inside the report, Gartner highlights:
Why segmentation failure rates remain high—and the common pitfalls organizations overlook.
How shifting hybrid work models are changing segmentation priorities.
Why design-first strategies outperform tool-driven deployments.
How “coffee shop networking” and cloud sprawl reshape segmentation requirements.
Why automation and continuous improvement are now essential for sustainable segmentation.
Six foundational principles that guide effective segmentation across hybrid and multicloud environments.
Overview
Enterprises struggle with network segmentation challenges, including high failure rates and outdated implementation practices. This research provides security and risk management leaders with six key principles for network segmentation success in hybrid or multicloud environments.
Key Findings
The failure rate for network segmentation projects is high in organizations due to complexity and poor planning.
A “big bang” mindset among project leaders will inevitably lead to project failure. Most network segmentation projects fail due to overambitious project sizes.
Network segmentation vendors are pushing GenAI messages that promise to automatically segment everything.
Shifting hybrid working from remote back to on-premises is a priority for many organizations — reprioiritizing network segmentation over secure remote access
Simple “coffee shop networking” is emerging, driving the need for segmenting these environments.
Haphazard adoption of vendor tools and poor oversight of the implementation constraints of the environment often lead to suboptimal network architectures.
Recommendations
Recalibrate ownership and accountability expectations in network segmentation projects with all relevant stakeholders by shifting to a continuous improvement approach.
Adopt tool-agnostic design principles and mandate automation capabilities that best fit the company’s security.
Design first, pick the tool second. Don’t let the tool drive the design, and remember that more zones does not equal better security.
Incorporate any strategic direction to implement “coffee shop networking” plans for branches into the strategy as these are naturally segmented environments.
As hybrid work shifts back to primarily on premises for many organizations, reprioritize on premises network segmentation over secure remote access projects.
Introduction
As organizations continue to migrate to hybrid data centers and a more mobile workforce with “coffee -shop networks”, conventional wisdom and best practices surrounding network segmentation have become outdated. Coffee shop networking is a combination of technologies that enables a simplified and consistent employee experience regardless of the employee’s location. The user experience is to grab a seat, connect and work from anywhere. The same experience applies whether the employee is in the office, at a coffee shop or working from home. Enterprises typically refer to coffee shop networking in the context of simplifying their campus and branch office networks.
Recent evolutions in suggested technology and network security mandates often miss the mark when it comes to ensuring a balanced set of security controls with manageable costs (in terms of both capital expenditure and human resources). Vendor claims that these problems can be magically solved with Gen AI tools that “autosegment” based on context are typically unrealistic.
Security and risk management (SRM) leaders aiming to drive successful network segmentation often reach out to Gartner analysts to help solve their critical implementation issues with statements like “We failed an audit,” “The project is stalled,” “We are still at the drawing board after six months,” and “The selected technology simply does not work”).
This research summarizes insights gathered through hundreds of client inquiries over the past few years, outlining the six most important aspects of successful network segmentation projects:
Start small and build network segments incrementally
Build governance for accountability
Separate zoning design from implementation
Automate enforcement of segmentation
Include network segmentation in a global security design
Unify policy management
Analysis
Start Small and Build Network Segments Incrementally
Large and overly ambitious network segmentation projects typically fail more often than smaller ones but are still more frequently attempted. Gartner recommends breaking segmentation implementation into manageable chunks by treating each network — such as a branch network, campus network, data center or public cloud — as a separate building block with differentiated requirements and objectives. For example, a local-area network (LAN) is typically flatter and has the lateral movement of ransomware as its most frequently identified threat vector and has the lateral movement of ransomware as its most frequently identified threat vector according to anecdotal evidence from Gartner enquiries. Data centers have more mature zoning principles but will have to deal with major upheaval when moving to hybrid and/or multicloud designs.
Each of these blocks becomes a subproject, typically prioritized by business need and implementation feasibility, with shared technology stacks (see the section of this research about unifying policy management).
For existing assets within each of the subprojects, identifying a shortlist of “quick wins” — relatively small changes that help to improve security posture — is typically the first step. This could be as simple as applying simple access control lists to user segment interfaces, or applying basic segmentation rules to a larger environment. SRM leaders should use these steps to show progress while testing the new approaches on a smaller scale, in addition to reducing risk when tackling the more complex aspects of the projects.
SRM leaders and their teams should also start zoning implementation opportunistically together with new app or infrastructure deployments (i.e., a line-in-the-sand approach) to further reduce the risk of disruption during the learning period. This also helps tune processes and configure tools at a smaller scale, without the additional burden of legacy tech and processes.
Build Governance for Accountability
One of the key functions of governance is to define acceptable risk and manage accountability. A common challenge for broad-scale network segmentation projects is the difficulty in identifying respective ownership and accountability. In most organizations the CIO is, from the security risk perspective, the accountable owner. The CIO might delegate responsibility for managing different aspects of risk to the security, network and cloud operation teams. Access to project resources (e.g., developers) needed to implement some security control and automation aspects might be under the control of the resource owner (business or application leader).
To overcome such conflicts, SRM leaders should prepare a risk-mitigation strategy before starting any network segmentation project.
Gartner has identified four common conflicts that will require arbitration:
Risk tolerance: Different resource owners have different risk appetites. Cybersecurity leaders must prepare a range of options to facilitate residual risk ownership.
Implementation of security controls: The segmentation enforcement technology might modify the continuous deployment process (e.g., by adding an agent). The security zones might conflict and complicate the existing infrastructure (e.g., cloud “security groups;” required switch upgrade).
Policy-change management: Immature asset discovery and categorization might lead to too many exceptions and affect change SLAs.
Operational control: Infrastructure components used in segmentation projects (i.e., routers, switches, virtual switches, firewalls, etc.) are usually split between security and network teams. SRM leaders must work with senior security and networking leaders to align goals and efforts to avoid conflicts.
When external forces (e.g., vendor marketing, “zero-trust” hype) interfere with the objectives of the project, the first step is to recalibrate overinflated expectations so that a narrower scope, residual risks, multiple steps and complementary projects become acceptable. SRM leaders should consider assessing a range of options, in terms of zoning design and tools, instead of relying on a single-design, universal approach.
Separate Zoning Design From Implementation
Keep Zoning Design ‘In House’ With Documented Design Principles
Many segmentation projects get stalled because the selected technology either cannot deliver at scale or isn’t available in all the required environments. Establishing segmentation policies, which exist independently of the specific tools required to enforce or implement them, fosters portability across environments.
The starting point for such a zoning strategy should be business rules and logic (for example, “Development shouldn’t talk to production directly, in accordance with regulatory requirements”).
SRM leaders should build their zoning strategies separately from the specific implementation constraints of the environment. In other words, they should design first and pick the tool second. Building a zoning design that is initially freed from enforcement tools, features or limitations opens more possibilities, allows scalability beyond a single environment and removes the pressure to “add more zones.” Remember that more zones don’t always imply better security. Applying these zoning principles should start with new deployments, preferably where there was also an initial investment in automation. Since it is more complex to retrofit zones on legacy infrastructure, this might occur much later as part of an infrastructure modernization. Alternatively, compensatory measures might prove to be a better investment.
Mix and Match Zoning Governing Principles as Needed
Zones should be designed in steps of increasing granularity. While location-based zoning might work for the first level of separation, other criteria will be a better fit as an organization aims at more granular zoning. There is no one principle that is better than the others, and the best grouping criteria vary for each organization. For each project, SRM leaders should combine multiple characteristics to achieve a harmonious zone design (see Figure 1).
Figure 1: Mix and Match Zoning Governing Principles
Initial zoning steps typically include:
Splitting workstations from servers: This is the first step toward moving away from a flat design as it provides the ability to filter administrative access, to inspect traffic for detecting lateral movement and to prevent ransomware infections.
Grouping by physical location: Common network groupings are campus/branch and on-premises data center/infrastructure as a service (IaaS).
Separating data center zones: Separate production from nonproduction, development from QA, and databases/data stores from non-data stores. For on-premises systems, this reduces the attack surface for both partner-facing and employee-facing applications. In the cloud, user authentication and other alternate controls replace access lists for inbound traffic.
Grouping similar assets: Common grouping categories include Internet of Things, operational technology, groups of applications (“application fencing”), databases and core services.
Splitting high-risk assets: Segregate network assets based on their level of risk, such as compliance (Payment Card industry Data Security Standards (PCI DSS), critical infrastructure), risk rating (high/medium/low) and data categorization (highly confidential, internal).
Aligning with authentication strategy: Group unauthenticated public assets separately from authenticated private entities.
Following these initial decisions, security teams should define more granular zones when:
The discovery/inventory of assets and flows are reliable and easy.
The frequency of policy change is compatible with agreed service levels and available tools.
The related attack surface reduction provides higher benefits than investment in other controls.
Automate Enforcement of Segmentation
The rise of cloud infrastructure has impacted asset life cycles, deployment automation and network security integration. It has also opened new ways of segmenting assets, is better suited to hybrid environments, and offers a different set of capabilities from on-premises security technologies (see Table 1). Instead of arbitrarily shifting third-party on-premises security tools to IaaS environments, SRM leaders need to apply native tools (security groups, network access control lists) on the public cloud.
Table 1: Enforcement of Segmentation in the Cloud
Feature requirements | Deployment options | Potential challenges |
|
|
|
|
|
|
Source: Gartner
Too often, security leaders see implementing network segmentation in the cloud as an easy problem to solve, inflating their expectations. The promise of the new security tools often diverts them toward adding as many zones as possible, frequently aiming at individual assets or event applications. The complexity of the resulting policy not only leads to frequent changes, but also makes the resulting architecture less scalable. To overcome this, SRM leaders should pick an enforcement technology that best supports their specific infrastructure and policy automation, not the one that promises the highest number of zones. Investing in network security policy management further streamlines management across heterogeneous environments. Additional tools can be used to fill automation and security layer gaps if and when needed.
To improve the chances of success, security teams should:
Redirect the compass away from more zones and toward more automated deployment. The selected technology must fully integrate with — or at least not be in the way of — the cloud automation.
Not rely on fully automated AI to continuously assess and automatically segment the network due to the risk of inaccuracies that could cause operational impact.
Select the technology that integrates well with the defined policy workflows, including accountability for policy changes.
Narrow the initial scope and test the new technologies and workflows on a well-defined and controlled set of applications.
Mandate deep automation capabilities, including published open Restful API and GA integrations with popular tools, such as Ansible and Terraform.
Include Network Segmentation in a Global Security Design
Most network segmentation designs are entirely built as siloed projects that are disconnected from other infrastructure. Network segmentation possibilities might be limited by organizational constraints or technical dependencies (such as insufficient automation). In the design, include the possibility of “coffee shop networking,” which creates natural segments that are automatically isolated. Even when building very granular zones, network segmentation remains only the foundational control, protecting against a limited set of risks (see Table 2).
Table 2: Aligning Network Security Controls With Threats
Network security control | Threat |
Monitoring and analytics |
|
Policy management |
|
Data leakage prevention |
|
Threat prevention |
|
Identity and access management |
|
Application protocol analysis |
|
Encryption tunneling |
|
Network segmentation |
|
|
|
Source: Gartner
Network segmentation zones should be associated with a set of complementary controls and detections, and focused on threat detection and security monitoring. SRM leaders need to understand that adding more zones is not a replacement for effective threat inspection and security monitoring. Instead, they should provide a range of options, anticipating not only the transition period when the final design is not yet implemented, but also addressing the residual risks that are not covered by segmenting the network.
The deployment of complementary controls and related processes in these project steps can sometimes create too much operational complexity. However, SRM leaders can manage these dependencies by highlighting what is covered, and what remains to be secured, at every step of the segmentation project, keeping the broader context of the network security design in mind.
Unify Policy Management
Hybrid/multicloud designs have greatly expanded the scope and complexity of firewalling and given rise to scalability and fragmentation problems in security policy management. More advanced — and multibrand — network security policy management products are available today, but they won’t solve everything, because policy change complexity depends on too many factors (see Table 3).
Table 3: Policy Management Complexity
Role | Centralized management | Enforcement |
|
|
|
|
|
|
SRM leaders need to be wary of selecting a segmentation technology without considering how it will integrate into a policy-change workflow for inbound, outbound, internal and intersite traffic patterns. They should consider automated discovery tools when the inventory of existing assets is lacking. Someone should be made responsible for vetting the recommended policy, as well as applying the new policy. Automating policy recommendation is not even half of the job. To effectively communicate the scope of policy changes, security teams often build a set of progressive SLAs to clarify what can and cannot be done at the same time as they are building the new architecture.
Today’s GenAI will not fully automate segmentation without human oversight. Before considering their technology options for enforcing the policy, network security teams need to define the following workflows:
Asset and application inventory management: Static databases of assets are rarely enough to ensure the relevant coverage of all the assets and applications to be secured. Automated discovery and interteam collaboration might also be required.
Business change requests: There will be more than one way for the business to request changes, depending on the type of project and the environment. The most difficult part of defining these workflows is documenting who is in charge of deciding, submitting and approving the changes.
Operational SLA development: Gartner sees that initial project scoping documents often contain change SLAs that are too ambitious. It will take more time than expected to get a fully functional change process. By advertising intermediary SLAs, SRM leaders ensure that every team can plan accordingly.
Exception handling: There will always be exceptions to the defined workflow. In addition to the expedited approval process for emergencies, documenting policy exceptions — with the ability to track back not only the stakeholder but also the justification for the change — is necessary.