Notifications
Clear all
Topic starter
10/07/2026 9:22 pm
TL;DR: Security budgets are at record highs, but vulnerability backlogs, tool sprawl, and fragmented controls still leave enterprises exposed, according to Illumio and the Verizon 2025 Data Breach Investigations Report. The real problem is not lack of spend but a security operating model that rewards activity, complexity, and noise over containment and measurable risk reduction.
NHIMG editorial — based on content published by Illumio: More Tools, More Problems: Why Your Security Stack May Be Working Against You
By the numbers:
- 34% in 2025., y exploitation jumped 34% in 2025.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Illumio’s analysis of why security stacks can work against resilience →
Security tool sprawl: is your stack reducing risk or adding it?
Explore further
10/07/2026 9:45 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: More tools, more problems: why security stacks backfire
