arXiv CSopen access

Why Network Segmentation Projects Fail

Why Network Segmentation Projects Fail Rohit Dube

arXiv:2604.08632v1 [cs.CR] 9 Apr 2026

Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134 USA Abstract—Network segmentation is a foundational enterprise security control. Despite its recognized benefits, segmentation initiatives frequently fail in practice, and the field lacks a systematic empirical explanation for why these projects do not achieve their intended outcomes. This paper presents an empirical study of failed segmentation projects based on a survey of 400 U.S.-based network security practitioners. The survey was grounded in a two-part failure framework that separately measures general IT project failure factors and segmentation-specific technical and operational barriers. Clustering analysis of the responses reveals four distinct failure archetypes. Surprisingly, practitioners across all four archetypes propose general IT project management fixes over segmentation-specific fixes in the same ratio.

This paper addresses that gap by presenting an empirical study based on a survey of network security practitioners with direct experience in failed segmentation projects. Practitioner perceptions are both a valid and important source of evidence, as these practitioners are the actors making design and implementation decisions during segmentation projects. A survey-based approach was chosen to gather practitioner views over alternatives such as interviews or focus groups because a survey enables a sample size large enough to support statistical analysis of failure patterns. The study captures perceptions across project management and technical dimensions of failure and applies quantitative clustering techniques to identify failure archetypes.

Index Terms—Computer Networks, Network Security, Network Segmentation, Clustering

The analysis reveals four distinct failure archetypes— Perfect Storm, Diffuse Friction, Operational Drag, and Scope & Visibility Trap—ranging from projects where every factor contributed simultaneously to projects where governance was sound but specific segmentation challenges proved decisive. The archetypes are associated with distinct project characteristics: projects involving campus networks and traditional Layer-2 macro-segmentation are more likely to experience the broadest or most technically intense failures, while the archetypes do not significantly differ by workload type or failure type. Despite diagnosing markedly different failures, practitioners across all four archetypes propose general IT project management fixes over segmentation-specific fixes in the same roughly 70/30 ratio, suggesting that segmentation-specific interventions may need to be explicitly prioritized when technical root causes are identified.

1. Introduction Network segmentation is widely regarded as a foundational control in modern enterprise cybersecurity architectures because it reduces attack surface, constrains lateral movement, and enables more granular enforcement of security policy. Prior research demonstrates that segmented networks significantly outperform flat networks in resisting malware propagation and unauthorized access, with empirical studies showing that simulated attacks are contained entirely within isolated segments rather than spreading across enterprise infrastructure [1]. Similarly, academic and practitioner-oriented analyzes emphasize segmentation as a core defense-in-depth mechanism that supports leastprivilege access, breach containment, and regulatory compliance, even as it introduces additional operational and management complexity [2]. At the same time, prior work highlights that while segmentation is clearly beneficial, guidance on designing and applying effective segmentation architectures remains vague, forcing practitioners to rely heavily on judgment when making segmentation decisions [3]. Practitioners consistently report that network segmentation initiatives often fail to achieve their intended outcomes or are abandoned before completion. These failures are well known anecdotally in industry practice, yet neither the academic literature nor practitioner-focused publications provide a systematic, empirical examination of why segmentation deployment projects fail.

The remainder of this paper is organized as follows. Section 2 reviews prior academic and practitioner work relevant to IT project failure and network segmentation challenges. Section 3 introduces a general framework for IT project failure and describes how its constructs are measured in an empirical study. Section 4 complements this framework to include the unique considerations of segmentation projects and details the corresponding measurement constructs. Section 5 develops network segmentation failure archetypes from the survey results. Section 6 analyses practitionerproposed solutions to segmentation failures. Section 7 points out the limitations of our work, and Section 8 concludes with a summary of our work.

2. Related Work A substantial body of research has examined why IT projects fail across different organizational contexts. Early empirical work demonstrated that project failure is associated with a set of managerially controllable factors whose relative importance varies by project type and lifecycle stage, challenging the view that failures are idiosyncratic or purely technical [4]. Large-scale empirical studies further show that cost overruns, delays, and benefit shortfalls are not explained by project complexity alone but instead reflect planning and governance deficiencies [5]. Research focusing on practitioner perceptions highlights how failures emerge through causal chains, with communication and cooperation failures acting as bridge causes across dimensions [6]. Indepth investigations of failed government IT projects find that most root causes originate outside of programming activities and instead reflect deficiencies in early problem formulation, requirements understanding, and organizational decision-making [7]. Synthesis work spanning more than three decades confirms strong consistency in these findings over time [8], while studies of project complexity emphasize that failure factors cluster, reinforcing the need for multidimensional frameworks [9]. Industry reports provide consistent evidence that segmentation initiatives encounter failure mechanisms distinct from general IT project challenges and rooted in the technical and operational properties of modern enterprise environments. A large-scale industry survey identifies a convergent set of technical barriers—architectural complexity, insufficient asset visibility, difficulty mapping communication flows, manual policy burden, and tooling limitations—as the primary segmentation challenges [10]. The same study shows that segmentation efforts frequently stall despite high organizational prioritization, with only one-third of respondents reporting full implementation of both macro- and micro-segmentation, indicating that failure may arise from incomplete environmental understanding rather than insufficient intent or governance [10]. Independent industry analysis reinforces these conclusions, reporting that segmentation initiatives commonly stall at the pilot or partial deployment stage due to concerns about policy safety and application outages, even though segmentation is widely recognized as strategically important [11]. Earlier industry survey results similarly note that lack of internal expertise and perceived operational risk slow segmentation progress, leading many organizations to limit enforcement scope despite acknowledging segmentation’s effectiveness [12]. Taken together, these industry studies motivate the need for a dedicated segmentation project failure framework distinct from general IT project failure models. Prior work has established the security benefits of network segmentation through analytical studies, simulations, and experimental evaluations, while also noting the practical difficulty of selecting, designing, and maintaining segmentation architectures [1], [2], [3]. Recent taxonomy work highlights the lack of empirical studies examining segmentation outcomes in real deployment and organizational set-

tings [13]. Complementary formal-methods research further highlights that segmentation guidance is often vague or underspecified, making it difficult to apply consistently or scale to large, complex environments without relying heavily on expert judgment [14]. This study addresses the gaps by translating the identified challenges into concrete failure factors, examining segmentation project failures from practitioner perspectives, and connecting segmentation outcomes to both general IT project failure causes and segmentationspecific challenges.

3. General IT Project Failure Framework In this section, we synthesize prior findings on general IT project failures into a concise framework suitable for empirical measurement. The framework emphasizes general, managerially controllable factors that recur across project types and remain stable over time despite changes in technology. The first dimension of the framework concerns strategic alignment and governance. Failures in this dimension originate from unclear project goals and insufficient leadership sponsorship or decision-making authority. Weak alignment at project initiation creates ambiguity around priorities and success criteria, which can constrain effective planning and coordination. Governance deficiencies further limit the organization’s ability to allocate resources, resolve conflicts, and respond to emerging risks during delivery [4], [8]. The second dimension addresses requirements and scope management. Unstable requirements disrupt estimation, sequencing, and coordination, and often propagate execution problems even when governance structures are nominally in place. Prior research shows that requirements-related issues frequently act as connective mechanisms linking strategic weaknesses to execution breakdowns [6], [7]. The third dimension combines project planning, execution, and control. This dimension captures both the realism of initial feasibility assumptions and the effectiveness of ongoing managerial oversight during delivery. Unrealistic schedules or resource assumptions increase exposure to failure by establishing infeasible baselines [5]. However, failure often materializes through inadequate monitoring, delayed risk response, or ineffective corrective action rather than through planning deficiencies alone [8]. The final dimension concerns coordination and communication among stakeholders. Unlike the preceding dimensions, coordination and communication tend to permeate all phases of the project lifecycle. Communication breakdowns amplify the effects of governance gaps, unstable requirements, and execution challenges by impeding shared understanding and timely decision-making. As project complexity and interdependence increase, coordination failures become more frequent and more consequential [6], [9]. Taken together, these dimensions form a concise and conceptually coherent framework for general IT project failure. The framework reflects a progression from strategic foundations, through definition and delivery, while explicitly accounting for universal coordination mechanisms. Table 1

summarizes the mapping between the framework dimensions and prior literature used to ground this synthesis. This framework provides a theoretical basis for the quantification and empirical analysis presented in subsequent sections. To make these dimensions empirically tractable, we operationalize each as one or two Likert-scale1 survey items as shown in Table 2 [15]. Items B1 and B2 measure strategic alignment and governance, capturing goal clarity and leadership sponsorship respectively. Item B3 measures requirements and scope management through experienced scope creep and changing requirements. Items B4 and B5 jointly measure project planning, execution, and control: B4 captures the realism of timelines and resources, while B5 captures the effectiveness of ongoing risk identification and corrective action during delivery. Item B6 measures coordination and communication among stakeholders.

4. Segmentation Project Failure Framework Building on the general IT project failure foundation, this section introduces a complementary framework that captures failure mechanisms specific to segmentation projects. As summarized in the related work section (Section 2), industry studies consistently show that segmentation initiatives encounter technical and operational barriers that are not adequately explained by traditional IT project failure constructs. Accordingly, the framework focuses on failure mechanisms arising from characteristics unique to segmentation. The first framework component is architectural and environmental complexity. Segmentation projects are often implemented across on-premises data centers, cloud platforms, containers, and legacy systems. Heterogeneity in infrastructure types complicates consistent policy design, deployment, and enforcement, increasing the likelihood of stalled or partial implementations [10]. The second component is insufficient visibility into assets and workloads. Segmentation depends on an accurate understanding of assets, workloads, and their roles within the environment. When asset visibility is incomplete, segmentation policies become either overly permissive or operationally risky, undermining project objectives [10]. Closely related is the difficulty of identifying legitimate communication flows. Segmentation requires distinguishing required system-to-system communication from unnecessary or risky traffic. Uncertainty in communication patterns leads to repeated policy revisions and prolonged pilot phases, limiting progress toward enforcement goals [10]. The framework further includes policy lifecycle and operational burden. Segmentation policies must evolve continuously as applications change and environments scale. High manual effort in policy creation and maintenance increases operational burden and reduces long-term sustainability [10]. 1. All items used a five-point agreement scale: 1 = Strongly disagree, 2 = Slightly disagree, 3 = Neither agree nor disagree, 4 = Slightly agree, 5 = Strongly agree.

Figure 1. Radar plot of medians for LCA clusters.

Another component is tooling maturity and automation limitations. Effective segmentation requires tooling that supports discovery, policy management, enforcement, and validation at scale. Limitations in tooling maturity or integration increase operational overhead and constrain deployment scope [10]. Finally, the framework includes risk of business disruption. Segmentation misconfigurations can directly disrupt application availability or performance. Perceived outage risk often constrains enforcement decisions, leading organizations to limit segmentation to lower-risk areas [12]. Each segmentation framework component is operationalized using a Likert-scale survey item as shown in Table 3 [15]. Item C1 captures architectural and environmental complexity, while C2 measures the degree to which insufficient asset visibility constrained policy design. Item C3 assesses the difficulty of identifying legitimate communication flows between systems. Item C4 evaluates whether excessive manual effort in policy creation and maintenance undermined sustainability, and C5 captures the extent to which tooling limitations contributed to failure. Item C6 measures the degree to which concerns about application outages or business disruption constrained deployment.

5. Segmentation Failure Archetypes Figure 1 previews the four failure archetypes identified by the analysis—Perfect Storm, Diffuse Friction, Operational Drag, and Scope & Visibility Trap—each characterized by a different pattern of failure attribution across general IT project management factors (B factors) and segmentation-specific technical factors (C factors). The remainder of this section describes how these archetypes were derived and what distinguishes them.

TABLE 1. M APPING OF IT P ROJECT FAILURE F RAMEWORK D IMENSIONS TO P RIOR L ITERATURE . Framework Dimension Strategic Alignment & Governance Requirements & Scope Management Project Planning, Execution & Control Coordination & Communication

Key Failure Aspects Unclear goals, weak sponsorship, insufficient decision authority Scope creep, changing or unclear requirements Unrealistic schedules, resource misalignment, inadequate monitoring, weak risk management, delayed corrective action Poor stakeholder coordination, ineffective communication

Representative Studies Pinto and Mantel [4]; Schmidt [8] Lehtinen et al. [6]; Lauesen [7]; Schmidt [8] Pinto and Mantel [4]; Budzier and Flyvbjerg [5]; Schmidt [8]; Montequı́n et al. [9] Lehtinen et al. [6]; Montequı́n et al. [9]

5.1. Determining the Number of Clusters TABLE 2. S URVEY I TEMS M EASURING G ENERAL IT P ROJECT FAILURE FACTORS . Item B1 B2 B3 B4

B5

B6

Survey Question (Agreement Scale) Goals were unclear or inconsistently defined at the outset. Senior leadership sponsorship and project leadership were insufficient. The project experienced scope creep or changing requirements. The project timeline was unrealistic given the available resources. Issues and risks were not identified, tracked, or addressed effectively during project execution. Coordination and communication among stakeholders were ineffective.

Framework Dimension Strategic Alignment & Governance Strategic Alignment & Governance Requirements & Scope Management Project Planning, Execution, & Control Project Planning, Execution, & Control Coordination & Communication

TABLE 3. S URVEY I TEMS M EASURING S EGMENTATION P ROJECT FAILURE FACTORS . Item C1

C2

C3

C4

C5

C6

Survey Question (Agreement Scale) The complexity of the environment (e.g., hybrid cloud, containers, legacy systems) made segmentation difficult to implement successfully. We lacked sufficient visibility into assets to design effective segmentation policies. Identifying legitimate communication flows between systems was more difficult than anticipated.

Segmentation policies required excessive manual effort to create and maintain. Limitations or immaturity of segmentation tools (including thirdparty products) contributed significantly to project failure. Concerns about application outages or business disruption constrained how fully segmentation could be deployed.

Framework Dimension Architectural and Environmental Complexity Insufficient Visibility

Asset

Difficulty Identifying Legitimate Communication Flows Policy Lifecycle and Operational Drag Tooling Maturity and Automation Limitations Risk of Business Disruption

TABLE 4. D ESCRIPTIVE STATISTICS FOR L IKERT- SCALE VARIABLES .

B1 B2 B3 B4 B5 B6 C1 C2 C3 C4 C5 C6

Min

Max

Median

Mean

SD

1 1 1 1 1 1 1 1 1 1 1 1

5 5 5 5 5 5 5 5 5 5 5 5

4.0 4.0 4.0 4.0 4.0 4.0 4.0 4.0 4.0 4.0 4.0 4.0

3.8 3.8 4.1 4.1 3.8 3.9 4.1 4.1 4.1 4.1 4.1 4.2

1.1 1.1 0.9 1.0 1.1 1.0 0.9 0.9 0.9 0.8 0.9 0.9

A survey containing the Likert-scale items and some related questions was conducted in late February and early March of 2026 and 400 responses from U.S.-based network security practitioners were obtained (see Appendix A for details). Table 4 summarizes the 12 items. All items have a median of 4.0 and similar means (3.8–4.2), with C factors (C1–C6) marginally higher than B factors (B1–B6), yet the full 1–5 range is used for every item. This combination of homogeneous aggregate statistics and substantial individuallevel variability suggests that distinct subgroups with different failure attribution patterns may be present: motivating the use of a clustering technique (latent class analysis) that can recover them. Latent Class Analysis (LCA) is a model-based clustering technique. It assumes that observed survey responses come from a mixture of distinct, unobserved subgroups, each with its own response pattern. For a given number of classes K , the model estimates two things: (i) the probability of selecting each response option (1–5) on each Likert item for each class, and (ii) the proportion of respondents in each class. These parameters are estimated using the ExpectationMaximization (EM) algorithm [16]. The EM algorithm alternates between two steps: computing each respondent’s probability of belonging to each class based on their responses (E-step), and updating each class’s response probabilities to best explain the data (M-step). Each respondent is assigned to the class with the highest posterior probability. To guard against convergence to local optima, for each value of K the EM algorithm was run 100 times with different random ini-

tializations, and the solution with the highest log-likelihood was retained for that model.2 Unlike distance-based methods, LCA treats each Likert item as categorical and models the full distribution of responses within each class. This makes it well suited for ordinal survey data [17], [18].3 4 Choosing the right number of classes requires fitting models for a range of K values and comparing them. Two commonly used measures are the Bayesian Information Criterion (BIC) and the Akaike Information Criterion (AIC). Both weigh model fit against complexity, but BIC penalizes additional parameters more heavily and is often recommended as the primary guide for class enumeration [19], [20]. Because BIC applies the strongest parsimony correction among common information criteria, it can favor simpler solutions even when additional classes capture meaningful structure. In such cases, the rate of change in AIC provides a useful complement: when the improvement in AIC shrinks sharply, adding more classes offers diminishing returns [20], [21]. Relative entropy measures how cleanly respondents are sorted into their assigned class, on a scale from 0 to 1, with values above 0.80 indicating high classification certainty and values below 0.60 suggesting poor separation [22], [23]. Entropy should not be used as a selection criterion on its own, as it tends to increase mechanically with the number of classes [24]. Finally, the size of the smallest class serves as a practical constraint: classes containing fewer than 5–8% of the sample may lack sufficient observations to estimate class-specific parameters reliably and risk overfitting [20]. Together, the AIC gradient, entropy, and minimum class size provide complementary evidence for class enumeration, particularly when BIC’s strong parsimony penalty favors a solution simpler than domain knowledge would suggest. 2. The fully unconstrained K = 4 model estimates approximately 195 free parameters (48 response probabilities per class plus 3 mixing weights) for 400 observations. While this 2:1 observation-to-parameter ratio is low by structural equation modeling conventions, EM estimation with categorical indicators is more stable than the raw ratio suggests: the ordinal response structure implicitly constrains the parameter space, and the high entropy (0.904) and acceptable bootstrap stability of the solution (Appendix B) provide empirical confirmation that the model is not overfitting. 3. LCA assumes conditional independence: within each class, the 12 indicators are assumed to be unrelated once class membership is accounted for. Some item pairs in the survey measure related constructs (e.g., B1 and B2 both capture governance; C1 and C2 both relate to environmental understanding), which could violate this assumption. Violations tend to produce additional classes that capture residual within-class correlations rather than genuine subgroups. The external validation results in Section 5.3, which show significant associations between cluster membership and project characteristics not used in clustering, argue against a purely spurious solution. 4. A more familiar alternative, K -means clustering, treats survey responses as continuous numbers and measures similarity using Euclidean distance. This implicitly assumes that the gap between “Strongly Disagree” (1) and “Disagree” (2) is the same as between “Agree” (4) and “Strongly Agree” (5), and that responses follow a bell-shaped distribution within each cluster: neither of which holds for five-point Likert scales. LCA avoids these assumptions by modeling the probability of each response option separately, making it the standard clustering method for ordinal survey data in the social and behavioral sciences.

Table 5 shows fit indices for models with K = 2 through K = 10. Based on the convergence of multiple criteria, K = 4 is selected as the optimal number of latent classes. BIC rises monotonically from K = 2, driven by the large number of parameters each new class adds combined with the BIC penalty, which scales with log(N ). By itself, BIC would select K = 2, but the AIC trajectory tells a different story. The largest AIC improvement occurs from K = 2 to K = 3, followed by a substantial further drop from K = 3 to K = 4. From K = 4 to K = 5, the improvement shrinks considerably, and AIC begins rising at K = 6. The region of diminishing returns spans K = 3 through K = 5, with K = 4 representing the point beyond which meaningful improvement largely ceases. Entropy at K = 4 is 0.904, the highest of any solution in the K = 2 through K = 5 range and well above the 0.80 threshold for good classification certainty. The K = 5 solution produces a smallest class of just 18 respondents (4.5% of the sample), which falls below the 5–8% range for adequate class size. The K = 4 solution, by contrast, has a smallest class of 31 respondents (7.8%), comfortably within this range. While entropy continues to rise at higher values of K , those solutions lack support from the AIC curve and carry growing risk of unstable small classes. Appendix B provides additional evidence, including a bootstrap stability analysis and likelihood ratio tests that jointly bracket the solution at K = 4. TABLE 5. L ATENT C LASS A NALYSIS MODEL FIT INDICES FOR K = 2 TO K = 10 CLASSES . K

AIC

∆AIC

BIC

Entropy

Smallest Class (%)

2 3 4 5 6 7 8 9 10

11140.7 10924.6 10826.2 10806.2 10827.3 10853.2 10901.3 10942.3 11001.6

−216.1 −98.4 −20.0 +21.1 +26.0 +48.0 +41.1 +59.3

11623.6 11651.0 11796.1 12019.6 12284.2 12553.6 12845.1 13129.7 13432.4

0.877 0.881 0.904 0.891 0.908 0.920 0.899 0.918 0.903

31.0 14.2 7.8 4.5 4.5 4.0 3.8 4.2 3.0

5.2. Cluster Signatures Tables 6 and 7 present, respectively, the median responses and endorsement rates (percentage rating an item ≥ 4) for each of the four clusters. The clusters are presented in order of decreasing size (number of respondents). Figure 1 provides a complementary visual summary. The largest cluster (n = 201, 50.2%) exhibits the broadest failure attribution of any group. Median responses are 4 or 5 on every item, and endorsement rates exceed 93% for all 12 factors (Table 7). Both B factors and C factors are endorsed at comparable rates, with no meaningful variation across items. In effect, the typical respondent in this cluster agrees or strongly agrees that every factor contributed to project failure. We label this cluster Perfect Storm: projects in which general IT project management

failures and segmentation-specific technical challenges occurred simultaneously and pervasively.5 The second-largest cluster (n = 134, 33.5%) shows a similarly broad but less intense pattern. Median responses are uniformly 4 across all 12 items, identical to much of the Perfect Storm cluster in Table 6. However, the endorsement rates reveal a clear difference. B factors are endorsed at roughly 30 percentage points below the corresponding rates in Perfect Storm. C factors are endorsed at higher rates than the B factors but still well below Perfect Storm. Further, nearly two-thirds of respondents in this cluster rate C factors higher than B factors on average. This cluster does not exhibit any single dominant failure cause. Instead, the pattern suggests projects that accumulated moderate friction across multiple dimensions without a decisive point of collapse. We label this cluster Diffuse Friction. The remaining two clusters break the pattern of broad endorsement. Unlike Perfect Storm and Diffuse Friction, which endorse most or all failure factors, these clusters reject some or all B factors while endorsing specific C factors. In the larger of the two (n = 34, 8.5%), median responses on B factors are predominantly 2, with low endorsement rates for insufficient leadership (B2, 8.8%) and unclear goals (B1, 17.6%). These respondents disagree that general project management problems caused their project to fail. Two C factors stand out: excessive manual effort in policy creation and maintenance (C4, 55.9%) and concerns about outages or business disruption (C6, 55.9%), both with a median of 4. This cluster describes projects where the operational burden of creating and maintaining segmentation policies was the primary barrier, compounded by reluctance to deploy aggressively due to outage risk. We label this cluster Operational Drag.6 The smallest cluster (n = 31, 7.8%) is defined by nearuniversal endorsement of scope creep (B3, 100%, median 5) and insufficient asset visibility (C2, 93.5%, median 5), with strong endorsement of complex environment (C1, 87.1%), unrealistic timeline (B4, 83.9%), and outage concerns (C6, 83.9%), all with medians of 5. This cluster describes projects where the scope expanded beyond what was originally planned in an environment that was difficult to see and understand, compounded by fear of disrupting production systems. We label this cluster Scope & Visibility Trap. 5. The broad endorsement in this cluster raises the question of acquiescence bias: a tendency to agree regardless of content. Three observations argue against this: (i) the two smallest clusters demonstrate that respondents in this sample discriminate sharply between items, rating some as low as 2 and others as 5; (ii) even within Perfect Storm, endorsement rates vary from 93.0% to 99.5%, indicating item-level differentiation; and (iii) Perfect Storm membership is associated with external project characteristics (campus network scope, Layer-2 adoption) that were not used in clustering, which response style bias alone would not produce. 6. The strong rejection of B factors combined with only moderate endorsement of C4 and C6 suggests that this cluster’s defining failure mechanism may be narrower or more nuanced than what the 12 survey items can capture. In-depth interviews with practitioners who experienced this failure pattern could reveal whether additional operational factors (not represented in the current framework) played a role.

TABLE 6. M EDIAN L IKERT RESPONSES PER CLUSTER (K = 4). S CALE : 1 = S TRONGLY D ISAGREE TO 5 = S TRONGLY AGREE . Item

Cluster Perfect Storm (n=201)

Diffuse Friction (n=134)

Operational Drag (n=34)

Scope & Visibility Trap (n=31)

B1 B2 B3 B4 B5 B6

4 4 5 5 4 4

4 4 4 4 4 4

2 2 3 2 2 2

4 2 5 5 2 2

C1 C2 C3 C4 C5 C6

4 4 4 4 4 4

4 4 4 4 4 4

2 2.5 3 4 2 4

5 5 5 4 4 5

TABLE 7. E NDORSEMENT RATES (% OF CLUSTER RATING ITEM ≥ 4) PER CLUSTER ( K = 4 ). Item

Cluster Perfect Storm (n=201)

Diffuse Friction (n=134)

Operational Drag (n=34)

Scope & Visibility Trap (n=31)

B1 B2 B3 B4 B5 B6

97.5 98.0 96.5 99.5 93.0 98.0

59.0 60.4 63.4 68.7 57.5 67.9

17.6 8.8 41.2 32.4 35.3 20.6

61.3 29.0 100.0 83.9 29.0 45.2

C1 C2 C3 C4 C5 C6

98.5 98.0 98.5 98.5 98.5 99.0

76.1 73.9 74.6 76.1 74.6 71.6

38.2 38.2 44.1 55.9 32.4 55.9

87.1 93.5 77.4 77.4 77.4 83.9

5.3. External Validation of Cluster Solution The four clusters were derived solely from responses to the general IT project failure items (B1–B6) and the segmentation project failure items (C1–C6). If the clusters reflect meaningful differences in project characteristics, they should also differ on variables that were not used in the clustering. To test this, chi-square tests of independence were conducted between cluster membership and six external variables: segmentation model type, segmentation approach, network environment, workload type, organization size, and primary failure type (Table 8). “Don’t know” responses were excluded on a per-variable basis. Results are presented in Tables 9 and 10. Projects that included campus networks in scope were significantly more likely to fall into the Perfect Storm or Scope & Visibility Trap clusters (p < 0.001). Campus segmentation introduces architectural complexity beyond data center or cloud environments—spanning building interconnects, wireless infrastructure, and diverse endpoint

TABLE 8. E XTERNAL VALIDATION VARIABLES , SHORT LABELS , AND RESPONSE OPTIONS . Variable

Short Label

Type

Response Options

Q1 Q2

Segmentation model type Segmentation approach

Single select Multi-select

Q3

Network environment

Multi-select

Q4

Workload type

Multi-select

ProfileOrganizationSize ProfileSuccess

Organization size Primary failure type

Single select Single select

Macro-segmentation; Micro-segmentation; Don’t know Layer-2 (VLAN, VXLAN); Layer-3 (VRFs, IP); Layer-3/4 (5-tuple); Layer-7 (application); User/device identity; Admin-assigned labels (tags); Other; Don’t know On-premises DC / private cloud; Public cloud; Campus network; IOT network; Branch / remote office; Don’t know Physical (bare metal); Virtualized (ESXi/KVM/Hyper-V); Container (Docker/K8s); Serverless; Don’t know 500–999; 1,000–2,999; 3,000–4,999; 5,000+; Don’t know Cancelled before implementation; Partially implemented then paused/cancelled; Fully implemented but rolled back; Delivered late/over budget (20%+); Delivered but failed to meet objectives

TABLE 9. S IGNIFICANT AND NEAR - SIGNIFICANT EXTERNAL ASSOCIATIONS WITH CLUSTER MEMBERSHIP (K = 4). P ERCENTAGES REPRESENT THE PROPORTION WITHIN EACH CLUSTER . F OR MULTI - SELECT ITEMS , PERCENTAGES REFLECT THE PROPORTION SELECTING THAT OPTION . “D ON ’ T KNOW ” RESPONSES EXCLUDED PER VARIABLE . Perfect Storm (n=201)

Diffuse Friction (n=134)

Operational Drag (n=34)

Scope & Visibility Trap (n=31)

χ2

Campus in scope

49.8

29.1

20.6

45.2

20.27

<0.001

Layer-2 used

54.2

40.3

47.1

71.0

12.04

0.007

Segmentation model type

Macro-segmentation Micro-segmentation

68.2 31.8

57.5 42.5

58.8 41.2

80.6 19.4

8.10

0.044

Organization size

500–999 1,000–2,999 3,000–4,999 5,000+

23.4 39.3 28.4 9.0

26.1 33.6 27.6 12.7

11.8 58.8 17.6 11.8

6.5 58.1 19.4 16.1

16.87

0.051†

Network environment

IOT in scope

32.3

44.0

44.1

29.0

6.30

0.098†

Variable

Category

Network environment Segmentation approach

p

† Approaching significance; organization size has 2 of 16 cells with expected count < 5.

TABLE 10. N ON - SIGNIFICANT EXTERNAL ASSOCIATIONS WITH CLUSTER MEMBERSHIP (K = 4). “D ON ’ T KNOW ” RESPONSES EXCLUDED PER VARIABLE . Variable

Item tested

χ2

p

Primary failure type

Overall

16.68

0.162

Segmentation approach

Layer-3 (VRFs, IP) Layer-3/4 (5-tuple) Layer-7 (application) User/device identity Admin-assigned labels (tags)

2.58 2.23 3.56 4.66 1.03

0.461 0.526 0.313 0.199 0.793

Network environment

On-premises DC / private cloud Public cloud Branch / remote office

1.47 2.61 1.33

0.689 0.456 0.721

Workload type

Physical (bare metal) Virtualized (ESXi/KVM/Hyper-V) Container (Docker/K8s) Serverless

3.57 1.89 1.10 3.53

0.312 0.595 0.777 0.317

† 2 of 8 cells with expected count < 5. ‡ 4 of 20 cells with expected count < 5; test may be underpowered.

‡

†

Figure 2. Network Environments in Scope by Cluster (Archetype).

Figure 3. Network Segmentation Model Type by Cluster (Archetype).

populations—which is consistent with the broad failure attribution seen in Perfect Storm and the technical overwhelm that characterizes Scope & Visibility Trap. By contrast, Diffuse Friction and Operational Drag projects were much less likely to have campus networks in scope (Table 9, Figure 2). The Scope & Visibility Trap cluster is associated with traditional Layer-2 macro-segmentation (p = 0.007 for Layer-2 adoption; p = 0.044 for macro-segmentation model type). This cluster has the highest rates of both macrosegmentation and Layer-2 adoption of any group. Layer-2 macro-segmentation using VLANs and VXLANs depends heavily on accurate asset visibility to define effective network zones, which aligns directly with this cluster’s profile: universal endorsement of scope creep and near-universal

endorsement of insufficient asset visibility. The remaining three clusters are more evenly split between macro and micro approaches (see Figures 3, 4). Two additional variables approach but do not reach statistical significance. The Operational Drag and Scope & Visibility Trap clusters (the two smaller, selective-attribution groups) concentrate heavily in the 1,000–2,999 employee range, while Perfect Storm and Diffuse Friction are more evenly distributed across size categories (p = 0.051; Table 9). This result should be interpreted with caution due to low expected cell counts.7 IOT network scope (p = 0.098) shows a different grouping: Diffuse Friction and Operational Drag have notably higher IOT involvement than Perfect Storm and Scope & Visibility Trap. Both findings warrant further investigation with a larger sample. No significant differences between clusters were detected for the remaining external variables in the survey (Table 10). Primary failure type, most segmentation approaches (Layer-3, Layer-3/4, Layer-7, identity-based, and tag-based), most network environments (on-premises, public cloud, and branch/remote office), and all four workload types are distributed similarly across the four clusters. This suggests that the clusters are not simply proxies for workload composition or failure type, although the small size of two clusters limits the power of these tests. Taken together, the significant associations involve variables that describe how segmentation was attempted: macrovs micro-segmentation, the specific segmentation approach (Layer 2 vs Layer 3 etc.), and the specific network types in 7. The chi-square test compares observed cell counts to the counts that would be expected if cluster membership and the variable were unrelated [25]. When a small cluster is crossed with a variable that has many categories, some cells have expected counts below 5, at which point the chi-square approximation becomes unreliable and the resulting p-value may be inaccurate.

Figure 4. Network Segmentation Approach Type by Cluster (Archetype).

scope. Variables describing what workloads were involved or what failure types occurred show no significant association with cluster membership.

6. Practitioner-proposed Remedies The previous section identified four distinct failure archetypes, each characterized by a different pattern of attribution across B and C factors. A natural follow-up question is whether practitioners who experience different types of failure also propose different remedies. If so, the fix strategy should be tailored to the archetype. If not, the disconnect between diagnosis and prescription is itself a finding with practical implications. To investigate this, we analyze responses to Q8, which asked: “In your view, what is the single most important change that you would implement if you could do this segmentation project again?” Each response was coded against a codebook aligned with the B1–B6 and C1–C6 failure framework (see Appendix C) and collapsed into two categories: general IT project management fixes (B) and segmentation-specific fixes (C) [26]. A small number of responses (6.0%) that were either emergent or non-actionable were excluded. Table 11 (Figure 5)) presents the distribution of proposed fixes across the four failure archetypes. All four archetypes propose fixes in virtually the same ratio: approximately 70% B fixes and 30% C fixes. This ratio holds regardless of whether the cluster attributed failure broadly (Perfect Storm and Diffuse Friction) or selectively to C factors (Operational Drag and Scope & Visibility Trap). The chi-square test confirms no significant association between failure archetype and proposed fix category (p = 0.94). Practitioners who experience fundamentally different types of failure converge on the same balance of remedies (see Appendix D for sample responses).

This convergence is particularly notable for the two selective-attribution clusters. Operational Drag respondents endorsed B factors at low rates (Table 7), identifying excessive manual effort in policy maintenance and outage risk as their primary barriers. Yet 71.9% propose a general IT fix. Similarly, Scope & Visibility Trap respondents attributed failure primarily to segmentation-specific challenges such as insufficient asset visibility and environmental complexity, alongside scope creep (B3) and unrealistic timeline (B4): yet 75.9% propose a general IT fix. Two complementary explanations may account for this pattern. First, general project management shortcomings may shape how practitioners experience a project overall. Even when the proximate cause of failure is segmentationspecific, working within a project that struggled with some aspects of project management may leave respondents feeling that the project was fundamentally mishandled, and their proposed fix reflects that broader sentiment. Second, general project management failures may be the upstream root cause. If the project had been scoped realistically, resourced adequately, and governed effectively, the segmentation-specific challenges might have been discovered earlier and resolved before they became fatal. Under this reading, respondents are not contradicting their diagnosis: they are looking past the proximate technical barrier to the organizational conditions that allowed it to emerge. Both explanations lead to actionable guidance. Projects must be run well at a minimum: participants need to believe the project is worthwhile and has a realistic chance of success. However, when a segmentation-specific failure is identified, it is that failure that needs direct attention. Resorting to general IT project management fixes alone will not make a segmentation-specific problem go away; both the upstream conditions and the proximate technical barrier may need to be addressed simultaneously.

Figure 5. Proposed Fix Category by Failure Archetype.

Future research could investigate whether the observed preference for B fixes over C fixes reflects a default toward more familiar remedies, a genuine causal belief, or something else altogether. TABLE 11. P ROPOSED FIX CATEGORY BY FAILURE ARCHETYPE (% OF CLUSTER ). R ESPONSES CODED AS EMERGENT OR NULL (6.0% OF TOTAL ) ARE EXCLUDED . χ2 = 0.42 , df = 3 , p = 0.94 .

Cluster

n

General IT Fix (%)

Segmentation Fix (%)

Perfect Storm Diffuse Friction Operational Drag Scope & Vis. Trap

188 127 32 29

70.2 71.7 71.9 75.9

29.8 28.3 28.1 24.1

7. Limitations The findings in this study are based on practitioner survey responses and are therefore subject to common limitations of survey-based research. Survey respondents may not fully represent all organizations or roles involved in segmentation projects, and practitioners with stronger experiences or opinions may be more likely to respond. The survey captures practitioner perceptions using a limited number of items, which necessarily provide a simplified view of complex organizational and technical issues. Responses also reflect individual perspectives and retrospective judgment, which may be influenced by role, experience, or organizational context. In addition, because segmentation practices and constraints vary across industries, organization sizes, and technology environments, the identified patterns should be interpreted as broadly indicative rather than universally applicable to all segmentation deployments. The clustering results further depend on how failure factors were defined and measured. Failure factors were represented using twelve Likert-scale survey questions based on prior research and industry reports. This focused set of questions supports interpretability, but different question formulations or additional failure factors could lead to different clustering results. Accordingly, the identified clusters should

be viewed as patterns within the chosen set of failure factors rather than as a complete or authoritative explanation of why segmentation projects fail. The two smaller archetypes (Operational Drag and Scope & Visibility Trap) contain 34 and 31 respondents respectively. Both clusters fall within the 5–8% range suggested for adequate class size [20], but their small absolute counts limit the precision of within-cluster statistics and the power of external validation tests. A larger sample might reveal additional structure within these groups or sharpen the borderline findings for organization size and IOT network scope. The external validation analysis involves multiple statistical tests without formal adjustment for multiple comparisons. Consequently, some reported associations may be due to chance, particularly those with marginal significance. The most prominent result (campus network in scope of segmentation project) appears robust, while other findings should be interpreted as exploratory. Free-form responses to Q8 were coded by a single researcher, and inter-rater reliability was not assessed. Coding at the granular level (B1–B6, C1–C6) before collapsing to broader categories (B, C) reduces the impact of withincategory disagreements, but ambiguous responses may still reflect the researcher’s interpretation rather than the respondent’s intent. In addition, each response received exactly one code; responses that proposed multiple fixes of different types were reduced to the most central one, which may undercount secondary fix types. Q8 asks what the respondent would change, which captures perceived remedies rather than causal analysis. The convergence on B fixes across all four archetypes may reflect what practitioners feel empowered to change rather than what they believe would be most effective. The distinction between controllability and causal importance cannot be resolved from this data alone.

8. Conclusion The 2025 National Academies Cyber Hard Problems report identifies the lack of an empirical basis for security decisions as a fundamental challenge, observing that most established cybersecurity best practices rest on common sense and received wisdom rather than rigorous evidence [27]. This paper responds to that call by providing the first systematic empirical analysis of why network segmentation projects fail. We developed a survey grounded in a two-part failure framework that distinguishes general IT project failure factors from segmentation-specific failure factors. Both framework components were measured using six survey items each. The resulting survey was administered to 400 network security practitioners in the U.S. Latent Class Analysis of the survey responses identified four distinct failure archetypes. Perfect Storm (50.2% of respondents) describes projects in which general IT project management failures and segmentation-specific technical challenges occurred simultaneously and pervasively. Diffuse

Friction (33.5%) describes projects that stalled under the cumulative weight of broad, moderate challenges rather than failing on any single front. Operational Drag (8.5%) describes projects where there was adequate goal clarity and executive sponsorship, but the operational burden of policy creation and maintenance proved unsustainable. Scope & Visibility Trap (7.8%) describes projects defeated by scope changes, unrealistic timeline, and the technical difficulty of segmentation in a complex environment with poor asset visibility and low disruption tolerance. The archetypes are not merely statistical groupings: they correspond to real differences in how segmentation was attempted. Projects involving campus networks and traditional Layer-2 macro-segmentation are more likely to fall into the Perfect Storm or Scope & Visibility Trap archetypes. Practitioners planning segmentation initiatives that span campus environments or rely on Layer-2 approaches should anticipate a higher risk of broad or technically intense failure and plan accordingly. By contrast, the archetypes do not significantly differ by workload type, suggesting that the failure patterns arise regardless of whether the environment runs bare metal, virtualized, containerized, or serverless workloads. When asked what single change they would make, respondents across all four archetypes proposed general IT project management fixes over segmentation-specific fixes in the same roughly 70/30 ratio, even when their failure attribution was predominantly segmentation-specific. These findings carry direct implications for practitioners managing segmentation initiatives. The existence of four distinct failure archetypes suggests that a one-size-fits-all approach to segmentation project recovery is insufficient: a Perfect Storm project requires broad organizational remediation, while a Scope & Visibility Trap project needs targeted investment in asset discovery and environmental scoping. At the same time, the convergence on general IT project management fixes across all archetypes reveals a gap between how practitioners diagnose failure and how they propose to address it. Organizations should treat strong project governance as a necessary foundation, but when segmentation-specific barriers are identified—whether excessive policy burden, poor asset visibility, or environmental complexity—those barriers require segmentation-specific interventions rather than a retreat to general project management practices.

Appendix A. Survey Administration The survey was administered by Vanson Bourne,8 an independent research firm, on our behalf. Respondents were recruited from Vanson Bourne’s proprietary panel of IT and security professionals. In total, 4,921 individuals were exposed to the survey. Of this initial pool, 3,050 individuals were screened out during the qualification phase for failing to meet the eligibility criteria. These criteria included involvement in a network segmentation project within the

previous 24 months and employment at an organization meeting the required employee count (500) at the time of the project. A further 1,271 respondents who passed the screening phase were eliminated following stringent data quality checks. These exclusions were based on behaviors such as “speeding” through the survey or providing a high frequency of “Don’t know” responses. Another 182 qualified respondents dropped out of the survey during the profiling section of the survey. Furthermore, 18 respondents dropped out in the main part of the survey; some of these responses were terminated once the target sample size of 400 was achieved and the survey was closed. The final sample comprises 400 completed responses from U.S.-based network security practitioners. Each respondent reported on a single failed segmentation project occurring within the previous 24 months at an organization with 500 or more employees. The median completion time for a successful response was 16 minutes and 58 seconds. For information on the project role and career experience of the 400 respondents see Figures 6, 7.

Appendix B. Additional Evidence for Four Classes To assess whether the four-class solution is robust to sampling variability, the LCA was refitted on 200 bootstrap samples (resampled with replacement) for K = 3, K = 4, and K = 5. Within each bootstrap sample (and for each K ), respondents were assigned to the class with the highest posterior probability to obtain hard class labels for comparison. Class assignments from each bootstrap sample were compared to the corresponding full-sample assignments using the Adjusted Rand Index (ARI), which measures agreement between two sets of class labels on a scale from 0 (random) to 1 (perfect) [28]. Table 12 presents the results. The K = 4 solution has comparable stability to K = 3, with a higher mean and median ARI and lower variability between bootstrap runs. At K = 5, stability drops noticeably, with no bootstrap samples reaching the 0.80 threshold for good agreement. The moderate absolute ARI values at K = 4 are consistent with expectations for a model containing two smaller classes of 31 and 34 respondents; bootstrap samples that underrepresent one of these groups will produce a less precise recovery of the full-sample solution. The stability analysis therefore establishes an upper bound (K < 5): as K = 5 fragments the data beyond what can be reliably recovered. To establish a lower bound, the Bootstrap Likelihood Ratio Test (BLRT) was used to test whether each successive class provides a statistically significant improvement in model fit over the previous solution [19], [29]. Table 13 presents the results. All four tests are significant (p < 0.01), indicating that each additional class from K = 2 through K = 5 captures structure not present in the simpler model. In particular, the K = 4 vs K = 3 test is significant with a likelihood ratio statistic of 220.4, confirming that the fourth 8. https://www.vansonbourne.com/

Figure 6. Role Distribution of Respondents on Failed Segmentation Project.

Figure 7. Segmentation Projects Undertaken by Respondents over Career.

class represents a genuine improvement over the three-class solution rather than an artifact of model flexibility. The BLRT therefore establishes a lower bound (K > 3): as stopping at K = 3 would discard meaningful structure that the data supports. Taken together, the two tests bracket the solution. The bootstrap stability analysis rules out K = 5 (the fifth class cannot be reliably recovered), while the BLRT rules out K = 3 (the fourth class is statistically justified). K = 4 is the only solution that satisfies both criteria.

TABLE 12. B OOTSTRAP STABILITY OF LCA SOLUTIONS (K = 3 TO K = 5). A DJUSTED R AND I NDEX (ARI) COMPUTED OVER 200 SHARED BOOTSTRAP SAMPLES . K

Mean ARI

SD

Median ARI

Q25–Q75

% ≥ 0.80

3 4 5

0.637 0.655 0.592

0.155 0.117 0.104

0.651 0.662 0.608

0.559–0.749 0.571–0.751 0.527–0.662

15.0 9.5 0

TABLE 13. B OOTSTRAP L IKELIHOOD R ATIO T EST (BLRT) RESULTS . 100 PARAMETRIC BOOTSTRAP SAMPLES PER TEST. Test

LLK−1

LLK

LRT

p

K = 2 vs K = 1 K = 3 vs K = 2 K = 4 vs K = 3 K = 5 vs K = 4

−5842.4 −5449.3 −5280.3 −5170.1

−5449.3 −5280.3 −5170.1 −5099.1

786.2 338.1 220.4 142.0

<0.01 <0.01 <0.01 <0.01

Appendix C. Free-form Text Coding Methodology This appendix describes the methodology used to code free-form responses to Q8, which asked respondents to identify the single most important change they would implement if they could repeat their segmentation project. The goal was to assign each response a single code representing the most central fix proposed by the respondent. A 14-code codebook was developed, aligned with the failure framework used in the survey (Tables 2 and 3) [26]. Twelve codes (B1–B6, C1–C6) map directly to the general IT project failure factors and segmentation project failure factors measured by the Likert items. An additional code captures responses that are concrete but do not map to any

of the 12 factors (E, Emergent Fix). A final code captures responses that are vague, non-actionable, or express satisfaction with the current approach (F, Null/No Change). Table 14 presents the full codebook with definitions and examples. Because the codebook describes proposed remedies rather than failure factors, some definitions are broader than the corresponding survey items: for example, the B5 codebook definition includes phasing as a specific risk reduction technique, whereas the B5 survey item measures the general failure to manage risks during execution. The examples in the codebook were developed after reviewing the free text responses from another survey and those from the pilot phase of the survey in this paper (the 15 pilot responses are not part of the 400 survey responses analyzed in this paper). Each response was assigned exactly one code, representing the most central fix in the respondent’s answer. When a response included multiple fixes but none dominated clearly, E was assigned if the content was concrete and F if all fixes were vague. Coding was performed blind to cluster membership to prevent the coder from unconsciously steering responses toward fixes expected for a given archetype. For statistical analysis, the 14 codes were collapsed into four categories: general IT project management fixes (B1–B6 → B), segmentation-specific fixes (C1–C6 → C), emergent (E), and null (F). Coding at the granular level (requiring the coder to identify the specific failure factor being addressed) improves accuracy at the collapsed level. The most consequential coding error for the analysis would be confusing a B code with a C code; this requires a substantially larger misreading of the response than confusing, say, B1 with B3 or C4 with C5. The collapsing step thus absorbs the most likely source of coding variability. Table 15 presents the distribution of codes across all 400 respondents.

Appendix D. Sample Free-text (Q8) Responses “Make the project timeline more flexible so it can accommodate changes and iterations.” — Perfect Storm Respondent

“Major coordination between network security and application teams can stop policy conflicts that broke key internal tools completely.” — Diffuse Friction Respondent

“I would ensure the scope was strictly followed.” — Operational Drag Respondent

“Better and smarter organizational leadership.” — Scope & Vis. Trap Respondent

References [1]

R. Bredesen and S. Mujeye, “Network segmentation security with the implementation of threats,” in Proc. 8th Int. Conf. Softw. Eng.

Inf. Manag. (ICSIM). ACM, 2025, pp. 137–141, doi: https://doi.or g/10.1145/3725899.3725920. [2]

N. R. Kotha, “Network segmentation as a defense mechanism for securing enterprise networks,” Turk. J. Comput. Math. Educ., vol. 11, no. 3, pp. 3023–3030, 2020, doi: https://doi.org/10.61841/turcomat. v11i3.14942.

[3]

N. Wagner, C. Ş. Şahin, M. Winterrose, J. Riordan, J. Pena, D. Hanson, and W. W. Streilein, “Towards automated cyber decision support: A case study on network segmentation for security,” in Proc. IEEE Symp. Ser. Comput. Intell. (SSCI). Lexington, MA, USA: IEEE, 2016, pp. 1–10, doi: https://doi.org/10.1109/SSCI.2016.7849908.

[4]

J. K. Pinto and S. J. Mantel, “The causes of project failure,” IEEE Trans. Eng. Manag., vol. 37, no. 4, pp. 269–276, 1990, doi: https: //doi.org/10.1109/17.62322.

[5]

A. Budzier and B. Flyvbjerg, “Overspend? late? failure? what the data say about IT project risk in the public sector,” arXiv preprint, 2013, arXiv:1304.4525, https://arxiv.org/abs/1304.4525.

[6]

T. O. A. Lehtinen, M. V. Mäntylä, J. Vanhanen, J. Itkonen, and C. Lassenius, “Perceived causes of software project failures—an analysis of their relationships,” Inf. Softw. Technol., vol. 56, no. 6, pp. 623–643, 2014, doi: https://doi.org/10.1016/j.infsof.2014.01.015.

[7]

S. Lauesen, “IT project failures, causes and cures,” IEEE Access, vol. 8, pp. 72 059–72 067, 2020, doi: https://doi.org/10.1109/ACCE SS.2020.2986545.

[8]

J. Schmidt, “Mitigating risk of failure in information technology projects: Causes and mechanisms,” Proj. Leadersh. Soc., vol. 4, p. 100097, 2023, doi: https://doi.org/10.1016/j.plas.2023.100097.

[9]

V. Rodrı́guez Montequı́n, J. Villanueva Balsera, S. M. Cousillas Fernández, and F. Ortega Fernández, “Exploring project complexity through project failure factors: Analysis of cluster patterns using self-organizing maps,” Complexity, vol. 2018, no. 1, pp. 1–17, 2018, doi: https://doi.org/10.1155/2018/9496731.

[10] Cisco Systems Inc., “The segmentation report,” White paper, Oct. 2025, [Online]. Available: https://www.cisco.com/c/en/us/products/c ollateral/security/hypershield/segmentation-report.pdf. [11] Akamai Technologies, “Segmentation impact study,” White paper, Sep. 2025, [Online]. Available: https://www.akamai.com/site/en/d ocuments/research-paper/segmentation-impact-study-2025.pdf. [12] ——, “The state of segmentation 2023,” White paper, Oct. 2023, [Online]. Accessed: Feb. 2025. [13] R. Dube, “A taxonomy of segmentation in network security,” IEEE Access, vol. 14, pp. 16 921–16 935, 2026, doi: https://doi.org/10.110 9/ACCESS.2026.3658250. [14] N. Mhaskar, M. Alabbad, and R. Khedri, “A formal approach to network segmentation,” Comput. Secur., vol. 103, p. 102162, 2021, doi: https://doi.org/10.1016/j.cose.2020.102162. [15] R. Likert, “A technique for the measurement of attitudes,” Arch. Psychol., vol. 22, no. 140, pp. 1–55, 1932. [16] A. P. Dempster, N. M. Laird, and D. B. Rubin, “Maximum likelihood from incomplete data via the EM algorithm,” J. Roy. Statist. Soc. Ser. B, vol. 39, no. 1, pp. 1–38, 1977. [17] L. M. Collins and S. T. Lanza, Latent Class and Latent Transition Analysis: With Applications in the Social, Behavioral, and Health Sciences. Hoboken, NJ, USA: Wiley, 2010, ISBN: 978-0470228395. [18] J. K. Vermunt and J. Magidson, “Latent class cluster analysis,” in Applied Latent Class Analysis, J. A. Hagenaars and A. L. McCutcheon, Eds. Cambridge, U.K.: Cambridge Univ. Press, 2002, pp. 89–106, doi: https://doi.org/10.1017/CBO9780511499531.004. [19] K. L. Nylund, T. Asparouhov, and B. O. Muthén, “Deciding on the number of classes in latent class analysis and growth mixture modeling: A Monte Carlo simulation study,” Struct. Equ. Model., vol. 14, no. 4, pp. 535–569, 2007, doi: https://doi.org/10.1080/1070 5510701575396.

TABLE 14. C ODEBOOK FOR FREE - FORM RESPONSE CODING . Code

Name

Definition

Examples

B1

Clear Goals

Define goals clearly and consistently at the outset.

B2

Executive Sponsorship Scope Management

Obtain sufficient senior leadership sponsorship and decision-making support. Prevent scope creep and changing requirements.

B4

Timeline and Resources

Develop realistic project timeline given available resources including workforce skills and training.

B5

Project Execution

B6

Coordination and Communication

Identify, track and effectively address issues and project risks during execution including phasing the project as a risk reduction measure. Coordinate and communicate effectively between stakeholders.

If I could change one thing then I would define success more clearly; We don’t have a segmentation approach and it would be good to have one; More clarity on what success looks like Clear ownership for segmentation; Teams don’t agree on priorities; Better alignment and leadership If I had the opportunity to change one thing about segmentation it would be the scope; Understand what is actually in scope; Requirements keep changing We need a larger budget for this critical work; Less worry about budget pressures; We need more budgeting to help implement a new approach; Educating and training people on the benefits and pathway forward. A workshop to be held with an SME to provide information and take questions would help; Having more knowledgeable employees to help with decision making process We sometimes wait until change is needed rather than proactively planning; Planning is good but execution is weak; No clear roadmap

C1

Architecture and Environment

C2

Asset Visibility

C3

Communication Flows

Identify legitimate communication flows between systems effectively.

C4

Policy Lifecycle and Operations

Automate creation and maintenance of segmentation policies. Use Artificial Intelligence (AI) to generate or modify policies dynamically, reducing manual work. Standardization of policies.

C5

Tooling Maturity

Obtain access to mature segmentation tools. Tooling capability, maturity, integration, or 3rd party services regardless of environment.

C6

Risk Appetite

Be willing to take some risk of application outages or business disruption.

E

Emergent Fix

F

Null / No Change

An emergent category. Use only when the response is clear and specific but does not map to one of B1–B6 or C1–C6 (as the most important fix). If a response includes many fixes but none dominate clearly, use E. Satisfied, unsure or lacks the knowledge to answer. Non-actionable responses. Statements without a proposed change. Any response that is vague, underspecified, or unclear in what it is referring to.

B3

Simplify the environment (e.g., hybrid cloud, containers, legacy systems). Restrict segmentation projects to specific environments. Environmental heterogeneity independent of tooling. Obtain sufficient visibility into assets to design effective segmentation policies.

I would like different departments to have better understanding; More collaboration between teams, then more execution; Have full buy in from all areas; Creating a rapid customer feedback mechanism enables timely feedback into product and service improvement; Increase the focus on customer feedback Adapt to dynamic environments such as clouds and containers with microsegmented platforms; Environment is too complex; We need more scalability and create more environments; The most important thing is to enhance support for legacy systems and strengthen perimeter protection It needs to be more focused on protecting critical assets to reduce threats, risks, and vulnerabilities; Better visibility into assets; We don’t know all assets in the environment Shift towards more dynamic and granular behavior-based segmentation; I would have my organization use more dynamic approaches; Segmented based on the flow of data generation, storage, transmission, use, and destruction; Know which systems talk to each other Implementation of AI to improve efficiency and accuracy; Make it more automated, policies and rules are manual; Tie firewall policy for macro segmentation and host based micro segmentation policies together; I’d streamline policy management by moving to a more unified platform, so teams spend less time coordinating across different tools and enforcement points; Clearer policy rules across the whole organization Segmentation tools are immature; Better technology implementation and risk mediation; We lack tools that support segmentation; It would be better integration testing. I think running more parallel with another production environment would be more helpful Enhanced segmentation planning that includes risk; Not willing to accept outages; Risk tradeoffs are not discussed Easier navigation; Fast forward service delivery; Let the new professionals demonstrate the new tools; It need [sic] to be more unified

nothing [sic], it has a good approach; More comprehensive; I am very satisfied with the current situation

TABLE 15. D ISTRIBUTION OF CODES ACROSS 400 RESPONDENTS . Code

Code Name

n

%

B1 B2 B3 B4 B5 B6

Clear Goals Executive Sponsorship Scope Management Timeline and Resources Project Execution Coordination and Communication

34 21 11 45 104 53

8.5 5.2 2.8 11.2 26.0 13.2

Total B

268

67.0

C1 C2 C3 C4 C5 C6

Architecture and Environment Asset Visibility Communication Flows Policy Lifecycle and Operations Tooling Maturity Risk Appetite

4 30 28 10 35 1

1.0 7.5 7.0 2.5 8.8 0.2

Total C

108

27.0

Emergent Fix Null / No Change

15 9

3.8 2.2

Total

400

100.0

E F

[20] K. Nylund-Gibson and A. Y. Choi, “Ten frequently asked questions about latent class analysis,” Transl. Issues Psychol. Sci., vol. 4, no. 4, pp. 440–461, 2018, doi: https://doi.org/10.1037/tps0000176. [21] K. P. Burnham and D. R. Anderson, Model Selection and Multimodel Inference: A Practical Information-Theoretic Approach, 2nd ed. New York, NY, USA: Springer, 2002, ISBN: 978-0387953649. [22] G. Celeux and G. Soromenho, “An entropy criterion for assessing the number of clusters in a mixture model,” J. Classif., vol. 13, no. 2, pp. 195–212, 1996, doi: https://doi.org/10.1007/BF01246098. [23] V. Ramaswamy, W. S. DeSarbo, D. J. Reibstein, and W. T. Robinson, “An empirical pooling approach for estimating marketing mix elasticities with PIMS data,” Market. Sci., vol. 12, no. 1, pp. 103–124, 1993, doi: https://doi.org/10.1287/mksc.12.1.103. [24] K. E. Masyn, “Latent class analysis and finite mixture modeling,” in The Oxford Handbook of Quantitative Methods: Vol. 2. Statistical Analysis, T. D. Little, Ed. New York, NY, USA: Oxford Univ. Press, 2013, pp. 551–611, doi: https://doi.org/10.1093/oxfordhb/978019993 4898.013.0025. [25] A. Agresti, An Introduction to Categorical Data Analysis, 2nd ed. Hoboken, NJ, USA: Wiley, 2007, ISBN: 978-0471226185. [26] H.-F. Hsieh and S. E. Shannon, “Three approaches to qualitative content analysis,” Qual. Health Res., vol. 15, no. 9, pp. 1277–1288, 2005, doi: https://doi.org/10.1177/1049732305276687. [27] National Academies of Sciences, Engineering, and Medicine, Cyber Hard Problems: Focused Steps Toward a Resilient Digital Future. Washington, DC, USA: National Academies Press, 2025, ISBN: 9780-309-73489-9. [28] L. Hubert and P. Arabie, “Comparing partitions,” J. Classif., vol. 2, no. 1, pp. 193–218, 1985, doi: https://doi.org/10.1007/BF01908075. [29] G. J. McLachlan and D. Peel, Finite Mixture Models. NY, USA: Wiley, 2000, ISBN: 978-0471006268.

New York,