More tools, more problems: why security stacks backfire

At a glance

What this is: Illumio argues that rising security spend and expanding tool stacks are not translating into better outcomes because complexity is creating gaps, not coverage.

Why it matters: For IAM and security teams, the same pattern shows up when identity, access, and containment controls are layered without ownership, because more tooling can still leave privilege, lateral movement, and response gaps unmanaged.

By the numbers:

• 34% in 2025.

👉 Read Illumio’s analysis of why security stacks can work against resilience

Context

Security programmes often fail when they optimise for visible activity instead of reduced blast radius. In this case, the primary issue is not a lack of tools but an accumulation of overlapping controls, disconnected dashboards, and unclosed vulnerability exposure that makes risk harder to see and harder to contain.

The identity angle is indirect but real. When access controls, workload protections, and monitoring operate as separate layers without a coherent model, the result is the same governance problem IAM teams already see in privilege sprawl and weak containment. That makes this a resilience and governance story, not just a tooling story.

Key questions

Q: What breaks when security teams add more tools without reducing overlap?

A: Overlapping tools often break the control model by creating inconsistent policies, duplicated alerts, and ownership gaps. Teams spend more time reconciling systems than reducing exposure, and attackers benefit from the seams between products. The fix is to define each tool’s purpose, remove redundant coverage, and measure whether the stack reduces blast radius rather than simply increasing activity.

Q: Why do large vulnerability backlogs make risk harder to manage?

A: Large backlogs make risk harder to manage because they turn prioritisation into a volume problem instead of an exposure problem. Once teams are dealing with tens of thousands of issues, they lose clarity on which weaknesses are reachable, exploitable, or tied to critical assets. Effective programmes rank remediation by exploitability and business impact, not by queue order.

Q: How do security teams know whether their stack is actually improving resilience?

A: They know it is improving resilience when a single compromise cannot move easily across systems, access is tightly scoped, and remediation decisions are driven by exposure path rather than dashboard volume. If alerts are rising but lateral movement risk is unchanged, the stack is producing visibility without containment.

Q: Who is accountable when tool sprawl leaves major gaps in containment?

A: Accountability sits with the security and technology owners who approved the control architecture and accepted the gaps between tools. Frameworks such as NIST CSF and NIST SP 800-53 expect defined ownership, continuous assessment, and control effectiveness, not just tool acquisition. If overlap creates exposure, governance has to answer for it.

Technical breakdown

Why tool sprawl creates security blind spots

Tool sprawl does not simply add overhead. Each new control plane introduces its own logs, policies, integrations, and failure modes, and those components rarely align cleanly across cloud, application, and identity layers. The result is a fragmented picture where teams can mistake alerts, dashboards, and ticket closure for actual exposure reduction. In practice, overlapping tools can hide the one path an attacker needs because no single owner sees the full chain from access to impact.

Practical implication: map where controls overlap, then remove duplicate coverage before adding another product.

How vulnerability backlogs distort risk decisions

A large backlog is not just an operations problem. Once tens of thousands of issues accumulate, prioritisation becomes statistical rather than contextual, and teams stop being able to distinguish exploitable exposure from noise. That creates a false sense of diligence while the attack surface remains broad. The article’s example shows how scale itself can become a governance failure when remediation capacity cannot match discovery volume.

Practical implication: rank remediation by exploitability, asset criticality, and exposure path, not raw backlog count.

Why blast-radius control matters more than more detection

Detection is useful only if containment limits how far an attacker can move after the first compromise. Security resilience depends on constraining lateral movement, reducing standing access, and making it harder for one failure to become a systemic incident. This is where identity governance intersects with cyber resilience: access scope and segmentation decisions shape the impact of every other control. If containment is weak, better telemetry only tells you how far the breach spread.

Practical implication: design controls around containment and privilege boundaries, not around alert volume.

Threat narrative

Attacker objective: The attacker aims to turn organisational complexity into reach, using gaps between tools to move from one exposed path to broader access or disruption.

1. Entry occurs through a weak or exposed control path that blends into an already complex environment, making initial compromise hard to distinguish from normal noise.
2. Escalation succeeds when overlapping tools do not share a unified view of privilege, vulnerability exposure, or trust relationships, giving attackers room to expand access.
3. Impact follows when the attacker reaches systems or data that were assumed to be protected by layered tooling but were never actually isolated or contained.

NHI Mgmt Group analysis

Security stack sprawl is now a governance failure, not just an efficiency problem. When teams add tools faster than they retire or integrate them, they create contradictory signals and blind spots that attackers can exploit. This is not about having fewer controls for the sake of simplicity, but about ensuring each control has a clear purpose, owner, and containment outcome. Practitioners should treat sprawl as a measurable risk condition, not a procurement preference.

More vulnerability data does not equal more risk understanding. Once a backlog reaches industrial scale, the organisation often stops prioritising by exposure path and starts managing by throughput. That creates theatre, not resilience, because the most dangerous issues are the ones that can be reached and chained, not the ones that are easiest to close. Teams should shift to exploitability-led triage and link vulnerability handling to asset criticality.

Blast-radius control is the missing metric in many modern security programmes. The article correctly points to resilience, but resilience only becomes operational when privilege scope, segmentation, and recovery boundaries are designed together. For IAM and PAM teams, this means access is not just a provisioning issue, it is a containment decision. Practitioners should measure how far a single compromise can travel before controls stop it.

Security activity has become a poor proxy for security effectiveness. Closed tickets, full dashboards, and frequent alerts can all coexist with high exposure if the programme lacks outcome metrics. That problem extends into identity governance when access reviews and policy checks happen without clear decisions on privilege reduction or blast radius. Practitioners should judge the stack by reduced exposure and constrained movement, not by operational busyness.

What this signals

Security programme leaders should treat tool rationalisation as an exposure-control exercise. The operational question is no longer how many products are deployed, but whether the environment is measurably easier to defend after each addition. Where identity and access controls are involved, the programme should verify that privilege scope, segmentation, and monitoring still align rather than drifting apart.

Containment metrics need to sit beside detection metrics. If a security stack cannot demonstrate reduced lateral movement, narrower access paths, or faster isolation of affected assets, it may be adding noise without reducing loss potential. That is especially important where NHIs and service accounts sit inside complex infrastructure and create hidden access paths.

The strongest signal in this article is a governance one: teams need to prove that their toolchain reduces the blast radius of the next incident. That means reassessing whether current controls are actually connected to the business resilience outcome they claim to support.

For practitioners

• Audit overlapping controls for redundancy Inventory where tools duplicate detection, policy enforcement, or logging across cloud, endpoint, and identity layers, then remove or consolidate coverage that does not change containment outcomes.
• Rebuild vulnerability prioritisation around exploitability Move from raw backlog counts to a triage model that weights active exploitation, asset criticality, and reachable exposure paths so remediation work targets real attack paths.
• Define containment as a security KPI Set measurable blast-radius objectives for high-value systems, including privilege limits, network segmentation, and recovery boundaries, so teams can prove the environment is harder to traverse after compromise.
• Tie identity controls to resilience outcomes Review standing access, privilege scope, and service account boundaries alongside the rest of the stack so IAM decisions directly support lateral movement resistance and incident containment.

Key takeaways

• Security stacks can become a liability when overlapping tools create blind spots, duplicate effort, and weak containment.
• Backlog volume and alert volume are poor substitutes for risk reduction when exploitable exposure remains reachable.
• IAM, PAM, and segmentation decisions matter because blast-radius control is the real test of whether a stack improves resilience.

Key terms

• Security Tool Sprawl: Security tool sprawl is the accumulation of overlapping products and controls that increase operational complexity without necessarily reducing risk. It becomes a governance problem when no team can explain which tools own detection, prevention, or containment across the full attack path.
• Blast Radius: Blast radius is the amount of damage a compromised system, account, or workload can cause before controls stop it. In practice, it is shaped by privilege scope, segmentation, recovery boundaries, and how quickly teams can isolate affected assets.
• Exploitability-Led Triage: Exploitability-led triage is a remediation method that prioritises weaknesses based on whether they are reachable and can be chained into real attack paths. It is more effective than raw backlog ranking because it ties effort to actual exposure, not just issue count.
• Containment: Containment is the ability to prevent an incident from spreading beyond its initial foothold. It depends on access boundaries, network controls, workload isolation, and identity governance that stops one compromised credential or system from becoming a broader breach.

What's in the full article

Illumio's full blog covers the operational detail this post intentionally leaves for the source:

• The article expands on the LinkedIn Live discussion with Tanya Janca and the specific reasoning behind the security spend critique.
• It outlines examples of tool sprawl, including how dashboards, alerts, and integrations can multiply without improving coverage.
• It explains the vibe-coding risk in more detail, including the example of generated code that deliberately leaked secrets.
• It closes with the resilience framing Illumio uses when thinking about containment, lateral movement, and blast radius.

👉 Illumio’s full post adds the spend critique, coding-risk example, and resilience framing in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management through a practitioner lens. It is designed for security teams that need to connect identity controls to access risk, operational resilience, and programme accountability.