47 tools, and no safer

A CISO at a 600-person SaaS company pulled her team’s security tool inventory in early 2026. The inventory listed 47 tools, spanning every layer of the stack: EDR on every endpoint, SIEM ingesting from dozens of sources, CSPM across three clouds, CNAPP above that, a dedicated posture tool for SaaS, a separate tool for code scanning, another for secrets detection, one for DLP, another for CASB, yet another for AI-specific monitoring, a UEBA product, a SOAR platform to orchestrate across the other tools, an ASM tool for external attack surface, a BAS tool for continuous validation, and several others she had to consult her team to identify.

The total security budget across these tools was approximately $3.2 million annually. Her security team was ten people, seven of whom spent significant time managing and operating the tools.

She asked her team a specific question: how many of the breaches in the last year, across the industry, would these tools have prevented or detected?

The team couldn’t give a clean answer. The reasoning path went something like: the tools would probably have detected the ransomware campaigns. The phishing-driven credential compromises, partially. The supply chain attacks, probably not. The insider threats with legitimate credentials, detection would depend on UEBA tuning. The OAuth-based data exfiltrations, they weren’t sure. The AI-related data exposures through legitimate user queries, definitely not.

The CISO went back to the inventory and counted how many of the 47 tools had produced an actionable incident in the last quarter. The answer was roughly eight. The remaining 39 were either baseline monitoring that rarely alerted, tools that produced alerts that got dismissed or ignored, or tools the team hadn’t fully tuned and wasn’t really using.

This is a common pattern. The security stack has grown. Tool count is high. Coverage is broad. Breach rates are also high. The two trends, more tools and more breaches, have coexisted for a decade, which should at least raise the question of whether the tools are actually working.

This essay is about that question. Why the industry keeps adding tools, what the tools actually do and don’t do, and what a more effective allocation of security spend might look like.

the tool market responded to every threat category

Every significant threat category over the last fifteen years has produced a vendor category. Endpoint threats produced EDR. Perimeter threats produced firewalls and NGFW. Network threats produced IDS/IPS and NDR. Insider threats produced UEBA. Data exfiltration produced DLP. Cloud misconfigurations produced CSPM. Cloud application vulnerabilities produced CNAPP. Credential attacks produced ITDR. AI-era risks produced AI-specific monitoring products. Each category is a valid response to a real threat. Each category has multiple vendors competing for enterprise budget.

The result is a stack where each threat category has its own tool (or multiple tools). A mature security program buys across categories, because each category addresses risks the others don’t. A security team that lacks EDR is ignoring endpoint threats. A team that lacks CSPM is ignoring cloud misconfiguration. A team that lacks identity threat detection is ignoring credential-based attacks.

The tools are not wrong to exist. The problem is that buying a tool in a category is not the same as being protected from the threats in that category. Each tool requires deployment, configuration, tuning, integration with other tools, and ongoing operation. A deployed-but-untuned EDR is not the same as an effectively-operating EDR. The difference is the tuning and operation, which is labor-intensive.

Most security teams are labor-constrained. They can buy tools faster than they can operate them. The procurement budget is, broadly, elastic. The headcount budget is less so. The ratio of tools to operators has been growing for years.

the category is not the same as the outcome

A specific conceptual failure: conflating “we have a tool in category X” with “we are protected from threat X.”

Example. EDR is designed to detect and respond to endpoint threats. Having EDR on your endpoints is a necessary precondition for effective endpoint threat response. It is not sufficient.

For EDR to actually protect you, several operational conditions must be met. The EDR must be deployed on every relevant endpoint (not just most). The detection rules must be tuned for your environment, which varies by vendor and by context. Alerts produced by the EDR must be reviewed by someone capable of triaging them. Confirmed incidents must be responded to within a useful time frame.

The tool is the first precondition. The operational conditions are the rest. Mid-market companies often have the tool and fall short on one or more operational conditions. Detection rules are set to defaults that produce too much noise, so the team starts ignoring alerts. Alerts go unreviewed outside business hours. Response is manual and slow.

The outcome of this, a tool that is deployed but underoperated, is worse than no tool in one specific way. The tool creates the impression that the category is covered. The impression reduces the urgency to invest in operational capability. The operational capability remains underdeveloped. The threat that the tool was supposed to address is not actually mitigated.

A more useful framing than “we have EDR” is “we have an endpoint response capability that operates at [latency] with [confidence level].” The latter describes outcomes. The former describes ownership of a tool.

tool count and protection are different things

more tools

coverage on paper

• A tool for every threat category
• Alerts nobody has time to review
• Gaps between tools that nobody owns

fewer, operated tools

coverage in practice

• Each tool has a named owner
• Tuned, so alerts get reviewed
• Budget left for the people who run them

the alert volume that nobody can handle

A specific operational reality: tools produce alerts. Humans triage alerts. The capacity to triage is bounded. Above that capacity, alerts are ignored.

Most security tools, out of the box, produce more alerts than most teams can handle. This is by design, vendors err on the side of surfacing anomalies rather than hiding them, because missing a real incident is worse for the vendor’s reputation than generating noise. The tuning to reduce noise is a customer responsibility.

In a mid-market company, the SIEM might produce thousands of alerts per day. The EDR might produce hundreds. The CSPM might produce dozens. The team of three or four security analysts might triage, at full effort, a few hundred alerts total. Most of the generated alerts never get reviewed.

The tools are doing their job. The triage capacity is the bottleneck.

The specific failure mode is that critical alerts get lost in the volume. An actual intrusion produces alerts, but they’re buried among hundreds of low-severity anomalies. The analyst doesn’t get to them before the attacker completes their objective.

This is not a problem that adding another tool solves. Adding a SOAR to orchestrate the alerts addresses some of it, SOAR can automate the low-severity triage and escalate the high-severity items. But SOAR itself requires tuning, operation, and integration. Adding SOAR without adequate operation replaces one problem with another.

The more sustainable answer is to reduce the alert volume through tuning, which requires time investment that most teams don’t prioritize. The investment pays off in sustained signal-to-noise, but the payoff is delayed and the investment cost is visible.

the coverage gaps nobody owns

A separate specific pattern: the risks that fall between the tools.

Every security tool has a scope. EDR covers endpoints. CSPM covers cloud configuration. SSPM covers SaaS configuration. Identity tools cover identities. None of them covers all the risks to the business.

The risks that fall between the tools are often the ones that actually materialize. A compromised OAuth grant to a non-SSO SaaS tool is not clearly the responsibility of any of the standard tools. An AI-driven data exposure through a legitimate user’s query is not covered by most SIEMs. A supply chain attack through a third-party library is partially covered by some tools but not cleanly owned.

These gaps are not theoretical. They correspond to categories of incidents that have been well-documented in public breach disclosures. The Okta breach in 2023 involved compromised support engineer access to customer tenants, which is a category that most security tools don’t cover specifically. The SolarWinds breach involved supply chain compromise, which the security stacks at the affected customers didn’t prevent. The various Copilot data exposures involved permission misconfigurations, not malicious activity.

A security program focused only on tool coverage tends to have gaps in categories that don’t have tools. A program that tracks risks independently of tools tends to notice these gaps and either develop internal capability or consciously accept the risk.

The specific exercise is to list the risks the business faces, then map each risk to the tools that address it. Risks without tools are either gaps you need to address through non-tool means (process, contract, audit) or risks you need to explicitly accept.

the portfolio rationalization opportunity

For most mid-market companies, the security tool portfolio has not been rationalized in years. Tools were added as they became available. Tools were retained after they were superseded, because removing them required work and the budget for the old tool was already allocated.

Rationalization is the deliberate process of reviewing the portfolio, identifying redundant or underused tools, and consolidating where consolidation makes sense.

Common candidates for rationalization: multiple tools with overlapping functionality (two different endpoint tools, two different cloud security tools). Tools that were purchased and deployed but are not actively used. Tools whose primary value has been absorbed into a platform the company already pays for.

The exercise usually turns up tools that overlap or that nobody operates. The money they free up can be redirected either to operational capacity (headcount to operate the remaining tools more effectively) or to addressing coverage gaps.

Most companies don’t rationalize. The rationalization exercise is organizationally painful, because it involves deciding which tools to cut and defending the decisions against the teams that own each tool. The default is to continue the existing portfolio and add tools at the margin, which grows the portfolio monotonically.

The bet behind rationalising is simple: fewer tools that someone actually operates protect more than many tools that nobody watches. Measure it on your own incidents before and after.

the service model as an alternative

A specific alternative to buying tools directly: buying security outcomes through a managed service.

Managed Detection and Response (MDR) is the service version of EDR. A vendor provides the detection tool and the operational capability. The vendor’s analysts triage alerts. The vendor’s responders handle incidents. The customer receives escalations for significant events.

For mid-market companies without the headcount to operate an EDR effectively, MDR often produces better outcomes than internal EDR operation. The vendor has scale advantages, 24/7 operations, and accumulated expertise across many customer environments.

Similar services exist for other categories, MSSPs (managed security service providers) for broader SOC functions, specialized managed services for cloud, identity, and application security.

The tradeoff is cost and control. MDR is typically more expensive than the underlying EDR license. The customer has less direct control over tuning and response. The benefit is outcomes without internal operation cost.

For small teams, the math usually favors managed services for most categories. The in-house operation requires scale that small teams don’t have. The managed service gets the outcomes without requiring the scale.

Large teams with dedicated specialists can achieve better results in-house, but most mid-market companies don’t have the team size to justify in-house operation across every security category.

the budget allocation that makes more sense

For a typical mid-market security budget, here is a framework that produces better outcomes than the common alternative.

Allocate a significant majority to operations. This includes headcount, managed services, and the operational tooling to keep the small number of in-house tools effective. If the security team is three people and the tool count is 47, either the tool count needs to come down or the headcount needs to come up.

Allocate the remaining budget to tools, focusing on categories with high coverage value for your specific risk profile. Not every category needs a tool. The tools you buy should be the ones you can operate, not the ones you think you should have.

Allocate a small specific budget to operational validation. This includes penetration testing, tabletop exercises, red team work, and breach-and-attack simulation. The validation tells you whether your tools and operations are actually working.

The specific percentage split varies by company, but the principle holds: operations first, tools second, validation third. Most companies have the inverse, tools first, operations third, validation rarely.

the exercise

For your own security program, here is the diagnostic.

List every security tool in your environment. For each tool, answer: when was it last tuned? When was the last incident it helped detect or respond to? Is it operated by internal staff, or is it on autopilot? What would break if we turned it off tomorrow?

Tools that have not produced an incident-driving alert in six months, are not tuned, and would not be missed if turned off are candidates for removal.

Tools that produce alerts you don’t review are candidates for either operational investment or removal.

Tools where you can’t name the owner are candidates for explicit ownership assignment or removal.

After the review, you should have a shorter list of tools that actually produce value, operated by a clearer roster of owners, with the remaining budget freed for operational investment.

The 47-tool stack is not the goal. The operational capacity to handle the threats your business actually faces is the goal. The stack is a means to an end, and most stacks are over-built relative to the capacity available to run them.

Reduce the stack. Invest in operations. Validate the outcomes.

The breach count won’t drop because you added another tool. It will drop if you actually operate the tools you have.