Why More Security Tools Don't Always Help
Complexity itself has become a threat surface. Subtraction is now a security strategy.
The average enterprise security team operates between sixty and eighty distinct tools. The number has grown every year for a decade, despite every CISO claiming to want to consolidate. The pressure is structural: each new threat category produces a new vendor category, each new vendor category produces a procurement, and each procurement produces another console, another agent, another schema. The marginal value of tool sixty-one is often negative — it adds integration debt, alert volume, and a new identity surface to defend — but the marginal value is invisible at the moment of purchase, when the tool is being judged against its own capability rather than against its cost to the whole.
The best-run programs we audit have done the opposite of what their budget would suggest: they consolidated, deprecated, and bought time back for their analysts. The savings rarely showed up as a line item, because the deprecated tools were folded into broader contracts or written off as sunk cost. The savings showed up as faster incident response, lower analyst attrition, and a security team that could absorb a new risk without first negotiating another procurement.
The hidden costs
Every security tool has three costs that do not appear on its invoice. It consumes attention, by producing alerts that compete with every other tool's alerts for the same analyst. It widens the identity surface, by requiring service accounts, API keys, and console logins that themselves become targets. And it creates integration debt, because the data it produces has to be reconciled with the data every other tool produces if it is going to be useful during an incident.
These costs are nonlinear. The first tool produces a manageable load. The tenth tool produces a triage problem. The fiftieth tool produces an attention bankruptcy that no amount of SOAR can fully repair. Programs that have crossed that threshold tend to add more tooling to solve it, which is the wrong direction. The exit is through subtraction.
A fourth cost is institutional, and it is the one most often underweighted. Each tool produces a constituency inside the security team that depends on it for their daily work, their expertise, and in some cases their job security. Removing the tool requires removing the constituency's dependence on it, which is a change management problem rather than a technology problem. Programs that try to remove tools without addressing the constituency find that the tool reappears within a quarter, often under a different procurement.
A pragmatic test
Before adding a tool, ask: does it reduce the number of consoles an analyst touches during an incident? If not, the tool is taxing your team even when it works. The question is intentionally narrow because it forces a comparison against the existing stack rather than against an abstract risk. A tool that is excellent in isolation but adds a console is worse than a tool that is mediocre but folds into one you already operate.
The same test applied to existing tools is even more useful. For each tool in the stack, ask which decisions it produces, who acts on those decisions, and what would happen if it were turned off for a quarter. The honest answers usually identify three to five tools whose absence would be unnoticed, and another three to five whose function is duplicated. The list is the consolidation backlog.
The test has a corollary for vendor evaluations. A demo that requires a new console is a tool that will require a new console in production. A demo that integrates with the team's existing telemetry plane and produces decisions in the team's existing workflow is a tool that will continue to do so. The demo is the first honest look at the operational cost; teams that ignore the signal at the demo discover it during the post-deployment retrospective.
Subtraction as strategy
Treating subtraction as a strategy requires leadership cover, because the visible artifacts of subtraction are smaller than the visible artifacts of acquisition. A new tool produces a launch, a logo on a slide, and a vendor relationship to manage. A retired tool produces a quieter SOC, which is harder to celebrate but more durable. The CISOs who do this well make the quieter SOC the story they tell to their boards, with the analyst attrition rate and the mean-time-to-respond as the supporting evidence.
The mature end-state is not a single platform; it is a coherent telemetry plane fed by a small set of high-quality sources, with detections and runbooks expressed as code. From that substrate, adding the next capability is cheap. Without it, the next capability is just another console.
The transition is multi-year and requires sustained executive support. The first quarter of subtraction produces visible discomfort from the constituencies that depended on the deprecated tools. The second produces grudging acknowledgment that the consolidated stack works. The third produces a noticeable improvement in the metrics that the board actually cares about. The CISOs who hold the direction through the first quarter are the ones who reach the third; the CISOs who flinch in the first quarter end up with a larger stack than they started with, because the political cost of stopping a consolidation is higher than the cost of never starting one.
What the next tool should look like
When the consolidation has produced a coherent substrate, the next tool to add is the one that uses the substrate rather than competing with it. The vendors who will succeed in this market are the ones who treat the customer's existing telemetry plane as the integration surface and produce decisions inside it, rather than asking the customer to migrate data into yet another schema. The tools that demand their own schema are the tools whose unit economics will degrade as the market matures, because they are charging twice for data the customer already has.
The pragmatic procurement question, applied to every new tool, is whether it makes the substrate more valuable or more fragmented. The tools that make the substrate more valuable are the ones to invest in. The tools that fragment it are the ones to defer until the vendor has caught up to the architectural direction the market is moving in.
Measuring the consolidation
Consolidation programs need their own metrics, or they regress under the weight of the next quarter's procurement cycle. The metrics that have held up across the programs we have observed are concrete and short. The count of distinct consoles an analyst touches during a typical incident. The number of agents installed on the median endpoint. The fraction of detections expressed in a shared schema versus a vendor-specific one. The mean time from a new detection idea to a deployed detection in production. Each of these moves in the right direction when the consolidation is real and in the wrong direction when the program is drifting back toward sprawl.
Publishing the metrics inside the security organization changes the politics of the next procurement. A team that can see that its console count has dropped from forty to twenty over eighteen months is a team that is less willing to accept a new console without serious justification. A team that has watched the number creep back up is a team that has the evidence it needs to push back on the next proposal. The metrics are not a substitute for leadership; they are the artifact that lets leadership defend the direction when the procurement pressure arrives.
The metrics also change the vendor conversation. A vendor that is asked, at the start of the evaluation, how the proposed tool will affect each of the consolidation metrics is a vendor that has to answer in operational terms rather than in capability terms. The vendors that have good answers tend to be the vendors whose tools survive the deployment; the vendors that deflect the question tend to be the ones whose tools end up on the next consolidation backlog.
Subtraction in the AI-tooling era
The arrival of AI security tooling is reproducing the proliferation pattern at higher velocity. New vendors are appearing weekly with copilots, anomaly detectors, agent-monitoring platforms, and prompt-firewall appliances, each of them positioned as essential to the AI-era security program. Some of the tools are genuinely useful; many of them are repackaged primitives that the existing stack could provide with less integration cost. Programs that apply the same subtraction discipline to AI tooling that they apply to traditional tooling will end up with a coherent AI security substrate; programs that treat AI tooling as exempt from the discipline will reproduce the sprawl they spent the last five years escaping.
The pragmatic posture is to treat AI security tooling as additions to the telemetry plane the program has already built, not as a parallel stack. The questions are the same as for any other tool. Does it produce decisions inside the existing workflow, or does it require a new console? Does it speak the existing schema, or does it impose its own? Does it reduce the analyst's cognitive load, or does it add to it? The vendors who answer these questions well are the ones whose tools will survive the next round of consolidation; the vendors who do not are the ones whose tools will be on the backlog.