More tools, more problems: why security stacks backfire

At a glance

What this is: Illumio argues that security stack sprawl is creating the illusion of progress while leaving enterprises with noisy tooling, massive backlog debt, and weak containment.

Why it matters: For IAM, NHI, and broader security teams, the lesson is that coverage is not control, and stacked tools do not replace governance, blast-radius reduction, or outcome-based security design.

Context

Security tool sprawl is a governance problem as much as a technical one. When teams add products faster than they integrate policies, telemetry, and response paths, they create overlapping controls that are harder to operate and easier for attackers to exploit. The same pattern shows up in identity programmes when access, secrets, and privilege are managed in separate silos without a shared operating model.

The article’s central point is that activity is not the same as effectiveness. In practice, that means dashboards, tickets, and alerts can make a team feel busy while leaving core risks untouched. For identity and access programmes, the relevant question is whether controls actually reduce standing access, contain blast radius, and improve decision quality, not whether they generate more operational noise.

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: What do security teams get wrong about tool proliferation?

A: They often assume more tools equal better protection. In practice, overlapping platforms can create fragmented telemetry, delayed response, and control gaps between teams. If the environment cannot correlate identity, access, and incident data quickly, attackers exploit the seams. The right question is whether each tool measurably improves containment, not whether it adds coverage on paper.

Q: How should security leaders decide whether to keep or cut a tool?

A: Keep it only if it measurably improves an outcome such as prevention, containment, or recovery in a way other controls do not already deliver. If the tool mainly produces dashboards, tickets, or duplicated alerts, it should be a candidate for consolidation or removal.

Technical breakdown

Why security stacks fail when controls are layered but not governed

A larger stack only improves security when the controls are coordinated around a common policy model and a shared view of risk. Otherwise, each new tool introduces its own telemetry, workflow, and exception handling, which increases operational friction and creates blind spots between products. The failure mode is not simply too many tools, but too many partially connected control planes making decisions in isolation. That is why complexity becomes an attacker advantage rather than a defensive asset.

Practical implication: rationalise control ownership and policy enforcement so separate tools do not create separate security truths.

Why backlog volume is a poor proxy for risk reduction

The article’s vulnerability example shows how backlog growth can become detached from real remediation capacity. Once a backlog reaches tens of thousands of issues, prioritisation becomes meaningless unless teams have strong exposure filtering, asset criticality, and owner accountability. This is especially relevant in identity and NHI environments, where stale accounts, unused secrets, and overprivileged access can persist far longer than any team can manually review. Volume alone does not tell you what is actually exploitable.

Practical implication: measure whether your backlog is shrinking the attack surface, not whether tickets are merely being closed.

How AI-generated code amplifies security stack weakness

AI-assisted development increases the amount of code entering production, often faster than security review capacity can adapt. That changes the control problem from inspecting isolated changes to governing defaults, pipeline safeguards, and secret-handling behaviour at scale. The article’s example of AI-generated output leaking secrets highlights a familiar NHI issue too: credentials embedded in code or automation paths become far harder to govern once they propagate through rapid delivery workflows. Speed magnifies weak controls.

Practical implication: move controls upstream into build and pipeline guardrails before insecure code and secrets become widespread.

Threat narrative

Attacker objective: Exploit control fragmentation to reach higher-value assets while defenders remain busy managing alerts, dashboards, and unresolved backlog.

1. Entry occurs through expanding attack surface and inconsistent controls across a sprawling stack, where each additional integration can create a new gap.
2. Escalation happens when overlapping tools fail to share context, letting attackers move through the weakest control path while defenders struggle to correlate signals.
3. Impact is achieved through uncontained lateral movement, unresolved vulnerability exposure, or secrets leakage that the security programme failed to reduce at source.

Breaches seen in the wild

• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Security tool sprawl becomes a control-plane problem when governance does not keep pace with procurement. Adding products without harmonising policy, ownership, and response simply distributes risk across more dashboards. The field should treat stack length as a governance smell, not a maturity signal, and measure whether each control reduces exposure or only adds activity.

Backlog volume is now a misleading security metric. A 40,000-item vulnerability queue may indicate process churn, not risk reduction, because untriaged findings can no longer guide meaningful remediation. The deeper issue is exposure prioritisation, especially where identity, secrets, and privilege create durable access paths. Teams should optimise for elimination of attack paths, not closure counts.

Blast-radius containment: this is the named concept security teams should now prioritise over tool accumulation. The article’s resilience lens is correct because modern attacks exploit the gap between detection and containment, not the absence of another product category. If lateral movement can still spread freely, the stack is compensating for weak architecture rather than fixing it; practitioners should make containment the primary design criterion.

AI-generated code turns weak defaults into scalable risk. When development speed increases, the security programme must shift from after-the-fact review to preventative guardrails, especially around secrets and insecure patterns. That makes NHI governance and pipeline policy more important, not less, because machine-created artefacts can propagate credential mistakes at production speed. Practitioners should govern the pipeline, not just inspect its output.

Security teams need fewer point solutions and more outcome ownership. The article rightly challenges the idea that adding another tool automatically improves resilience. In governance terms, this means linking controls to attack-surface reduction, containment, and recovery outcomes under frameworks such as NIST CSF and OWASP-NHI where identity-bound access is involved. Practitioners should audit for outcome gaps, not vendor coverage gaps.

From our research library:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
• Read next: Identity and NHI Security Business Case Guide

What this signals

Blast-radius containment is becoming the more useful security design lens than raw control count. When a stack grows faster than policy coherence, the practical question is whether one compromised path can still be contained before it reaches identity, secrets, or production workloads.

Security leaders should expect AI-assisted development to widen the gap between code volume and review capacity. That makes secure defaults, pipeline guardrails, and identity-aware controls more important than another layer of after-the-fact scanning.

For practitioners

• Reduce tool overlap by control outcome Map each security product to a specific outcome such as exposure reduction, containment, or recovery, then retire tools that only duplicate visibility without changing risk.
• Measure backlog by exploitable exposure Prioritise vulnerabilities, secrets, and identity issues by reachability, privilege, and business criticality instead of raw ticket counts or dashboard volume.
• Move guardrails into build pipelines Set secure defaults for code generation, CI, and deployment so unsafe patterns and leaked secrets are blocked before they reach production workflows.
• Design for containment first Reassess segmentation, privilege boundaries, and response paths so compromise of one control plane does not allow lateral movement across the environment.

Key takeaways

• Security stack sprawl can look like maturity while actually fragmenting ownership, slowing response, and leaving dangerous gaps between tools.
• The article’s strongest evidence is the mismatch between record-high budgets and persistent backlog, alert, and containment problems.
• The practical response is to consolidate around outcome-based controls that reduce exposure, contain blast radius, and remove unnecessary tooling.

Key terms

• Tool Sprawl: Tool sprawl is the accumulation of overlapping systems that each solve part of the same identity or operations problem. In practice, it creates duplicate workflows, inconsistent policy enforcement, and more manual reconciliation, which weakens confidence in access decisions and slows down secure scaling.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Security Theater: Security theater describes a control that looks protective but adds little real security relative to its cost or risk. The term is used when a measure increases complexity, friction, or failure modes without materially changing the attacker’s position. In practice, it is a warning to test whether a control meaningfully reduces exposure.
• Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the broader resilience outcomes their programmes are meant to deliver.